The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

net: ravb: Fix missing rtnl lock in suspend/resume path

Fix the suspend/resume path by ensuring the rtnl lock is held where required. Calls to ravbopen, ravbclose and wol operations must be performed under the rtnl lock to prevent conflicts with ongoing ndo operations.

Without this fix, the following warning is triggered: [ 39.032969] ============================= [ 39.032983] WARNING: suspicious RCU usage [ 39.033019] ----------------------------- [ 39.033033] drivers/net/phy/phydevice.c:2004 suspicious rcudereferenceprotected() usage! ... [ 39.033597] stack backtrace: [ 39.033613] CPU: 0 UID: 0 PID: 174 Comm: python3 Not tainted 6.13.0-rc7-next-20250116-arm64-renesas-00002-g35245dfdc62c #7 [ 39.033623] Hardware name: Renesas SMARC EVK version 2 based on r9a08g045s33 (DT) [ 39.033628] Call trace: [ 39.033633] showstack+0x14/0x1c (C) [ 39.033652] dumpstacklvl+0xb4/0xc4 [ 39.033664] dumpstack+0x14/0x1c [ 39.033671] lockdeprcususpicious+0x16c/0x22c [ 39.033682] phydetach+0x160/0x190 [ 39.033694] phydisconnect+0x40/0x54 [ 39.033703] ravbclose+0x6c/0x1cc [ 39.033714] ravbsuspend+0x48/0x120 [ 39.033721] dpmruncallback+0x4c/0x14c [ 39.033731] devicesuspend+0x11c/0x4dc [ 39.033740] dpmsuspend+0xdc/0x214 [ 39.033748] dpmsuspendstart+0x48/0x60 [ 39.033758] suspenddevicesandenter+0x124/0x574 [ 39.033769] pmsuspend+0x1ac/0x274 [ 39.033778] statestore+0x88/0x124 [ 39.033788] kobjattrstore+0x14/0x24 [ 39.033798] sysfskfwrite+0x48/0x6c [ 39.033808] kernfsfopwriteiter+0x118/0x1a8 [ 39.033817] vfswrite+0x27c/0x378 [ 39.033825] ksyswrite+0x64/0xf4 [ 39.033833] _arm64syswrite+0x18/0x20 [ 39.033841] invokesyscall+0x44/0x104 [ 39.033852] el0svccommon.constprop.0+0xb4/0xd4 [ 39.033862] doel0svc+0x18/0x20 [ 39.033870] el0svc+0x3c/0xf0 [ 39.033880] el0t64synchandler+0xc0/0xc4 [ 39.033888] el0t64_sync+0x154/0x158 [ 39.041274] ravb 11c30000.ethernet eth0: Link is Down(CVE-2025-21801)

In the Linux kernel, the following vulnerability has been resolved:

Bluetooth: btrtl: Prevent potential NULL dereference

The btrtlinitialize() function checks that rtlload_file() either had an error or it loaded a zero length file. However, if it loaded a zero length file then the error code is not set correctly. It results in an error pointer vs NULL bug, followed by a NULL pointer dereference. This was detected by Smatch:

drivers/bluetooth/btrtl.c:592 btrtlinitialize() warn: passing zero to 'ERRPTR'(CVE-2025-37792)

In the Linux kernel, the following vulnerability has been resolved:

net_sched: ets: Fix double list add in class with netem as child qdisc

As described in Gerrard's report [1], there are use cases where a netem child qdisc will make the parent qdisc's enqueue callback reentrant. In the case of ets, there won't be a UAF, but the code will add the same classifier to the list twice, which will cause memory corruption.

In addition to checking for qlen being zero, this patch checks whether the class was already added to the activelist (clis_active) before doing the addition to cater for the reentrant case.

[1] https://lore.kernel.org/netdev/CAHcdcOm+03OD2j6R0=YHKqmy=VgJ8xEOKuP6c7mSgnp-TEJJbw@mail.gmail.com/(CVE-2025-37914)

In the Linux kernel, the following vulnerability has been resolved:

btrfs: adjust subpage bit start based on sectorsize

When running machines with 64k page size and a 16k nodesize we started seeing tree log corruption in production. This turned out to be because we were not writing out dirty blocks sometimes, so this in fact affects all metadata writes.

When writing out a subpage EB we scan the subpage bitmap for a dirty range. If the range isn't dirty we do

bit_start++;

to move onto the next bit. The problem is the bitmap is based on the number of sectors that an EB has. So in this case, we have a 64k pagesize, 16k nodesize, but a 4k sectorsize. This means our bitmap is 4 bits for every node. With a 64k page size we end up with 4 nodes per page.

To make this easier this is how everything looks

[0 16k 32k 48k ] logical address [0 4 8 12 ] radix tree offset [ 64k page ] folio [ 16k eb ][ 16k eb ][ 16k eb ][ 16k eb ] extent buffers [ | | | | | | | | | | | | | | | | ] bitmap

Now we use all of our addressing based on fsinfo->sectorsizebits, so as you can see the above our 16k eb->start turns into radix entry 4.

When we find a dirty range for our eb, we correctly do bitstart += sectorsper_node, because if we start at bit 0, the next bit for the next eb is 4, to correspond to eb->start 16k.

However if our range is clean, we will do bit_start++, which will now put us offset from our radix tree entries.

In our case, assume that the first time we check the bitmap the block is not dirty, we increment bit_start so now it == 1, and then we loop around and check again. This time it is dirty, and we go to find that start using the following equation

start = folio_start + bit_start * fs_info->sectorsize;

so in the case above, eb->start 0 is now dirty, and we calculate start as

0 + 1 * fs_info->sectorsize = 4096
4096 >> 12 = 1

Now we're looking up the radix tree for 1, and we won't find an eb. What's worse is now we're using bitstart == 1, so we do bitstart += sectorspernode, which is now 5. If that eb is dirty we will run into the same thing, we will look at an offset that is not populated in the radix tree, and now we're skipping the writeout of dirty extent buffers.

The best fix for this is to not use sectorsizebits to address nodes, but that's a larger change. Since this is a fs corruption problem fix it simply by always using sectorsper_node to increment the start bit.(CVE-2025-37931)

In the Linux kernel, the following vulnerability has been resolved:

bus: fsl-mc: fix double-free on mc_dev

The blamed commit tried to simplify how the deallocations are done but, in the process, introduced a double-free on the mc_dev variable.

In case the MC device is a DPRC, a new mcbus is allocated and the mcdev variable is just a reference to one of its fields. In this circumstance, on the error path only the mc_bus should be freed.

This commit introduces back the following checkpatch warning which is a false-positive.

WARNING: kfree(NULL) is safe and this check is probably not required + if (mcbus) + kfree(mcbus);(CVE-2025-38313)

In the Linux kernel, the following vulnerability has been resolved:

f2fs: fix to bail out in getnewsegment()

------------[ cut here ]------------ WARNING: CPU: 3 PID: 579 at fs/f2fs/segment.c:2832 newcurseg+0x5e8/0x6dc pc : newcurseg+0x5e8/0x6dc Call trace: newcurseg+0x5e8/0x6dc f2fsallocatedatablock+0xa54/0xe28 dowritepage+0x6c/0x194 f2fsdowritenodepage+0x38/0x78 _writenodepage+0x248/0x6d4 f2fssyncnodepages+0x524/0x72c f2fswritecheckpoint+0x4bc/0x9b0 _checkpointandcompletereqs+0x80/0x244 issuecheckpointthread+0x8c/0xec kthread+0x114/0x1bc retfromfork+0x10/0x20

getnewsegment() detects inconsistent status in between freesegmap and freesecmap, let's record such error into super block, and bail out getnewsegment() instead of continue using the segment.(CVE-2025-38333)

In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix GCCGCCPCIEHOTRST definition for WCN7850

GCCGCCPCIEHOTRST is wrongly defined for WCN7850, causing kernel crash on some specific platforms.

