OESA-2025-1410

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

fs/ntfs3: Fix some memory leaks in an error handling path of 'log_replay()'

All error handling paths lead to 'out' where many resources are freed.

Do it as well here instead of a direct return, otherwise 'log', 'ra' and 'log->onepagebuf' (at least) will leak.(CVE-2021-47660)

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

list: fix a data-race around ep->rdllist

eppoll() first calls epeventsavailable() with no lock held and checks if ep->rdllist is empty by listempty_careful(), which reads rdllist->prev. Thus all accesses to it need some protection to avoid store/load-tearing.

Note INITLISTHEAD_RCU() already has the annotation for both prev and next.

Commit bf3b9f6372c4 ("epoll: Add busy poll support to epoll with socket fds.") added the first lockless epeventsavailable(), and commit c5a282e9635e ("fs/epoll: reduce the scope of wq lock in epollwait()") made some epeventsavailable() calls lockless and added single call under a lock, finally commit e59d3c64cba6 ("epoll: eliminate unnecessary lock for zero timeout") made the last epevents_available() lockless.

BUG: KCSAN: data-race in doepollwait / doepollwait

write to 0xffff88810480c7d8 of 8 bytes by task 1802 on cpu 0: INITLISTHEAD include/linux/list.h:38 [inline] listspliceinit include/linux/list.h:492 [inline] epstartscan fs/eventpoll.c:622 [inline] epsendevents fs/eventpoll.c:1656 [inline] eppoll fs/eventpoll.c:1806 [inline] doepollwait+0x4eb/0xf40 fs/eventpoll.c:2234 doepollpwait fs/eventpoll.c:2268 [inline] _dosysepollpwait fs/eventpoll.c:2281 [inline] _sesysepollpwait+0x12b/0x240 fs/eventpoll.c:2275 _x64sysepollpwait+0x74/0x80 fs/eventpoll.c:2275 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x44/0xd0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x44/0xae

read to 0xffff88810480c7d8 of 8 bytes by task 1799 on cpu 1: listemptycareful include/linux/list.h:329 [inline] epeventsavailable fs/eventpoll.c:381 [inline] eppoll fs/eventpoll.c:1797 [inline] doepollwait+0x279/0xf40 fs/eventpoll.c:2234 doepollpwait fs/eventpoll.c:2268 [inline] _dosysepollpwait fs/eventpoll.c:2281 [inline] _sesysepollpwait+0x12b/0x240 fs/eventpoll.c:2275 _x64sysepollpwait+0x74/0x80 fs/eventpoll.c:2275 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x44/0xd0 arch/x86/entry/common.c:80 entrySYSCALL64after_hwframe+0x44/0xae

value changed: 0xffff88810480c7d0 -> 0xffff888103c15098

Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 1799 Comm: syz-fuzzer Tainted: G W 5.17.0-rc7-syzkaller-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2022-49443)

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

cpufreq: governor: Use kobject release() method to free dbs_data

The struct dbsdata embeds a struct govattrset and the struct govattrset embeds a kobject. Since every kobject must have a release() method and we can't use kfree() to free it directly, so introduce cpufreqdbsdatarelease() to release the dbs_data via the kobject::release() method. This fixes the calltrace like below:

ODEBUG: free active (active state 0) object type: timerlist hint: delayedworktimerfn+0x0/0x34 WARNING: CPU: 12 PID: 810 at lib/debugobjects.c:505 debugprintobject+0xb8/0x100 Modules linked in: CPU: 12 PID: 810 Comm: sh Not tainted 5.16.0-next-20220120-yocto-standard+ #536 Hardware name: Marvell OcteonTX CN96XX board (DT) pstate: 60400009 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : debugprintobject+0xb8/0x100 lr : debugprintobject+0xb8/0x100 sp : ffff80001dfcf9a0 x29: ffff80001dfcf9a0 x28: 0000000000000001 x27: ffff0001464f0000 x26: 0000000000000000 x25: ffff8000090e3f00 x24: ffff80000af60210 x23: ffff8000094dfb78 x22: ffff8000090e3f00 x21: ffff0001080b7118 x20: ffff80000aeb2430 x19: ffff800009e8f5e0 x18: 0000000000000000 x17: 0000000000000002 x16: 00004d62e58be040 x15: 013590470523aff8 x14: ffff8000090e1828 x13: 0000000001359047 x12: 00000000f5257d14 x11: 0000000000040591 x10: 0000000066c1ffea x9 : ffff8000080d15e0 x8 : ffff80000a1765a8 x7 : 0000000000000000 x6 : 0000000000000001 x5 : ffff800009e8c000 x4 : ffff800009e8c760 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0001474ed040 Call trace: debugprintobject+0xb8/0x100 _debugchecknoobjfreed+0x1d0/0x25c debugchecknoobjfreed+0x24/0xa0 kfree+0x11c/0x440 cpufreqdbsgovernorexit+0xa8/0xac cpufreqexitgovernor+0x44/0x90 cpufreqsetpolicy+0x29c/0x570 storescalinggovernor+0x110/0x154 store+0xb0/0xe0 sysfskfwrite+0x58/0x84 kernfsfopwriteiter+0x12c/0x1c0 newsyncwrite+0xf0/0x18c vfswrite+0x1cc/0x220 ksyswrite+0x74/0x100 _arm64syswrite+0x28/0x3c invokesyscall.constprop.0+0x58/0xf0 doel0svc+0x70/0x170 el0svc+0x54/0x190 el0t64synchandler+0xa4/0x130 el0t64sync+0x1a0/0x1a4 irq event stamp: 189006 hardirqs last enabled at (189005): [<ffff8000080849d0>] finishtaskswitch.isra.0+0xe0/0x2c0 hardirqs last disabled at (189006): [<ffff8000090667a4>] el1dbg+0x24/0xa0 softirqs last enabled at (188966): [<ffff8000080106d0>] _dosoftirq+0x4b0/0x6a0 softirqs last disabled at (188957): [<ffff80000804a618>] _irqexit_rcu+0x108/0x1a4

rjw: Because can be freed by the govattrsetput() in cpufreqdbsgovernorexit() now, it is also necessary to put the invocation of the governor ->exit() callback into the new cpufreqdbsdata_release() function.

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

fs/ntfs3: validate BOOT sectorsperclusters

When the NTFS BOOT sectorsperclusters field is > 0x80, it represents a shift value. Make sure that the shift value is not too large before using it (NTFS max cluster size is 2MB). Return -EVINVAL if it too large.

This prevents negative shift values and shift values that are larger than the field size.

Prevents this UBSAN error:

UBSAN: shift-out-of-bounds in ../fs/ntfs3/super.c:673:16 shift exponent -192 is negative(CVE-2022-49553)

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

drm/drmvmamanager: Add drmvmanodeallowonce()

Currently there is no easy way for a drm driver to safely check and allow drmvmaoffsetnode for a drm file just once. Allow drm drivers to call non-refcounted version of drmvmanodeallow() so that a driver doesn't need to keep track of each drmvmanodeallow() to call subsequent drmvmanoderevoke() to prevent memory leak.(CVE-2023-53001)

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

tipc: Fix use-after-free of kernel socket in cleanup_bearer().

syzkaller reported a use-after-free of UDP kernel socket in cleanup_bearer() without repro. 0

When bearerdisable() calls tipcudpdisable(), cleanup of the UDP kernel socket is deferred by work calling cleanupbearer().

tipcexitnet() waits for such works to finish by checking tipcnet(net)->wqcount. However, the work decrements the count too early before releasing the kernel socket, unblocking cleanup_net() and resulting in use-after-free.

Let's move the decrement after releasing the socket in cleanup_bearer().

 sk_alloc+0x438/0x608
 inet_create+0x4c8/0xcb0
 __sock_create+0x350/0x6b8
 sock_create_kern+0x58/0x78
 udp_sock_create4+0x68/0x398
 udp_sock_create+0x88/0xc8
 tipc_udp_enable+0x5e8/0x848
 __tipc_nl_bearer_enable+0x84c/0xed8
 tipc_nl_bearer_enable+0x38/0x60
 genl_family_rcv_msg_doit+0x170/0x248
 genl_rcv_msg+0x400/0x5b0
 netlink_rcv_skb+0x1dc/0x398
 genl_rcv+0x44/0x68
 netlink_unicast+0x678/0x8b0
 netlink_sendmsg+0x5e4/0x898
 ____sys_sendmsg+0x500/0x830

BUG: KMSAN: use-after-free in udplibunhash+0x3b8/0x930 net/ipv4/udp.c:1979 udphashslot include/net/udp.h:85 [inline] udplibunhash+0x3b8/0x930 net/ipv4/udp.c:1979 skcommonrelease+0xaf/0x3f0 net/core/sock.c:3820 inetrelease+0x1e0/0x260 net/ipv4/afinet.c:437 inet6release+0x6f/0xd0 net/ipv6/afinet6.c:489 _sockrelease net/socket.c:658 [inline] sockrelease+0xa0/0x210 net/socket.c:686 cleanupbearer+0x42d/0x4c0 net/tipc/udpmedia.c:819 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xcaf/0x1c90 kernel/workqueue.c:3310 workerthread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 retfromfork+0x60/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry_64.S:244

