The Linux Kernel, the operating system core itself.

Security Fix(es):

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

can: dev: cangetechoskb(): prevent call to kfreeskb() in hard IRQ context

If a driver calls cangetechoskb() during a hardware IRQ (which is often, but not always, the case), the 'WARNON(inirq)' in net/core/skbuff.c#skbreleaseheadstate() might be triggered, under network congestion circumstances, together with the potential risk of a NULL pointer dereference.

The root cause of this issue is the call to kfreeskb() instead of devkfreeskbirq() in net/core/dev.c#enqueuetobacklog().

This patch prevents the skb to be freed within the call to netifrx() by incrementing its reference count with skbget(). The skb is finally freed by one of the in-irq-context safe functions: devconsumeskbany() or devkfreeskbany(). The "any" version is used because some drivers might call cangetecho_skb() in a normal context.

The reason for this issue to occur is that initially, in the core network stack, loopback skb were not supposed to be received in hardware IRQ context. The CAN stack is an exeption.

This bug was previously reported back in 2017 in [1] but the proposed patch never got accepted.

While [1] directly modifies net/core/dev.c, we try to propose here a smoother modification local to CAN network stack (the assumption behind is that only CAN devices are affected by this issue).

[1] http://lore.kernel.org/r/57a3ffb6-3309-3ad5-5a34-e93c3fe3614d@cetitec.com(CVE-2020-36789)

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

video: fbdev: cirrusfb: check pixclock to avoid divide by zero

Do a sanity check on pixclock value to avoid divide by zero.

If the pixclock value is zero, the cirrusfb driver will round up pixclock to get the derived frequency as close to maxclock as possible.

Syzkaller reported a divide error in cirrusfbcheckpixclock.