Since this register is divergent for WCN7850 and QCN9274, move it to register table to allow different definitions. Then correct the register address for WCN7850 to fix this issue.

Note IPQ5332 is not affected as it is not PCIe based device.

Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPLV1.0V2.0_SILICONZ-3(CVE-2025-38414)

In the Linux kernel, the following vulnerability has been resolved:

fs/ntfs3: cancle set bad inode after removing name fails

The reproducer uses a file0 on a ntfs3 file system with a corrupted i_link. When renaming, the file0's inode is marked as a bad inode because the file name cannot be deleted.

The underlying bug is that makebadinode() is called on a live inode. In some cases it's "icache lookup finds a normal inode, dsplicealias() is called to attach it to dentry, while another thread decides to call makebadinode() on it - that would evict it from icache, but we'd already found it there earlier". In some it's outright "we have an inode attached to dentry - that's how we got it in the first place; let's call makebadinode() on it just for shits and giggles".(CVE-2025-38615)

In the Linux kernel, the following vulnerability has been resolved:

scsi: libiscsi: Initialize iscsiconn->dddata only if memory is allocated

In case of an ibfastregmr allocation failure during iSER setup, the machine hits a panic because iscsiconn->dddata is initialized unconditionally, even when no memory is allocated (ddsize == 0). This leads invalid pointer dereference during connection teardown.

Fix by setting iscsiconn->dddata only if memory is actually allocated.

Panic trace:

iser: isercreatefastregdesc: Failed to allocate ibfastregmr err=-12 iser: iserallocrxdescriptors: failed allocating rx descriptors / data buffers BUG: unable to handle page fault for address: fffffffffffffff8 RIP: 0010:swakeuplocked.part.5+0xa/0x40 Call Trace: complete+0x31/0x40 iscsiiserconnstop+0x88/0xb0 [ibiser] iscsistopconn+0x66/0xc0 [scsitransportiscsi] iscsiifstopconn+0x14a/0x150 [scsitransportiscsi] iscsiifrx+0x1135/0x1834 [scsitransportiscsi] ? netlinklookup+0x12f/0x1b0 ? netlinkdelivertap+0x2c/0x200 netlinkunicast+0x1ab/0x280 netlinksendmsg+0x257/0x4f0 ? _copyfromuser+0x29/0x60 socksendmsg+0x5f/0x70(CVE-2025-38700)

In the Linux kernel, the following vulnerability has been resolved:

ext4: do not BUG when INLINEDATAFL lacks system.data xattr

A syzbot fuzzed image triggered a BUGON in ext4updateinlinedata() when an inode had the INLINEDATAFL flag set but was missing the system.data extended attribute.

Since this can happen due to a maiciouly fuzzed file system, we shouldn't BUG, but rather, report it as a corrupted file system.

Add similar replacements of BUGON with EXT4ERRORINODE() ii ext4createinlinedata() and ext4inlinedata_truncate().(CVE-2025-38701)

In the Linux kernel, the following vulnerability has been resolved:

loop: Avoid updating block size under exclusive owner

Syzbot came up with a reproducer where a loop device block size is changed underneath a mounted filesystem. This causes a mismatch between the block device block size and the block size stored in the superblock causing confusion in various places such as fs/buffer.c. The particular issue triggered by syzbot was a warning in _getblkslow() due to requested buffer size not matching block device block size.

Fix the problem by getting exclusive hold of the loop device to change its block size. This fails if somebody (such as filesystem) has already an exclusive ownership of the block device and thus prevents modifying the loop device under some exclusive owner which doesn't expect it.(CVE-2025-38709)

In the Linux kernel, the following vulnerability has been resolved:

fs/buffer: fix use-after-free when call bh_read() helper