Uninit was created at: slabfreehook mm/slub.c:2269 [inline] slabfree mm/slub.c:4580 [inline] kmemcachefree+0x207/0xc40 mm/slub.c:4682 netfree net/core/netnamespace.c:454 [inline] cleanupnet+0x16f2/0x19d0 net/core/netnamespace.c:647 processonework kernel/workqueue.c:3229 [inline] processscheduledworks+0xcaf/0x1c90 kernel/workqueue.c:3310 workerthread+0xf6c/0x1510 kernel/workqueue.c:3391 kthread+0x531/0x6b0 kernel/kthread.c:389 retfromfork+0x60/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x11/0x20 arch/x86/entry/entry64.S:244

CPU: 0 UID: 0 PID: 54 Comm: kworker/0:2 Not tainted 6.12.0-rc1-00131-gf66ebf37d69c #7 91723d6f74857f70725e1583cba3cf4adc716cfa Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 Workqueue: events cleanup_bearer(CVE-2024-56642)

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

bpf, sockmap: Fix race between element replace and close()

Element replace (with a socket different from the one stored) may race with socket's close() link popping & unlinking. _sockmap_delete() unconditionally unrefs the (wrong) element:

// set map[0] = s0 mapupdateelem(map, 0, s0)

// drop fd of s0 close(s0) sockmapclose() locksock(sk) (s0!) sockmapremovelinks(sk) link = skpsocklinkpop() sockmapunlink(sk, link) sockmapdeletefromlink // replace map[0] with s1 mapupdateelem(map, 0, s1) sockmapupdateelem (s1!) locksock(sk) sockmapupdatecommon psock = skpsock(sk) spinlock(&stab->lock) osk = stab->sks[idx] sockmapaddlink(..., &stab->sks[idx]) sockmapunref(osk, &stab->sks[idx]) psock = skpsock(osk) skpsockput(sk, psock) if (refcountdecandtest(&psock)) skpsockdrop(sk, psock) spinunlock(&stab->lock) unlocksock(sk) _sockmapdelete spinlock(&stab->lock) sk = *psk // s1 replaced s0; sk == s1 if (!sktest || sktest == sk) // sktest (s0) != sk (s1); no branch sk = xchg(psk, NULL) if (sk) sockmapunref(sk, psk) // unref s1; sks[idx] will dangle psock = skpsock(sk) skpsockput(sk, psock) if (refcountdecandtest()) skpsockdrop(sk, psock) spinunlock(&stab->lock) releasesock(sk)

Then close(map) enqueues bpfmapfreedeferred, which finally calls sockmapfree(). This results in some refcountt warnings along with a KASAN splat [1].

Fix _sockmapdelete(), do not allow sockmap_unref() on elements that may have been replaced.

Write of size 4 at addr ffff88811f5b9100 by task kworker/u64:12/1063

CPU: 14 UID: 0 PID: 1063 Comm: kworker/u64:12 Not tainted 6.12.0+ #125 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014 Workqueue: eventsunbound bpfmapfreedeferred Call Trace: <TASK> dumpstacklvl+0x68/0x90 printreport+0x174/0x4f6 kasanreport+0xb9/0x190 kasancheckrange+0x10f/0x1e0 sockmapfree+0x10e/0x330 bpfmapfreedeferred+0x173/0x320 processonework+0x846/0x1420 workerthread+0x5b3/0xf80 kthread+0x29e/0x360 retfromfork+0x2d/0x70 retfromfork_asm+0x1a/0x30 </TASK>

Allocated by task 1202: kasansavestack+0x1e/0x40 kasansavetrack+0x10/0x30 _kasanslaballoc+0x85/0x90 kmemcacheallocnoprof+0x131/0x450 skprotalloc+0x5b/0x220 skalloc+0x2c/0x870 unixcreate1+0x88/0x8a0 unixcreate+0xc5/0x180 _sockcreate+0x241/0x650 _syssocketpair+0x1ce/0x420 _x64syssocketpair+0x92/0x100 dosyscall64+0x93/0x180 entrySYSCALL64afterhwframe+0x76/0x7e