divide error: 0000 [#1] SMP KASAN PTI CPU: 0 PID: 14938 Comm: cirrusfbtest Not tainted 5.15.0-rc6 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2 RIP: 0010:cirrusfbcheck_var+0x6f1/0x1260

Call Trace: fbsetvar+0x398/0xf90 dofbioctl+0x4b8/0x6f0 fbioctl+0xeb/0x130 _x64sysioctl+0x19d/0x220 dosyscall64+0x3a/0x80 entrySYSCALL64afterhwframe+0x44/0xae(CVE-2021-47641)

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

can: dev: can_restart: fix use after free bug

After calling netifrxni(skb), dereferencing skb is unsafe. Especially, the canframe cf which aliases skb memory is accessed after the netifrxni() in: stats->rxbytes += cf->len;

Reordering the lines solves the issue.(CVE-2021-47668)

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

can: peak_usb: fix use after free bugs

After calling peakusbnetifrxni(skb), dereferencing skb is unsafe. Especially, the canframe cf which aliases skb memory is accessed after the peakusbnetifrx_ni().

Reordering the lines solves the issue.(CVE-2021-47670)

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

qede: confirm skb is allocated before using

qedebuildskb() assumes buildskb() always works and goes straight to skbreserve(). However, build_skb() can fail under memory pressure. This results in a kernel panic because the skb to reserve is NULL.

Add a check in case build_skb() failed to allocate and return NULL.

The NULL return is handled correctly in callers to qedebuildskb().(CVE-2022-49084)

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

net: openvswitch: fix leak of nested actions

While parsing user-provided actions, openvswitch module may dynamically allocate memory and store pointers in the internal copy of the actions. So this memory has to be freed while destroying the actions.

Currently there are only two such actions: ct() and set(). However, there are many actions that can hold nested lists of actions and ovsnlafreeflowactions() just jumps over them leaking the memory.

For example, removal of the flow with the following actions will lead to a leak of the memory allocated by nfcttmpl_alloc():

actions:clone(ct(commit),0)

Non-freed set() action may also leak the 'dst' structure for the tunnel info including device references.

Under certain conditions with a high rate of flow rotation that may cause significant memory leak problem (2MB per second in reporter's case). The problem is also hard to mitigate, because the user doesn't have direct control over the datapath flows generated by OVS.

Fix that by iterating over all the nested actions and freeing everything that needs to be freed recursively.

New build time assertion should protect us from this problem if new actions will be added in the future.

Unfortunately, openvswitch module doesn't use NLAFNESTED, so all attributes has to be explicitly checked. sample() and clone() actions are mixing extra attributes into the user-provided action list. That prevents some code generalization too.(CVE-2022-49086)

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

scsi: pm8001: Fix abort all task initialization

In pm80xxsendabortall(), the nelem field of the ccb used is not initialized to 0. This missing initialization sometimes lead to the task completion path seeing the ccb with a non-zero nelem resulting in the execution of invalid dmaunmapsg() calls in pm8001ccbtaskfree(), causing a crash such as:

[ 197.676341] RIP: 0010:iommudmaunmapsg+0x6d/0x280 [ 197.700204] RSP: 0018:ffff889bbcf89c88 EFLAGS: 00010012 [ 197.705485] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffffff83d0bda0 [ 197.712687] RDX: 0000000000000002 RSI: 0000000000000000 RDI: ffff88810dffc0d0 [ 197.719887] RBP: 0000000000000000 R08: 0000000000000000 R09: ffff8881c790098b [ 197.727089] R10: ffffed1038f20131 R11: 0000000000000001 R12: 0000000000000000 [ 197.734296] R13: ffff88810dffc0d0 R14: 0000000000000010 R15: 0000000000000000 [ 197.741493] FS: 0000000000000000(0000) GS:ffff889bbcf80000(0000) knlGS:0000000000000000 [ 197.749659] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 197.755459] CR2: 00007f16c1b42734 CR3: 0000000004814000 CR4: 0000000000350ee0 [ 197.762656] Call Trace: [ 197.765127] <IRQ> [ 197.767162] pm8001ccbtaskfree+0x5f1/0x820 [pm80xx] [ 197.772364] ? dorawspinunlock+0x54/0x220 [ 197.776680] pm8001mpitaskabortresp+0x2ce/0x4f0 [pm80xx] [ 197.782406] processoq+0xe85/0x7890 [pm80xx] [ 197.786817] ? lockacquire+0x194/0x490 [ 197.790697] ? handleirqevent+0x10e/0x1b0 [ 197.794920] ? mpisatacompletion+0x2d70/0x2d70 [pm80xx] [ 197.800378] ? _wakeupbit+0x100/0x100 [ 197.804340] ? lockisheldtype+0x98/0x110 [ 197.808565] pm80xxchipisr+0x94/0x130 [pm80xx] [ 197.813243] taskletactioncommon.constprop.0+0x24b/0x2f0 [ 197.818785] _dosoftirq+0x1b5/0x82d [ 197.822485] ? dorawspinunlock+0x54/0x220 [ 197.826799] _irqexitrcu+0x17e/0x1e0 [ 197.830678] irqexitrcu+0xa/0x20 [ 197.834114] commoninterrupt+0x78/0x90 [ 197.840051] </IRQ> [ 197.844236] <TASK> [ 197.848397] asmcommoninterrupt+0x1e/0x40

Avoid this issue by always initializing the ccb nelem field to 0 in pm8001sendabortall(), pm8001sendreadlog() and pm80xxsendabortall().(CVE-2022-49217)

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

drm/amd/display: Fix a NULL pointer dereference in amdgpudmconnectoraddcommon_modes()

In amdgpudmconnectoraddcommonmodes(), amdgpudmcreatecommonmode() is assigned to mode and is passed to drmmodeprobedadd() directly after that. drmmodeprobedadd() passes &mode->head to listaddtail(), and there is a dereference of it in listaddtail() without recoveries, which could lead to NULL pointer dereference on failure of amdgpudmcreatecommon_mode().

Fix this by adding a NULL check of mode.

This bug was found by a static analyzer.

Builds with 'make allyesconfig' show no new warnings, and our static analyzer no longer warns about this code.(CVE-2022-49232)

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

staging: rtl8712: fix uninit-value in r871xudrvinit()

When 'tmpU1b' returns from r8712read8(padapter, EE9346CR) is 0, 'mac[6]' will not be initialized.

BUG: KMSAN: uninit-value in r871xudrvinit+0x2d54/0x3070 drivers/staging/rtl8712/usbintf.c:541 r871xudrvinit+0x2d54/0x3070 drivers/staging/rtl8712/usbintf.c:541 usbprobeinterface+0xf19/0x1600 drivers/usb/core/driver.c:396 reallyprobe+0x653/0x14b0 drivers/base/dd.c:596 _driverprobedevice+0x3e9/0x530 drivers/base/dd.c:752 driverprobedevice drivers/base/dd.c:782 [inline] _deviceattachdriver+0x79f/0x1120 drivers/base/dd.c:899 busforeachdrv+0x2d6/0x3f0 drivers/base/bus.c:427 _deviceattach+0x593/0x8e0 drivers/base/dd.c:970 deviceinitialprobe+0x4a/0x60 drivers/base/dd.c:1017 busprobedevice+0x17b/0x3e0 drivers/base/bus.c:487 deviceadd+0x1fff/0x26e0 drivers/base/core.c:3405 usbsetconfiguration+0x37e9/0x3ed0 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0x13c/0x300 drivers/usb/core/generic.c:238 usbprobedevice+0x309/0x570 drivers/usb/core/driver.c:293 reallyprobe+0x653/0x14b0 drivers/base/dd.c:596 _driverprobedevice+0x3e9/0x530 drivers/base/dd.c:752 driverprobedevice drivers/base/dd.c:782 [inline] _deviceattachdriver+0x79f/0x1120 drivers/base/dd.c:899 busforeachdrv+0x2d6/0x3f0 drivers/base/bus.c:427 _deviceattach+0x593/0x8e0 drivers/base/dd.c:970 deviceinitialprobe+0x4a/0x60 drivers/base/dd.c:1017 busprobedevice+0x17b/0x3e0 drivers/base/bus.c:487 deviceadd+0x1fff/0x26e0 drivers/base/core.c:3405 usbnewdevice+0x1b8e/0x2950 drivers/usb/core/hub.c:2566 hubportconnect drivers/usb/core/hub.c:5358 [inline] hubportconnectchange drivers/usb/core/hub.c:5502 [inline] portevent drivers/usb/core/hub.c:5660 [inline] hubevent+0x58e3/0x89e0 drivers/usb/core/hub.c:5742 processonework+0xdb6/0x1820 kernel/workqueue.c:2307 workerthread+0x10b3/0x21e0 kernel/workqueue.c:2454 kthread+0x3c7/0x500 kernel/kthread.c:377 retfrom_fork+0x1f/0x30

Local variable mac created at: r871xudrvinit+0x1771/0x3070 drivers/staging/rtl8712/usbintf.c:394 usbprobe_interface+0xf19/0x1600 drivers/usb/core/driver.c:396

KMSAN: uninit-value in r871xudrvinit https://syzkaller.appspot.com/bug?id=3cd92b1d85428b128503bfa7a250294c9ae00bd8(CVE-2022-49298)

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

driver: base: fix UAF when driver_attach failed

When driverattach(drv); failed, the driverprivate will be freed. But it has been added to the bus, which caused a UAF.

To fix it, we need to delete it from the bus when failed.(CVE-2022-49385)

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

RDMA/hfi1: Prevent panic when SDMA is disabled

If the hfi1 module is loaded with HFI1CAPSDMA off, a call to hfi1writeiter() will dereference a NULL pointer and panic. A typical stack frame is:

sdmaselectuserengine [hfi1] hfi1usersdmaprocessrequest [hfi1] hfi1writeiter [hfi1] doiterreadvwritev doiterwrite vfswritev dowritev dosyscall64

The fix is to test for SDMA in hfi1writeiter() and fail the I/O with EINVAL.(CVE-2022-49429)

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

sfc: fix use after free when disabling sriov

Use after free is detected by kfence when disabling sriov. What was read after being freed was vf->pcidev: it was freed from pcidisablesriov and later read in efxef10sriovfreevfvports, called from efxef10sriovfreevf_vswitching.

Set the pointer to NULL at release time to not trying to read it later.

Reproducer and dmesg log (note that kfence doesn't detect it every time): $ echo 1 > /sys/class/net/enp65s0f0np0/device/sriovnumvfs $ echo 0 > /sys/class/net/enp65s0f0np0/device/sriovnumvfs

BUG: KFENCE: use-after-free read in efxef10sriovfreevf_vswitching+0x82/0x170 [sfc]

Use-after-free read at 0x00000000ff3c1ba5 (in kfence-#224): efxef10sriovfreevfvswitching+0x82/0x170 [sfc] efxef10pcisriovdisable+0x38/0x70 [sfc] efxpcisriovconfigure+0x24/0x40 [sfc] sriovnumvfsstore+0xfe/0x140 kernfsfopwriteiter+0x11c/0x1b0 newsyncwrite+0x11f/0x1b0 vfswrite+0x1eb/0x280 ksyswrite+0x5f/0xe0 dosyscall64+0x5c/0x80 entrySYSCALL64after_hwframe+0x44/0xae

kfence-#224: 0x00000000edb8ef95-0x00000000671f5ce1, size=2792, cache=kmalloc-4k

allocated by task 6771 on cpu 10 at 3137.860196s: pciallocdev+0x21/0x60 pciiovaddvirtfn+0x2a2/0x320 sriovenable+0x212/0x3e0 efxef10sriovconfigure+0x67/0x80 [sfc] efxpcisriovconfigure+0x24/0x40 [sfc] sriovnumvfsstore+0xba/0x140 kernfsfopwriteiter+0x11c/0x1b0 newsyncwrite+0x11f/0x1b0 vfswrite+0x1eb/0x280 ksyswrite+0x5f/0xe0 dosyscall64+0x5c/0x80 entrySYSCALL64after_hwframe+0x44/0xae

freed by task 6771 on cpu 12 at 3170.991309s: devicerelease+0x34/0x90 kobjectcleanup+0x3a/0x130 pciiovremovevirtfn+0xd9/0x120 sriovdisable+0x30/0xe0 efxef10pcisriovdisable+0x57/0x70 [sfc] efxpcisriovconfigure+0x24/0x40 [sfc] sriovnumvfsstore+0xfe/0x140 kernfsfopwriteiter+0x11c/0x1b0 newsyncwrite+0x11f/0x1b0 vfswrite+0x1eb/0x280 ksyswrite+0x5f/0xe0 dosyscall64+0x5c/0x80 entrySYSCALL64afterhwframe+0x44/0xae(CVE-2022-49626)

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

cgroup: Use separate src/dst nodes when preloading css_sets for migration

Each cset (cssset) is pinned by its tasks. When we're moving tasks around across csets for a migration, we need to hold the source and destination csets to ensure that they don't go away while we're moving tasks about. This is done by linking cset->mgpreloadnode on either the mgctx->preloadedsrccsets or mgctx->preloadeddstcsets list. Using the same cset->mgpreload_node for both the src and dst lists was deemed okay as a cset can't be both the source and destination at the same time.

Unfortunately, this overloading becomes problematic when multiple tasks are involved in a migration and some of them are identity noop migrations while others are actually moving across cgroups. For example, this can happen with the following sequence on cgroup1:

#1> mkdir -p /sys/fs/cgroup/misc/a/b #2> echo $$ > /sys/fs/cgroup/misc/a/cgroup.procs #3> RUNACOMMANDWHICHCREATESMULTIPLETHREADS & #4> PID=$! #5> echo $PID > /sys/fs/cgroup/misc/a/b/tasks #6> echo $PID > /sys/fs/cgroup/misc/a/cgroup.procs

the process including the group leader back into a. In this final migration, non-leader threads would be doing identity migration while the group leader is doing an actual one.

After #3, let's say the whole process was in cset A, and that after #4, the leader moves to cset B. Then, during #6, the following happens:

1. cgroupmigrateadd_src() is called on B for the leader.

2. cgroupmigrateadd_src() is called on A for the other threads.

3. cgroupmigrateprepare_dst() is called. It scans the src list.

4. It notices that B wants to migrate to A, so it tries to A to the dst list but realizes that its ->mgpreloadnode is already busy.

5. and then it notices A wants to migrate to A as it's an identity migration, it culls it by listdelinit()'ing its ->mgpreloadnode and putting references accordingly.

6. The rest of migration takes place with B on the src list but nothing on the dst list.

This means that A isn't held while migration is in progress. If all tasks leave A before the migration finishes and the incoming task pins it, the cset will be destroyed leading to use-after-free.

This is caused by overloading cset->mgpreloadnode for both src and dst preload lists. We wanted to exclude the cset from the src list but ended up inadvertently excluding it from the dst list too.

This patch fixes the issue by separating out cset->mgpreloadnode into ->mgsrcpreloadnode and ->mgdstpreloadnode, so that the src and dst preloadings don't interfere with each other.(CVE-2022-49647)

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

mm/khugepaged: fix ->anon_vma race

If an ->anonvma is attached to the VMA, collapseandfreepmd() requires it to be locked.

Page table traversal is allowed under any one of the mmap lock, the anonvma lock (if the VMA is associated with an anonvma), and the mapping lock (if the VMA is associated with a mapping); and so to be able to remove page tables, we must hold all three of them. retractpagetables() bails out if an ->anon_vma is attached, but does this check before holding the mmap lock (as the comment above the check explains).

If we racily merged an existing ->anon_vma (shared with a child process) from a neighboring VMA, subsequent rmap traversals on pages belonging to the child will be able to see the page tables that we are concurrently removing while assuming that nothing else can access them.

Repeat the ->anon_vma check once we hold the mmap lock to ensure that there really is no concurrent page table access.

Hitting this bug causes a lockdep warning in collapseandfreepmd(), in the line "lockdepassertheldwrite(&vma->anon_vma->root->rwsem)". It can also lead to use-after-free access.(CVE-2023-52935)

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

net: mdio: validate parameter addr in mdiobusgetphy()

The caller may pass any value as addr, what may result in an out-of-bounds access to array mdiomap. One existing case is stmmacinit_phy() that may pass -1 as addr. Therefore validate addr before using it.(CVE-2023-53019)

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

net: nfc: Fix use-after-free in local_cleanup()

Fix a use-after-free that occurs in kfreeskb() called from localcleanup(). This could happen when killing nfc daemon (e.g. neard) after detaching an nfc device. When detaching an nfc device, localcleanup() called from nfcllcpunregisterdevice() frees local->rxpending and decreases local->ref by krefput() in nfcllcplocalput(). In the terminating process, nfc daemon releases all sockets and it leads to decreasing local->ref. After the last release of local->ref, localcleanup() called from localrelease() frees local->rxpending again, which leads to the bug.

Setting local->rxpending to NULL in localcleanup() could prevent use-after-free when local_cleanup() is called twice.

Found by a modified version of syzkaller.

BUG: KASAN: use-after-free in kfree_skb()

Call Trace: dumpstacklvl (lib/dumpstack.c:106) printaddressdescription.constprop.0.cold (mm/kasan/report.c:306) kasancheckrange (mm/kasan/generic.c:189) kfreeskb (net/core/skbuff.c:955) localcleanup (net/nfc/llcpcore.c:159) nfcllcplocalput.part.0 (net/nfc/llcpcore.c:172) nfcllcplocalput (net/nfc/llcpcore.c:181) llcpsockdestruct (net/nfc/llcpsock.c:959) _skdestruct (net/core/sock.c:2133) skdestruct (net/core/sock.c:2181) _skfree (net/core/sock.c:2192) skfree (net/core/sock.c:2203) llcpsockrelease (net/nfc/llcpsock.c:646) _sockrelease (net/socket.c:650) sockclose (net/socket.c:1365) _fput (fs/filetable.c:306) taskworkrun (kernel/taskwork.c:179) ptracenotify (kernel/signal.c:2354) syscallexittousermodeprepare (kernel/entry/common.c:278) syscallexittousermode (kernel/entry/common.c:296) dosyscall64 (arch/x86/entry/common.c:86) entrySYSCALL64afterhwframe (arch/x86/entry/entry_64.S:106)

Allocated by task 4719: kasansavestack (mm/kasan/common.c:45) _kasanslaballoc (mm/kasan/common.c:325) slabpostallochook (mm/slab.h:766) kmemcacheallocnode (mm/slub.c:3497) _allocskb (net/core/skbuff.c:552) pn533recvresponse (drivers/nfc/pn533/usb.c:65) _usbhcdgivebackurb (drivers/usb/core/hcd.c:1671) usbgivebackurbbh (drivers/usb/core/hcd.c:1704) taskletactioncommon.isra.0 (kernel/softirq.c:797) _dosoftirq (kernel/softirq.c:571)

Freed by task 1901: kasansavestack (mm/kasan/common.c:45) kasansettrack (mm/kasan/common.c:52) kasansavefreeinfo (mm/kasan/genericdd.c:518) _kasanslabfree (mm/kasan/common.c:236) kmemcachefree (mm/slub.c:3809) kfreeskbmem (net/core/skbuff.c:874) kfreeskb (net/core/skbuff.c:931) localcleanup (net/nfc/llcpcore.c:159) nfcllcpunregisterdevice (net/nfc/llcpcore.c:1617) nfcunregisterdevice (net/nfc/core.c:1179) pn53xunregisternfc (drivers/nfc/pn533/pn533.c:2846) pn533usbdisconnect (drivers/nfc/pn533/usb.c:579) usbunbindinterface (drivers/usb/core/driver.c:458) devicereleasedriverinternal (drivers/base/dd.c:1279) busremovedevice (drivers/base/bus.c:529) devicedel (drivers/base/core.c:3665) usbdisabledevice (drivers/usb/core/message.c:1420) usbdisconnect (drivers/usb/core.c:2261) hubevent (drivers/usb/core/hub.c:5833) processonework (arch/x86/include/asm/jumplabel.h:27 include/linux/jumplabel.h:212 include/trace/events/workqueue.h:108 kernel/workqueue.c:2281) workerthread (include/linux/list.h:282 kernel/workqueue.c:2423) kthread (kernel/kthread.c:319) retfromfork (arch/x86/entry/entry64.S:301)(CVE-2023-53023)

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

netfilter: ipset: Fix overflow before widen in the bitmapipcreate() function.

When firstip is 0, lastip is 0xFFFFFFFF, and netmask is 31, the value of an arithmetic expression 2 << (netmask - mask_bits - 1) is subject to overflow due to a failure casting operands to a larger data type before performing the arithmetic.

Note that it's harmless since the value will be checked at the next step.

Found by InfoTeCS on behalf of Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-53032)

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

jfs: add check read-only before truncation in jfstruncatenolock()

Added a check for "read-only" mode in the jfs_truncate_nolock function to avoid errors related to writing to a read-only filesystem.

Call stack:

blockwritebegin() { jfswritefailed() { jfstruncate() { jfstruncatenolock() { txEnd() { ... log = JFSSBI(tblk->sb)->log; // (log == NULL)

If the isReadOnly(ip) condition is triggered in jfs_truncate_nolock, the function execution will stop, and no further data modification will occur. Instead, the xtTruncate function will be called with the "COMMIT_WMAP" flag, preventing modifications in "read-only" mode.(CVE-2024-58094)

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

ipv6: mcast: extend RCU protection in igmp6_send()

igmp6_send() can be called without RTNL or RCU being held.

Extend RCU protection so that we can safely fetch the net pointer and avoid a potential UAF.

Note that we no longer can use sockallocsendskb() because ipv6.igmpsk uses GFP_KERNEL allocations which can sleep.

Instead use allocskb() and charge the net->ipv6.igmpsk socket under RCU protection.(CVE-2025-21759)

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

ndisc: extend RCU protection in ndiscsendskb()

ndiscsendskb() can be called without RTNL or RCU held.

Acquire rcureadlock() earlier, so that we can use devnetrcu() and avoid a potential UAF.(CVE-2025-21760)

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

openvswitch: use RCU protection in ovsvportcmdfillinfo()

ovsvportcmdfillinfo() can be called without RTNL or RCU.

Use RCU protection and devnetrcu() to avoid potential UAF.(CVE-2025-21761)

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

arp: use RCU protection in arp_xmit()

arp_xmit() can be called without RTNL or RCU protection.

Use RCU protection to avoid potential UAF.(CVE-2025-21762)

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

neighbour: use RCU protection in _neighnotify()

_neighnotify() can be called without RTNL or RCU protection.

Use RCU protection to avoid potential UAF.(CVE-2025-21763)

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

ndisc: use RCU protection in ndiscallocskb()

ndiscallocskb() can be called without RTNL or RCU being held.

Add RCU protection to avoid possible UAF.(CVE-2025-21764)

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

iscsiibft: Fix UBSAN shift-out-of-bounds warning in ibftattrshownic()

When performing an iSCSI boot using IPv6, iscsistart still reads the /sys/firmware/ibft/ethernetX/subnet-mask entry. Since the IPv6 prefix length is 64, this causes the shift exponent to become negative, triggering a UBSAN warning. As the concept of a subnet mask does not apply to IPv6, the value is set to ~0 to suppress the warning message.(CVE-2025-21993)

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

net: atm: fix use after free in lec_send()

The ->send() operation frees skb so save the length before calling ->send() to avoid a use after free.(CVE-2025-22004)

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

tracing: Fix use-after-free in printgraphfunction_flags during tracer switching

Kairui reported a UAF issue in printgraphfunctionflags() during ftrace stress testing [1]. This issue can be reproduced if puting a 'mdelay(10)' after 'mutexunlock(&tracetypeslock)' in s_start(), and executing the following script:

$ echo functiongraph > currenttracer $ cat trace > /dev/null & $ sleep 5 # Ensure the 'cat' reaches the 'mdelay(10)' point $ echo timerlat > current_tracer

The root cause lies in the two calls to printgraphfunctionflags within printtraceline during each sshow():

• One through 'iter->trace->print_line()';
• Another through 'event->funcs->trace()', which is hidden in printtracefmt() before printtraceline returns.

Tracer switching only updates the former, while the latter continues to use the printline function of the old tracer, which in the script above is printgraphfunctionflags.

Moreover, when switching from the 'functiongraph' tracer to the 'timerlat' tracer, sstart only calls graphtraceclose of the 'function_graph' tracer to free 'iter->private', but does not set it to NULL. This provides an opportunity for 'event->funcs->trace()' to use an invalid 'iter->private'.

To fix this issue, set 'iter->private' to NULL immediately after freeing it in graphtraceclose(), ensuring that an invalid pointer is not passed to other tracers. Additionally, clean up the unnecessary 'iter->private = NULL' during each 'cat trace' when using wakeup and irqsoff tracers.

[1] https://lore.kernel.org/all/20231112150030.84609-1-ryncsn@gmail.com/(CVE-2025-22035)

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

net: fix geneve_opt length integer overflow

struct geneve_opt uses 5 bit length for each single option, which means every vary size option should be smaller than 128 bytes.

However, all current related Netlink policies cannot promise this length condition and the attacker can exploit a exact 128-byte size option to fake a zero length option and confuse the parsing logic, further achieve heap out-of-bounds read.

One example crash log is like below:

[ 3.905425] ================================================================== [ 3.905925] BUG: KASAN: slab-out-of-bounds in nlaput+0xa9/0xe0 [ 3.906255] Read of size 124 at addr ffff888005f291cc by task poc/177 [ 3.906646] [ 3.906775] CPU: 0 PID: 177 Comm: poc-oob-read Not tainted 6.1.132 #1 [ 3.907131] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 3.907784] Call Trace: [ 3.907925] <TASK> [ 3.908048] dumpstacklvl+0x44/0x5c [ 3.908258] printreport+0x184/0x4be [ 3.909151] kasanreport+0xc5/0x100 [ 3.909539] kasancheckrange+0xf3/0x1a0 [ 3.909794] memcpy+0x1f/0x60 [ 3.909968] nlaput+0xa9/0xe0 [ 3.910147] tunnelkeydump+0x945/0xba0 [ 3.911536] tcfactiondump1+0x1c1/0x340 [ 3.912436] tcfactiondump+0x101/0x180 [ 3.912689] tcfextsdump+0x164/0x1e0 [ 3.912905] fwdump+0x18b/0x2d0 [ 3.913483] tcffillnode+0x2ee/0x460 [ 3.914778] tfilternotify+0xf4/0x180 [ 3.915208] tcnewtfilter+0xd51/0x10d0 [ 3.918615] rtnetlinkrcvmsg+0x4a2/0x560 [ 3.919118] netlinkrcvskb+0xcd/0x200 [ 3.919787] netlinkunicast+0x395/0x530 [ 3.921032] netlinksendmsg+0x3d0/0x6d0 [ 3.921987] _socksendmsg+0x99/0xa0 [ 3.922220] _syssendto+0x1b7/0x240 [ 3.922682] _x64syssendto+0x72/0x90 [ 3.922906] dosyscall64+0x5e/0x90 [ 3.923814] entrySYSCALL64afterhwframe+0x6e/0xd8 [ 3.924122] RIP: 0033:0x7e83eab84407 [ 3.924331] Code: 48 89 fa 4c 89 df e8 38 aa 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 faf [ 3.925330] RSP: 002b:00007ffff505e370 EFLAGS: 00000202 ORIG_RAX: 000000000000002c [ 3.925752] RAX: ffffffffffffffda RBX: 00007e83eaafa740 RCX: 00007e83eab84407 [ 3.926173] RDX: 00000000000001a8 RSI: 00007ffff505e3c0 RDI: 0000000000000003 [ 3.926587] RBP: 00007ffff505f460 R08: 00007e83eace1000 R09: 000000000000000c [ 3.926977] R10: 0000000000000000 R11: 0000000000000202 R12: 00007ffff505f3c0 [ 3.927367] R13: 00007ffff505f5c8 R14: 00007e83ead1b000 R15: 00005d4fbbe6dcb8

Fix these issues by enforing correct length condition in related policies.(CVE-2025-22055)

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

udp: Fix memory accounting leak.

Matt Dowling reported a weird UDP memory usage issue.

Under normal operation, the UDP memory usage reported in /proc/net/sockstat remains close to zero. However, it occasionally spiked to 524,288 pages and never dropped. Moreover, the value doubled when the application was terminated. Finally, it caused intermittent packet drops.

We can reproduce the issue with the script below [0]:

1. /proc/net/sockstat reports 0 pages

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 1 mem 0

2. Run the script till the report reaches 524,288

   python3 test.py & sleep 5

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 3 mem 524288 <-- (INTMAX + 1) >> PAGESHIFT

3. Kill the socket and confirm the number never drops

   pkill python3 && sleep 5

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 1 mem 524288

4. (necessary since v6.0) Trigger protomemorypcpu_drain()

   python3 test.py & sleep 1 && pkill python3

5. The number doubles

   cat /proc/net/sockstat | grep UDP:

   UDP: inuse 1 mem 1048577

The application set INTMAX to SORCVBUF, which triggered an integer overflow in udprmemrelease().

When a socket is close()d, udpdestructcommon() purges its receive queue and sums up skb->truesize in the queue. This total is calculated and stored in a local unsigned integer variable.

The total size is then passed to udprmemrelease() to adjust memory accounting. However, because the function takes a signed integer argument, the total size can wrap around, causing an overflow.

Then, the released amount is calculated as follows:

1) Add size to sk->skforwardalloc. 2) Round down sk->skforwardalloc to the nearest lower multiple of PAGESIZE and assign it to amount. 3) Subtract amount from sk->skforwardalloc. 4) Pass amount >> PAGESHIFT to _skmemreduceallocated().

When the issue occurred, the total in udpdestructcommon() was 2147484480 (INTMAX + 833), which was cast to -2147482816 in udprmem_release().

At 1) sk->skforwardalloc is changed from 3264 to -2147479552, and 2) sets -2147479552 to amount. 3) reverts the wraparound, so we don't see a warning in inetsockdestruct(). However, udpmemoryallocated ends up doubling at 4).