There's issue as follows: BUG: KASAN: stack-out-of-bounds in endbufferreadsync+0xe3/0x110 Read of size 8 at addr ffffc9000168f7f8 by task swapper/3/0 CPU: 3 UID: 0 PID: 0 Comm: swapper/3 Not tainted 6.16.0-862.14.0.6.x8664 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <IRQ> dumpstacklvl+0x55/0x70 printaddressdescription.constprop.0+0x2c/0x390 printreport+0xb4/0x270 kasanreport+0xb8/0xf0 endbufferreadsync+0xe3/0x110 endbiobhiosync+0x56/0x80 blkupdaterequest+0x30a/0x720 scsiendrequest+0x51/0x2b0 scsiiocompletion+0xe3/0x480 ? scsideviceunbusy+0x11e/0x160 blkcompletereqs+0x7b/0x90 handlesoftirqs+0xef/0x370 irqexitrcu+0xa5/0xd0 sysvecapictimer_interrupt+0x6e/0x90 </IRQ>

Above issue happens when do ntfs3 filesystem mount, issue may happens as follows: mount IRQ ntfsfillsuper readcachepage doreadcachefolio filemapreadfolio mpagereadfolio dompagereadpage ntfsgetblockvbo bhread submitbh waitonbuffer(bh); blkcompletereqs scsiiocompletion scsiendrequest blkupdaterequest endbiobhiosync endbufferreadsync _endbufferreadnotouch unlockbuffer

        wait_on_buffer(bh);--> return will return to caller

                  put_bh
                    --> trigger stack-out-of-bounds

In the mpagereadfolio() function, the stack variable 'mapbh' is passed to ntfsgetblockvbo(). Once unlockbuffer() unlocks and waitonbuffer() returns to continue processing, the stack variable is likely to be reclaimed. Consequently, during the endbufferreadsync() process, calling put_bh() may result in stack overrun.

If the bh is not allocated on the stack, it belongs to a folio. Freeing a buffer head which belongs to a folio is done by dropbuffers() which will fail to free buffers which are still locked. So it is safe to call putbh() before _endbufferreadnotouch().(CVE-2025-39691)

In the Linux kernel, the following vulnerability has been resolved:

soc: qcom: mdt_loader: Ensure we don't read past the ELF header

When the MDT loader is used in remoteproc, the ELF header is sanitized beforehand, but that's not necessary the case for other clients.

Validate the size of the firmware buffer to ensure that we don't read past the end as we iterate over the header. ephentsize and eshentsize are validated as well, to ensure that the assumptions about step size in the traversal are valid.(CVE-2025-39787)

In the Linux kernel, the following vulnerability has been resolved:

block: avoid possible overflow for chunksectors check in blkstack_limits()

In blkstacklimits(), we check that the t->chunksectors value is a multiple of the t->physicalblock_size value.

However, by finding the chunksectors value in bytes, we may overflow the unsigned int which holds chunksectors, so change the check to be based on sectors.(CVE-2025-39795)

In the Linux kernel, the following vulnerability has been resolved:

pcmcia: Add error handling for addinterval() in dovalidate_mem()

In the dovalidatemem(), the call to addinterval() does not handle errors. If kmalloc() fails in addinterval(), it could result in a null pointer being inserted into the linked list, leading to illegal memory access when sub_interval() is called next.

This patch adds an error handling for the addinterval(). If addinterval() returns an error, the function will return early with the error code.(CVE-2025-39920)

In the Linux kernel, the following vulnerability has been resolved:

dmaengine: qcom: bam_dma: Fix DT error handling for num-channels/ees

When we don't have a clock specified in the device tree, we have no way to ensure the BAM is on. This is often the case for remotely-controlled or remotely-powered BAM instances. In this case, we need to read num-channels from the DT to have all the necessary information to complete probing.

However, at the moment invalid device trees without clock and without num-channels still continue probing, because the error handling is missing return statements. The driver will then later try to read the number of channels from the registers. This is unsafe, because it relies on boot firmware and lucky timing to succeed. Unfortunately, the lack of proper error handling here has been abused for several Qualcomm SoCs upstream, causing early boot crashes in several situations [1, 2].

Avoid these early crashes by erroring out when any of the required DT properties are missing. Note that this will break some of the existing DTs upstream (mainly BAM instances related to the crypto engine). However, clearly these DTs have never been tested properly, since the error in the kernel log was just ignored. It's safer to disable the crypto engine for these broken DTBs.