Freed by task 46: kasansavestack+0x1e/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x60 _kasanslabfree+0x4b/0x70 kmemcachefree+0x1a1/0x590 _skdestruct+0x388/0x5a0 skpsockdestroy+0x73e/0xa50 processonework+0x846/0x1420 workerthread+0x5b3/0xf80 kthread+0x29e/0x360 retfromfork+0x2d/0x70 retfromforkasm+0x1a/0x30

The bu ---truncated---(CVE-2024-56664)

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

hrtimers: Handle CPU state correctly on hotplug

Consider a scenario where a CPU transitions from CPUHPONLINE to halfway through a CPU hotunplug down to CPUHPHRTIMERSPREPARE, and then back to CPUHPONLINE:

Since hrtimerspreparecpu() does not run, cpubase.hresactive remains set to 1 throughout. However, during a CPU unplug operation, the tick and the clockevents are shut down at CPUHPAPTICKDYING. On return to the online state, for instance CFS incorrectly assumes that the hrtick is already active, and the chance of the clockevent device to transition to oneshot mode is also lost forever for the CPU, unless it goes back to a lower state than CPUHPHRTIMERS_PREPARE once.

This round-trip reveals another issue; cpubase.online is not set to 1 after the transition, which appears as a WARNONONCE in enqueuehrtimer().

Aside of that, the bulk of the per CPU state is not reset either, which means there are dangling pointers in the worst case.

Address this by adding a corresponding startup() callback, which resets the stale per CPU state and sets the online flag.

tglx: Make the new callback unconditionally available, remove the online modification in the prepare() callback and clear the remaining state in the starting callback instead of the prepare callback

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

usb: gadget: f_tcm: Don't free command immediately

Don't prematurely free the command. Wait for the status completion of the sense status. It can be freed then. Otherwise we will double-free the command.(CVE-2024-58055)

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

net: davicom: fix UAF in dm9000drvremove

dm is netdev private data and it cannot be used after freenetdev() call. Using dm after freenetdev() can cause UAF bug. Fix it by moving free_netdev() at the end of the function.

This is similar to the issue fixed in commit ad297cd2db89 ("net: qcom/emac: fix UAF in emac_remove").

This bug is detected by our static analysis tool.(CVE-2025-21715)

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

net: rose: fix timer races against user threads

Rose timers only acquire the socket spinlock, without checking if the socket is owned by one user thread.

Add a check and rearm the timers if needed.

BUG: KASAN: slab-use-after-free in rosetimerexpiry+0x31d/0x360 net/rose/rose_timer.c:174 Read of size 2 at addr ffff88802f09b82a by task swapper/0/0

CPU: 0 UID: 0 PID: 0 Comm: swapper/0 Not tainted 6.13.0-rc5-syzkaller-00172-gd1bf27c4e176 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:378 [inline] printreport+0x169/0x550 mm/kasan/report.c:489 kasanreport+0x143/0x180 mm/kasan/report.c:602 rosetimerexpiry+0x31d/0x360 net/rose/rosetimer.c:174 calltimerfn+0x187/0x650 kernel/time/timer.c:1793 expiretimers kernel/time/timer.c:1844 [inline] _runtimers kernel/time/timer.c:2418 [inline] _runtimerbase+0x66a/0x8e0 kernel/time/timer.c:2430 runtimerbase kernel/time/timer.c:2439 [inline] runtimersoftirq+0xb7/0x170 kernel/time/timer.c:2449 handlesoftirqs+0x2d4/0x9b0 kernel/softirq.c:561 _dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] _irqexitrcu+0xf7/0x220 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1049 </IRQ>(CVE-2025-21718)

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

nilfs2: do not force clear folio if buffer is referenced

Patch series "nilfs2: protect busy buffer heads from being force-cleared".

This series fixes the buffer head state inconsistency issues reported by syzbot that occurs when the filesystem is corrupted and falls back to read-only, and the associated buffer head use-after-free issue.

This patch (of 2):

Syzbot has reported that after nilfs2 detects filesystem corruption and falls back to read-only, inconsistencies in the buffer state may occur.

One of the inconsistencies is that when nilfs2 calls markbufferdirty() to set a data or metadata buffer as dirty, but it detects that the buffer is not in the uptodate state:

WARNING: CPU: 0 PID: 6049 at fs/buffer.c:1177 markbufferdirty+0x2e5/0x520 fs/buffer.c:1177 ... Call Trace: <TASK> nilfspalloccommitallocentry+0x4b/0x160 fs/nilfs2/alloc.c:598 nilfsifilecreateinode+0x1dd/0x3a0 fs/nilfs2/ifile.c:73 nilfsnewinode+0x254/0x830 fs/nilfs2/inode.c:344 nilfsmkdir+0x10d/0x340 fs/nilfs2/namei.c:218 vfsmkdir+0x2f9/0x4f0 fs/namei.c:4257 domkdirat+0x264/0x3a0 fs/namei.c:4280 _dosysmkdirat fs/namei.c:4295 [inline] _sesysmkdirat fs/namei.c:4293 [inline] _x64sysmkdirat+0x87/0xa0 fs/namei.c:4293 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64after_hwframe+0x77/0x7f

The other is when nilfsbtreepropagate(), which propagates the dirty state to the ancestor nodes of a b-tree that point to a dirty buffer, detects that the origin buffer is not dirty, even though it should be:

WARNING: CPU: 0 PID: 5245 at fs/nilfs2/btree.c:2089 nilfsbtreepropagate+0xc79/0xdf0 fs/nilfs2/btree.c:2089 ... Call Trace: <TASK> nilfsbmappropagate+0x75/0x120 fs/nilfs2/bmap.c:345 nilfscollectfiledata+0x4d/0xd0 fs/nilfs2/segment.c:587 nilfssegctorapplybuffers+0x184/0x340 fs/nilfs2/segment.c:1006 nilfssegctorscanfile+0x28c/0xa50 fs/nilfs2/segment.c:1045 nilfssegctorcollectblocks fs/nilfs2/segment.c:1216 [inline] nilfssegctorcollect fs/nilfs2/segment.c:1540 [inline] nilfssegctordoconstruct+0x1c28/0x6b90 fs/nilfs2/segment.c:2115 nilfssegctorconstruct+0x181/0x6b0 fs/nilfs2/segment.c:2479 nilfssegctorthreadconstruct fs/nilfs2/segment.c:2587 [inline] nilfssegctorthread+0x69e/0xe80 fs/nilfs2/segment.c:2701 kthread+0x2f0/0x390 kernel/kthread.c:389 retfromfork+0x4b/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:244 </TASK>

Both of these issues are caused by the callbacks that handle the page/folio write requests, forcibly clear various states, including the working state of the buffers they hold, at unexpected times when they detect read-only fallback.

Fix these issues by checking if the buffer is referenced before clearing the page/folio state, and skipping the clear if it is.(CVE-2025-21722)

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

padata: avoid UAF for reorder_work

Although the previous patch can avoid ps and ps UAF for doserial, it can not avoid potential UAF issue for reorder_work. This issue can happen just as below:

cryptorequest cryptorequest cryptodelalg padatadoserial ... padata_reorder // processes all remaining // requests then breaks while (1) { if (!padata) break; ... }

            padata_do_serial
              // new request added
              list_add
// sees the new request
queue_work(reorder_work)
              padata_reorder
                queue_work_on(squeue->work)

...

            <kworker context>
            padata_serial_worker
            // completes new request,
            // no more outstanding
            // requests

                        crypto_del_alg
                          // free pd

<kworker context> invokepadatareorder // UAF of pd

To avoid UAF for 'reorderwork', get 'pd' ref before put 'reorderwork' into the 'serialwq' and put 'pd' ref until the 'serialwq' finish.(CVE-2025-21726)

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

padata: fix UAF in padata_reorder

A bug was found when run ltp test:

BUG: KASAN: slab-use-after-free in padatafindnext+0x29/0x1a0 Read of size 4 at addr ffff88bbfe003524 by task kworker/u113:2/3039206

CPU: 0 PID: 3039206 Comm: kworker/u113:2 Kdump: loaded Not tainted 6.6.0+ Workqueue: pdecryptparallel padataparallelworker Call Trace: <TASK> dumpstacklvl+0x32/0x50 printaddressdescription.constprop.0+0x6b/0x3d0 printreport+0xdd/0x2c0 kasanreport+0xa5/0xd0 padatafindnext+0x29/0x1a0 padatareorder+0x131/0x220 padataparallelworker+0x3d/0xc0 processonework+0x2ec/0x5a0

If 'mdelay(10)' is added before calling 'padatafindnext' in the 'padatareorder' function, this issue could be reproduced easily with ltp test (pcryptaead01).

This can be explained as bellow:

pcryptaeadencrypt ... padatadoparallel refcountinc(&pd->refcnt); // add refcnt ... padatadoserial padatareorder // pd while (1) { padatafindnext(pd, true); // using pd queueworkon ... padataserialworker cryptodelalg padataputpdcnt // sub refcnt padatafreeshell padataputpd(ps->pd); // pd is freed // loop again, but pd is freed // call padatafind_next, UAF }