Since commit 3cd3399dd7a8 ("net: implement per-cpu reserves for memoryallocated"), memory usage no longer doubles immediately after a socket is close()d because _skmemreduceallocated() caches the amount in udpmemorypercpufwalloc. However, the next time a UDP socket receives a packet, the subtraction takes effect, causing UDP memory usage to double.

This issue makes further memory allocation fail once the socket's sk->skrmemalloc exceeds net.ipv4.udprmemmin, resulting in packet drops.

To prevent this issue, let's use unsigned int for the calculation and call skforwardalloc_add() only once for the small delta.

Note that firstpacketlength() also potentially has the same problem.

SORCVBUFFORCE = 33 INTMAX = (2 ** 31) - 1

s = socket(AFINET, SOCKDGRAM) s.bind(('', 0)) s.setsockopt(SOLSOCKET, SORCVBUFFORCE, INT_MAX)

c = socket(AFINET, SOCKDGRAM) c.connect(s.getsockname())

data = b'a' * 100

while True: c.send(data)(CVE-2025-22058)

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

md/raid1,raid10: don't ignore IO flags

If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced.

Other than REQIDLE, other flags should not be ignored as well, for example REQMETA can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks.

Fix those problems by keep IO flags from master bio.

Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")(CVE-2025-22125)

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