In the Linux kernel i40e driver, there is a security vulnerability: the driver lacks boundary checks for the maximum number of virtual function (VF) filters. An attacker could potentially exploit this vulnerability to request filter counts beyond the boundaries, leading to potential security issues.(CVE-2025-39968)

In the Linux kernel, the following vulnerability has been resolved: i40e: fix idx validation in config queues msg. Ensure idx is within range of active/initialized TCs when iterating over vf->ch[idx] in i40evcconfigqueuesmsg().(CVE-2025-39971)

In the Linux kernel, the following vulnerability has been resolved:

x86/mce: use iscopyfrom_user() to determine copy-from-user context

Patch series "mm/hwpoison: Fix regressions in memory failure handling", v4.

1. What am I trying to do:

This patchset resolves two critical regressions related to memory failure handling that have appeared in the upstream kernel since version 5.17, as compared to 5.10 LTS.

- copyin case: poison found in user page while kernel copying from user space
- instr case: poison found while instruction fetching in user space

2. What is the expected outcome and why

• For copyin case:

Kernel can recover from poison found where kernel is doing getuser() or copyfromuser() if those places get an error return and the kernel return -EFAULT to the process instead of crashing. More specifily, MCE handler checks the fixup handler type to decide whether an in kernel #MC can be recovered. When EXTYPEUACCESS is found, the PC jumps to recovery code specified in _ASMEXTABLE_FAULT() and return a -EFAULT to user space.

• For instr case:

If a poison found while instruction fetching in user space, full recovery is possible. User process takes #PF, Linux allocates a new page and fills by reading from storage.

3. What actually happens and why

• For copyin case: kernel panic since v5.17

Commit 4c132d1d844a ("x86/futex: Remove .fixup usage") introduced a new extable fixup type, EXTYPEEFAULTREG, and later patches updated the extable fixup type for copy-from-user operations, changing it from EXTYPEUACCESS to EXTYPEEFAULTREG. It breaks previous EXTYPEUACCESS handling when posion found in getuser() or copyfrom_user().

• For instr case: user process is killed by a SIGBUS signal due to #CMCI and #MCE race

When an uncorrected memory error is consumed there is a race between the CMCI from the memory controller reporting an uncorrected error with a UCNA signature, and the core reporting and SRAR signature machine check when the data is about to be consumed.

Background: why UNcorrected errors tied to CMCI in Intel platform [1]

Prior to Icelake memory controllers reported patrol scrub events that detected a previously unseen uncorrected error in memory by signaling a broadcast machine check with an SRAO (Software Recoverable Action Optional) signature in the machine check bank. This was overkill because it's not an urgent problem that no core is on the verge of consuming that bad data. It's also found that multi SRAO UCE may cause nested MCE interrupts and finally become an IERR.

Hence, Intel downgrades the machine check bank signature of patrol scrub from SRAO to UCNA (Uncorrected, No Action required), and signal changed to

CMCI. Just to add to the confusion, Linux does take an action (in

ucdecodenotifier()) to try to offline the page despite the UCNA signature name.

Background: why #CMCI and #MCE race when poison is consuming in

Intel platform [1]

Having decided that CMCI/UCNA is the best action for patrol scrub errors, the memory controller uses it for reads too. But the memory controller is executing asynchronously from the core, and can't tell the difference between a "real" read and a speculative read. So it will do CMCI/UCNA if an error is found in any read.

Thus:

1) Core is clever and thinks address A is needed soon, issues a speculative read.

2) Core finds it is going to use address A soon after sending the read request

3) The CMCI from the memory controller is in a race with MCE from the core that will soon try to retire the load from address A.

Quite often (because speculation has got better) the CMCI from the memory controller is delivered before the core is committed to the instruction reading address A, so the interrupt is taken, and Linux offlines the page (marking it as poison).

Why user process is killed for instr case

Commit 046545a661af ("mm/hwpoison: fix error page recovered but reported "not ---truncated---(CVE-2025-39989)