In the padatareorder function, when it loops in 'while', if the alg is deleted, the refcnt may be decreased to 0 before entering 'padatafind_next', which leads to UAF.

As mentioned in [1], doserial is supposed to be called with BHs disabled and always happen under RCU protection, to address this issue, add synchronizercu() in 'padatafreeshell' wait for all doserial calls to finish.

[1] https://lore.kernel.org/all/20221028160401.cccypv4euxikusiq@parnassus.localdomain/ [2] https://lore.kernel.org/linux-kernel/jfjz5d7zwbytztackem7ibzalm5lnxldi2eofeiczqmqs2m7o6@fq426cwnjtkm/(CVE-2025-21727)

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

arm64: cacheinfo: Avoid out-of-bounds write to cacheinfo array

The loop that detects/populates cache information already has a bounds check on the array size but does not account for cache levels with separate data/instructions cache. Fix this by incrementing the index for any populated leaf (instead of any populated level).(CVE-2025-21785)

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

vrf: use RCU protection in l3mdevl3out()

l3mdevl3out() can be called without RCU being held:

rawsendmsg() ippushpendingframes() ipsendskb() iplocalout() _iplocalout() l3mdevip_out()

Add rcureadlock() / rcureadunlock() pair to avoid a potential UAF.(CVE-2025-21791)

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

PCI: rcar-ep: Fix incorrect variable used when calling devmrequestmem_region()

The rcarpcieparseoutboundranges() uses the devmrequestmem_region() macro to request a needed resource. A string variable that lives on the stack is then used to store a dynamically computed resource name, which is then passed on as one of the macro arguments. This can lead to undefined behavior.

Depending on the current contents of the memory, the manifestations of errors may vary. One possible output may be as follows:

$ cat /proc/iomem 30000000-37ffffff : 38000000-3fffffff :

Sometimes, garbage may appear after the colon.

In very rare cases, if no NULL-terminator is found in memory, the system might crash because the string iterator will overrun which can lead to access of unmapped memory above the stack.

Thus, fix this by replacing outbound_name with the name of the previously requested resource. With the changes applied, the output will be as follows:

$ cat /proc/iomem 30000000-37ffffff : memory2 38000000-3fffffff : memory3

kwilczynski: commit log

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

hrtimers: Force migrate away hrtimers queued after CPUHPAPHRTIMERS_DYING

hrtimers are migrated away from the dying CPU to any online target at the CPUHPAPHRTIMERS_DYING stage in order not to delay bandwidth timers handling tasks involved in the CPU hotplug forward progress.

However wakeups can still be performed by the outgoing CPU after CPUHPAPHRTIMERS_DYING. Those can result again in bandwidth timers being armed. Depending on several considerations (crystal ball power management based election, earliest timer already enqueued, timer migration enabled or not), the target may eventually be the current CPU even if offline. If that happens, the timer is eventually ignored.

The most notable example is RCU which had to deal with each and every of those wake-ups by deferring them to an online CPU, along with related workarounds:

_ e787644caf76 (rcu: Defer RCU kthreads wakeup when CPU is dying) _ 9139f93209d1 (rcu/nocb: Fix RT throttling hrtimer armed from offline CPU) _ f7345ccc62a4 (rcu/nocb: Fix rcuog wake-up from offline softirq)

The problem isn't confined to RCU though as the stop machine kthread (which runs CPUHPAPHRTIMERSDYING) reports its completion at the end of its work through cpustopsignaldone() and performs a wake up that eventually arms the deadline server timer:

WARNING: CPU: 94 PID: 588 at kernel/time/hrtimer.c:1086 hrtimerstartrangens+0x289/0x2d0 CPU: 94 UID: 0 PID: 588 Comm: migration/94 Not tainted Stopper: multicpustop+0x0/0x120 <- stopmachinecpuslocked+0x66/0xc0 RIP: 0010:hrtimerstartrangens+0x289/0x2d0 Call Trace: <TASK> startdltimer enqueuedlentity dlserverstart enqueuetaskfair enqueuetask ttwudoactivate trytowakeup complete cpustopperthread

Instead of providing yet another bandaid to work around the situation, fix it in the hrtimers infrastructure instead: always migrate away a timer to an online target whenever it is enqueued from an offline CPU.

This will also allow to revert all the above RCU disgraceful hacks.(CVE-2025-21816)

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

batman-adv: Drop unmanaged ELP metric worker

