OESA-2025-1448

The Linux Kernel, the operating system core itself.

Security Fix(es):

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:

bnxt: Do not read past the end of test names

Test names were being concatenated based on a offset beyond the end of the first name, which tripped the buffer overflow detection logic:

detected buffer overflow in strnlen [...] Call Trace: bnxtethtoolinit.cold+0x18/0x18

Refactor struct hwrmselftestqlist_output to use an actual array, and adjust the concatenation to use snprintf() rather than a series of strncat() calls.(CVE-2023-53010)

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

drm/amdgpu: avoid buffer overflow attach in smusyssetpptable()

It malicious user provides a small pptable through sysfs and then a bigger pptable, it may cause buffer overflow attack in function smusyssetpptable().(CVE-2025-21780)

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

batman-adv: fix panic during interface removal

Reference counting is used to ensure that batadvhardifneighnode and batadvhardiface are not freed before/during batadvvelpthroughputmetricupdate work is finished.

But there isn't a guarantee that the hard if will remain associated with a soft interface up until the work is finished.

This fixes a crash triggered by reboot that looks like this:

Call trace: batadvvmeshfree+0xd0/0x4dc [batmanadv] batadvvelpthroughputmetricupdate+0x1c/0xa4 processonework+0x178/0x398 workerthread+0x2e8/0x4d0 kthread+0xd8/0xdc retfromfork+0x10/0x20

(the batadvvmesh_free call is misleading, and does not actually happen)

I was able to make the issue happen more reliably by changing hardifneigh->batv.metric_work work to be delayed work. This allowed me to track down and confirm the fix.

sven@narfation.org: prevent entering batadvvelpgetthroughput without soft_iface

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

usbnet: gl620a: fix endpoint checking in genelink_bind()

Syzbot reports [1] a warning in usbsubmiturb() triggered by inconsistencies between expected and actually present endpoints in gl620a driver. Since genelink_bind() does not properly verify whether specified eps are in fact provided by the device, in this case, an artificially manufactured one, one may get a mismatch.

Fix the issue by resorting to a usbnet utility function usbnetgetendpoints(), usually reserved for this very problem. Check for endpoints and return early before proceeding further if any are missing.

[1] Syzbot report: usb 5-1: Manufacturer: syz usb 5-1: SerialNumber: syz usb 5-1: config 0 descriptor?? gl620a 5-1:0.23 usb0: register 'gl620a' at usb-dummyhcd.0-1, ... ------------[ cut here ]------------ usb 5-1: BOGUS urb xfer, pipe 3 != type 1 WARNING: CPU: 2 PID: 1841 at drivers/usb/core/urb.c:503 usbsubmiturb+0xe4b/0x1730 drivers/usb/core/urb.c:503 Modules linked in: CPU: 2 UID: 0 PID: 1841 Comm: kworker/2:2 Not tainted 6.12.0-syzkaller-07834-g06afb0f36106 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Workqueue: mld mldifcwork RIP: 0010:usbsubmiturb+0xe4b/0x1730 drivers/usb/core/urb.c:503 ... Call Trace: <TASK> usbnetstartxmit+0x6be/0x2780 drivers/net/usb/usbnet.c:1467 _netdevstartxmit include/linux/netdevice.h:5002 [inline] netdevstartxmit include/linux/netdevice.h:5011 [inline] xmitone net/core/dev.c:3590 [inline] devhardstartxmit+0x9a/0x7b0 net/core/dev.c:3606 schdirectxmit+0x1ae/0xc30 net/sched/schgeneric.c:343 _devxmitskb net/core/dev.c:3827 [inline] _devqueuexmit+0x13d4/0x43e0 net/core/dev.c:4400 devqueuexmit include/linux/netdevice.h:3168 [inline] neighresolveoutput net/core/neighbour.c:1514 [inline] neighresolveoutput+0x5bc/0x950 net/core/neighbour.c:1494 neighoutput include/net/neighbour.h:539 [inline] ip6finishoutput2+0xb1b/0x2070 net/ipv6/ip6output.c:141 _ip6finishoutput net/ipv6/ip6output.c:215 [inline] ip6finishoutput+0x3f9/0x1360 net/ipv6/ip6output.c:226 NFHOOKCOND include/linux/netfilter.h:303 [inline] ip6output+0x1f8/0x540 net/ipv6/ip6output.c:247 dstoutput include/net/dst.h:450 [inline] NFHOOK include/linux/netfilter.h:314 [inline] NFHOOK include/linux/netfilter.h:308 [inline] mldsendpack+0x9f0/0x11d0 net/ipv6/mcast.c:1819 mldsendcr net/ipv6/mcast.c:2120 [inline] mldifcwork+0x740/0xca0 net/ipv6/mcast.c:2651 processonework+0x9c5/0x1ba0 kernel/workqueue.c:3229 processscheduledworks kernel/workqueue.c:3310 [inline] workerthread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK>(CVE-2025-21877)

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

ftrace: Avoid potential division by zero in functionstatshow()

Check whether denominator expression x * (x - 1) * 1000 mod {2^32, 2^64} produce zero and skip stddev computation in that case.

For now don't care about rec->counter * rec->counter overflow because rec->time * rec->time overflow will likely happen earlier.(CVE-2025-21898)

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

rapidio: add check for rioaddnet() in rioscanalloc_net()

The return value of rioaddnet() should be checked. If it fails, putdevice() should be called to free the memory and give up the reference initialized in rioadd_net().(CVE-2025-21935)

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:

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)