ext4: fix OOB read when checking dotdot dir

Mounting a corrupted filesystem with directory which contains '.' dir entry with rec_len == block size results in out-of-bounds read (later on, when the corrupted directory is removed).

ext4emptydir() assumes every ext4 directory contains at least '.' and '..' as directory entries in the first data block. It first loads the '.' dir entry, performs sanity checks by calling ext4checkdirentry() and then uses its reclen member to compute the location of '..' dir entry (in ext4nextentry). It assumes the '..' dir entry fits into the same data block.

If the reclen of '.' is precisely one block (4KB), it slips through the sanity checks (it is considered the last directory entry in the data block) and leaves "struct ext4direntry2 *de" point exactly past the memory slot allocated to the data block. The following call to ext4checkdir_entry() on new value of de then dereferences this pointer which results in out-of-bounds mem access.

Fix this by extending _ext4checkdirentry() to check for '.' dir entries that reach the end of data block. Make sure to ignore the phony dir entries for checksum (by checking name_len for non-zero).

Note: This is reported by KASAN as use-after-free in case another structure was recently freed from the slot past the bound, but it is really an OOB read.

This issue was found by syzkaller tool.

Call Trace: [ 38.594108] BUG: KASAN: slab-use-after-free in ext4checkdirentry+0x67e/0x710 [ 38.594649] Read of size 2 at addr ffff88802b41a004 by task syz-executor/5375 [ 38.595158] [ 38.595288] CPU: 0 UID: 0 PID: 5375 Comm: syz-executor Not tainted 6.14.0-rc7 #1 [ 38.595298] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 38.595304] Call Trace: [ 38.595308] <TASK> [ 38.595311] dumpstacklvl+0xa7/0xd0 [ 38.595325] printaddressdescription.constprop.0+0x2c/0x3f0 [ 38.595339] ? _ext4checkdirentry+0x67e/0x710 [ 38.595349] printreport+0xaa/0x250 [ 38.595359] ? _ext4checkdirentry+0x67e/0x710 [ 38.595368] ? kasanaddrtoslab+0x9/0x90 [ 38.595378] kasanreport+0xab/0xe0 [ 38.595389] ? _ext4checkdirentry+0x67e/0x710 [ 38.595400] _ext4checkdirentry+0x67e/0x710 [ 38.595410] ext4emptydir+0x465/0x990 [ 38.595421] ? _pfxext4emptydir+0x10/0x10 [ 38.595432] ext4rmdir.part.0+0x29a/0xd10 [ 38.595441] ? _dquotinitialize+0x2a7/0xbf0 [ 38.595455] ? _pfxext4rmdir.part.0+0x10/0x10 [ 38.595464] ? _pfxdquotinitialize+0x10/0x10 [ 38.595478] ? downwrite+0xdb/0x140 [ 38.595487] ? _pfxdownwrite+0x10/0x10 [ 38.595497] ext4rmdir+0xee/0x140 [ 38.595506] vfsrmdir+0x209/0x670 [ 38.595517] ? lookuponeqstrexcl+0x3b/0x190 [ 38.595529] dormdir+0x363/0x3c0 [ 38.595537] ? _pfxdormdir+0x10/0x10 [ 38.595544] ? strncpyfromuser+0x1ff/0x2e0 [ 38.595561] _x64sysunlinkat+0xf0/0x130 [ 38.595570] dosyscall64+0x5b/0x180 [ 38.595583] entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2025-37785)