The ELP worker needs to calculate new metric values for all neighbors "reachable" over an interface. Some of the used metric sources require locks which might need to sleep. This sleep is incompatible with the RCU list iterator used for the recorded neighbors. The initial approach to work around of this problem was to queue another work item per neighbor and then run this in a new context.

Even when this solved the RCU vs might_sleep() conflict, it has a major problems: Nothing was stopping the work item in case it is not needed anymore - for example because one of the related interfaces was removed or the batman-adv module was unloaded - resulting in potential invalid memory accesses.

Directly canceling the metric worker also has various problems:

• cancelworksync for a to-be-deactivated interface is called with rtnllock held. But the code in the ELP metric worker also tries to use rtnllock() - which will never return in this case. This also means that cancelworksync would never return because it is waiting for the worker to finish.
• iterating over the neighbor list for the to-be-deactivated interface is currently done using the RCU specific methods. Which means that it is possible to miss items when iterating over it without the associated spinlock - a behaviour which is acceptable for a periodic metric check but not for a cleanup routine (which must "stop" all still running workers)

The better approch is to get rid of the per interface neighbor metric worker and handle everything in the interface worker. The original problems are solved by:

• creating a list of neighbors which require new metric information inside the RCU protected context, gathering the metric according to the new list outside the RCU protected context
• only use rcutrylock inside metric gathering code to avoid a deadlock when the canceldelayedworksync is called in the interface removal code (which is called with the rtnl_lock held)(CVE-2025-21823)

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

io_uring: prevent opcode speculation

sqe->opcode is used for different tables, make sure we santitise it against speculations.(CVE-2025-21863)

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

uprobes: Reject the shared zeropage in uprobewriteopcode()

We triggered the following crash in syzkaller tests:

BUG: Bad page state in process syz.7.38 pfn:1eff3 page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1eff3 flags: 0x3fffff00004004(referenced|reserved|node=0|zone=1|lastcpupid=0x1fffff) raw: 003fffff00004004 ffffe6c6c07bfcc8 ffffe6c6c07bfcc8 0000000000000000 raw: 0000000000000000 0000000000000000 00000000fffffffe 0000000000000000 page dumped because: PAGEFLAGSCHECKATFREE flag(s) set Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x32/0x50 badpage+0x69/0xf0 freeunrefpageprepare+0x401/0x500 freeunrefpage+0x6d/0x1b0 uprobewriteopcode+0x460/0x8e0 installbreakpoint.part.0+0x51/0x80 registerforeachvma+0x1d9/0x2b0 _uproberegister+0x245/0x300 bpfuprobemultilinkattach+0x29b/0x4f0 linkcreate+0x1e2/0x280 _sysbpf+0x75f/0xac0 _x64sysbpf+0x1a/0x30 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2

BUG: Bad rss-counter state mm:00000000452453e0 type:MM_FILEPAGES val:-1

The following syzkaller test case can be used to reproduce:

r2 = creat(&(0x7f0000000000)='./file0\x00', 0x8) write$nbd(r2, &(0x7f0000000580)=ANY=[], 0x10) r4 = openat(0xffffffffffffff9c, &(0x7f0000000040)='./file0\x00', 0x42, 0x0) mmap$IORINGOFFSQRING(&(0x7f0000ffd000/0x3000)=nil, 0x3000, 0x0, 0x12, r4, 0x0) r5 = userfaultfd(0x80801) ioctl$UFFDIOAPI(r5, 0xc018aa3f, &(0x7f0000000040)={0xaa, 0x20}) r6 = userfaultfd(0x80801) ioctl$UFFDIOAPI(r6, 0xc018aa3f, &(0x7f0000000140)) ioctl$UFFDIOREGISTER(r6, 0xc020aa00, &(0x7f0000000100)={{&(0x7f0000ffc000/0x4000)=nil, 0x4000}, 0x2}) ioctl$UFFDIOZEROPAGE(r5, 0xc020aa04, &(0x7f0000000000)={{&(0x7f0000ffd000/0x1000)=nil, 0x1000}}) r7 = bpf$PROGLOAD(0x5, &(0x7f0000000140)={0x2, 0x3, &(0x7f0000000200)=ANY=[@ANYBLOB="1800000000120000000000000000000095"], &(0x7f0000000000)='GPL\x00', 0x7, 0x0, 0x0, 0x0, 0x0, '\x00', 0x0, @fallback=0x30, 0xffffffffffffffff, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, @void, @value}, 0x94) bpf$BPFLINKCREATEXDP(0x1c, &(0x7f0000000040)={r7, 0x0, 0x30, 0x1e, @val=@uprobemulti={&(0x7f0000000080)='./file0\x00', &(0x7f0000000100)=[0x2], 0x0, 0x0, 0x1}}, 0x40)

The cause is that zero pfn is set to the PTE without increasing the RSS count in mfillatomicptezeropage() and the refcount of zero folio does not increase accordingly. Then, the operation on the same pfn is performed in uprobewriteopcode()->replacepage() to unconditional decrease the RSS count and old_folio's refcount.

Therefore, two bugs are introduced:

1. The RSS count is incorrect, when process exit, the check_mm() report error "Bad rss-count".

2. The reserved folio (zero folio) is freed when folio->refcount is zero, then freepagesprepare->freepageis_bad() report error "Bad page state".

There is more, the following warning could also theoretically be triggered:

_replacepage() -> ... -> folioremovermappte() -> VMWARNONFOLIO(iszerofolio(folio), folio)

Considering that uprobe hit on the zero folio is a very rare case, just reject zero old folio immediately after getuserpagevmaremote().

mingo: Cleaned up the changelog

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

ovl: fix UAF in ovldentryupdatereval by moving dput() in ovllink_up

The issue was caused by dput(upper) being called before ovldentryupdatereval(), while upper->dflags was still accessed in ovldentryremote().

Move dput(upper) after its last use to prevent use-after-free.

BUG: KASAN: slab-use-after-free in ovldentryremote fs/overlayfs/util.c:162 [inline] BUG: KASAN: slab-use-after-free in ovldentryupdate_reval+0xd2/0xf0 fs/overlayfs/util.c:167

Call Trace: <TASK> _dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 ovldentryremote fs/overlayfs/util.c:162 [inline] ovldentryupdatereval+0xd2/0xf0 fs/overlayfs/util.c:167 ovllinkup fs/overlayfs/copyup.c:610 [inline] ovlcopyupone+0x2105/0x3490 fs/overlayfs/copyup.c:1170 ovlcopyupflags+0x18d/0x200 fs/overlayfs/copyup.c:1223 ovlrename+0x39e/0x18c0 fs/overlayfs/dir.c:1136 vfsrename+0xf84/0x20a0 fs/namei.c:4893 ... </TASK>(CVE-2025-21887)

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

gpio: aggregator: protect driver attr handlers against module unload

Both newdevicestore and deletedevicestore touch module global resources (e.g. gpioaggregatorlock). To prevent race conditions with module unload, a reference needs to be held.

Add trymoduleget() in these handlers.

For newdevicestore, this eliminates what appears to be the most dangerous scenario: if an id is allocated from gpioaggregatoridr but platformdeviceregister has not yet been called or completed, a concurrent module unload could fail to unregister/delete the device, leaving behind a dangling platform device/GPIO forwarder. This can result in various issues. The following simple reproducer demonstrates these problems:

#!/bin/bash while :; do # note: whether 'gpiochip0 0' exists or not does not matter. echo 'gpiochip0 0' > /sys/bus/platform/drivers/gpio-aggregator/new_device done & while :; do modprobe gpio-aggregator modprobe -r gpio-aggregator done & wait

Starting with the following warning, several kinds of warnings will appear and the system may become unstable:

------------[ cut here ]------------ listdel corruption, ffff888103e2e980->next is LISTPOISON1 (dead000000000100) WARNING: CPU: 1 PID: 1327 at lib/listdebug.c:56 listdelentryvalidorreport+0xa3/0x120 [...] RIP: 0010:listdelentryvalidorreport+0xa3/0x120 [...] Call Trace: <TASK> ? _listdelentryvalidorreport+0xa3/0x120 ? _warn.cold+0x93/0xf2 ? _listdelentryvalidorreport+0xa3/0x120 ? reportbug+0xe6/0x170 ? _irqworkqueuelocal+0x39/0xe0 ? handlebug+0x58/0x90 ? excinvalidop+0x13/0x60 ? asmexcinvalidop+0x16/0x20 ? _listdelentryvalidorreport+0xa3/0x120 gpiodremovelookuptable+0x22/0x60 newdevicestore+0x315/0x350 [gpioaggregator] kernfsfopwriteiter+0x137/0x1f0 vfswrite+0x262/0x430 ksyswrite+0x60/0xd0 dosyscall64+0x6c/0x180 entrySYSCALL64afterhwframe+0x76/0x7e [...] </TASK> ---[ end trace 0000000000000000 ]---(CVE-2025-21943)