OESA-2026-1306

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

cacheinfo: Fix sharedcpumap to handle shared caches at different levels

The cacheinfo sets up the sharedcpumap by checking whether the caches with the same index are shared between CPUs. However, this will trigger slab-out-of-bounds access if the CPUs do not have the same cache hierarchy. Another problem is the mismatched sharedcpumap when the shared cache does not have the same index between CPUs.

CPU0 I D L3 index 0 1 2 x ^ ^ ^ ^ index 0 1 2 3 CPU1 I D L2 L3

This patch checks each cache is shared with all caches on other CPUs.(CVE-2023-53254)

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

drm/radeon: Fix integer overflow in radeoncsparser_init

The type of size is unsigned, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later(CVE-2023-53309)

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

media: v4l2-mem2mem: add lock to protect parameter num_rdy

Getting below error when using KCSAN to check the driver. Adding lock to protect parameter numrdy when getting the value with function: v4l2m2mnumsrcbufsready/v4l2m2mnumdstbufs_ready.

kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2m2mbuf_queue kworker/u16:3: [name:report&]

kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3:  v4l2m2mbuf_queue+0xd8/0x10c(CVE-2023-53519)

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

wifi: brcmfmac: cfg80211: Pass the PMK in binary instead of hex

Apparently the hex passphrase mechanism does not work on newer chips/firmware (e.g. BCM4387). It seems there was a simple way of passing it in binary all along, so use that and avoid the hexification.

OpenBSD has been doing it like this from the beginning, so this should work on all chips.

Also clear the structure before setting the PMK. This was leaking uninitialized stack contents to the device.(CVE-2023-53715)

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

usb-storage: alauda: Fix uninit-value in alaudacheckmedia()

Syzbot got KMSAN to complain about access to an uninitialized value in the alauda subdriver of usb-storage:

BUG: KMSAN: uninit-value in alaudatransport+0x462/0x57f0 drivers/usb/storage/alauda.c:1137 CPU: 0 PID: 12279 Comm: usb-storage Not tainted 5.3.0-rc7+ #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: _dumpstack lib/dumpstack.c:77 [inline] dumpstack+0x191/0x1f0 lib/dumpstack.c:113 kmsanreport+0x13a/0x2b0 mm/kmsan/kmsanreport.c:108 _msanwarning+0x73/0xe0 mm/kmsan/kmsaninstr.c:250 alaudacheck_media+0x344/0x3310 drivers/usb/storage/alauda.c:460

The problem is that alaudacheckmedia() doesn't verify that its USB transfer succeeded before trying to use the received data. What should happen if the transfer fails isn't entirely clear, but a reasonably conservative approach is to pretend that no media is present.

A similar problem exists in a usbstordbg() call in alaudagetmediastatus(). In this case, when an error occurs the call is redundant, because usbstorctrltransfer() already will print a debugging message.

Finally, unrelated to the uninitialized memory access, is the fact that alaudacheckmedia() performs DMA to a buffer on the stack. Fortunately usb-storage provides a general purpose DMA-able buffer for uses like this. We'll use it instead.(CVE-2023-53847)

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

RDMA/mlx4: Prevent shift wrapping in setusersq_size()

The ucmd->logsqbbcount variable is controlled by the user so this shift can wrap. Fix it by using checkshloverflow() in the same way that it was done in commit 515f60004ed9 ("RDMA/hns: Prevent undefined behavior in hnsrocesetusersqsize()").(CVE-2023-54168)

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

usb: typec: altmodes/displayport: fix pinassignmentshow

This patch fixes negative indexing of buf array in pinassignmentshow when getcurrentpin_assignments returns 0 i.e. no compatible pin assignments are found.

BUG: KASAN: use-after-free in pinassignmentshow+0x26c/0x33c ... Call trace: dumpbacktrace+0x110/0x204 dumpstacklvl+0x84/0xbc printreport+0x358/0x974 kasanreport+0x9c/0xfc _dokernelfault+0xd4/0x2d4 dobadarea+0x48/0x168 dotagcheckfault+0x24/0x38 domemabort+0x6c/0x14c el1abort+0x44/0x68 el1h64synchandler+0x64/0xa4 el1h64sync+0x78/0x7c pinassignmentshow+0x26c/0x33c devattr_show+0x50/0xc0(CVE-2023-54186)

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

md/raid10: fix memleak of md thread

In raid10run(), if setupconf() succeed and raid10_run() failed before setting 'mddev->thread', then in the error path 'conf->thread' is not freed.

Fix the problem by setting 'mddev->thread' right after setup_conf().(CVE-2023-54294)

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

dm flakey: don't corrupt the zero page

When we need to zero some range on a block device, the function _blkdevissuezeropages submits a write bio with the bio vector pointing to the zero page. If we use dm-flakey with corrupt bio writes option, it will corrupt the content of the zero page which results in crashes of various userspace programs. Glibc assumes that memory returned by mmap is zeroed and it uses it for calloc implementation; if the newly mapped memory is not zeroed, calloc will return non-zeroed memory.

Fix this bug by testing if the page is equal to ZERO_PAGE(0) and avoiding the corruption in this case.(CVE-2023-54317)

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

cloneprivatemnt(): make sure that caller has CAPSYSADMIN in the right userns

What we want is to verify there is that clone won't expose something hidden by a mount we wouldn't be able to undo. "Wouldn't be able to undo" may be a result of MNT_LOCKED on a child, but it may also come from lacking admin rights in the userns of the namespace mount belongs to.

cloneprivatemnt() checks the former, but not the latter.

There's a number of rather confusing CAPSYSADMIN checks in various userns during the mount, especially with the new mount API; they serve different purposes and in case of cloneprivatemnt() they usually, but not always end up covering the missing check mentioned above.(CVE-2025-38499)

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

ipv6: reject malicious packets in ipv6gsosegment()

syzbot was able to craft a packet with very long IPv6 extension headers leading to an overflow of skb->transport_header.

This 16bit field has a limited range.

Add skbresettransportheadercareful() helper and use it from ipv6gsosegment()

WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 skbresettransportheader include/linux/skbuff.h:3032 [inline] WARNING: CPU: 0 PID: 5871 at ./include/linux/skbuff.h:3032 ipv6gsosegment+0x15e2/0x21e0 net/ipv6/ip6offload.c:151 Modules linked in: CPU: 0 UID: 0 PID: 5871 Comm: syz-executor211 Not tainted 6.16.0-rc6-syzkaller-g7abc678e3084 #0 PREEMPT(full) Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/12/2025 RIP: 0010:skbresettransportheader include/linux/skbuff.h:3032 [inline] RIP: 0010:ipv6gsosegment+0x15e2/0x21e0 net/ipv6/ip6offload.c:151 Call Trace: <TASK> skbmacgsosegment+0x31c/0x640 net/core/gso.c:53 nshgsosegment+0x54a/0xe10 net/nsh/nsh.c:110 skbmacgsosegment+0x31c/0x640 net/core/gso.c:53 _skbgsosegment+0x342/0x510 net/core/gso.c:124 skbgsosegment include/net/gso.h:83 [inline] validatexmitskb+0x857/0x11b0 net/core/dev.c:3950 validatexmitskblist+0x84/0x120 net/core/dev.c:4000 schdirectxmit+0xd3/0x4b0 net/sched/schgeneric.c:329 _devxmitskb net/core/dev.c:4102 [inline] _devqueue_xmit+0x17b6/0x3a70 net/core/dev.c:4679(CVE-2025-38572)

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

vsock: Do not allow binding to VMADDRPORTANY

It is possible for a vsock to autobind to VMADDRPORTANY. This can cause a use-after-free when a connection is made to the bound socket. The socket returned by accept() also has port VMADDRPORTANY but is not on the list of unbound sockets. Binding it will result in an extra refcount decrement similar to the one fixed in fcdd2242c023 (vsock: Keep the binding until socket destruction).

Modify the check in _vsockbindconnectible() to also prevent binding to VMADDRPORT_ANY.(CVE-2025-38618)

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

pid: Add a judgment for ns null in pidnrns

_taskpidnrns ns = taskactivepidns(current); pidnrns(rcudereference(*taskpidptr(task, type)), ns); if (pid && ns->level <= pid->level) {

Sometimes null is returned for taskactivepidns. Then it will trigger kernel panic in pidnr_ns.

For example: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 Mem abort info: ESR = 0x0000000096000007 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x07: level 3 translation fault Data abort info: ISV = 0, ISS = 0x00000007, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 39-bit VAs, pgdp=00000002175aa000 [0000000000000058] pgd=08000002175ab003, p4d=08000002175ab003, pud=08000002175ab003, pmd=08000002175be003, pte=0000000000000000 pstate: 834000c5 (Nzcv daIF +PAN -UAO +TCO +DIT -SSBS BTYPE=--) pc : _taskpidnrns+0x74/0xd0 lr : _taskpidnrns+0x24/0xd0 sp : ffffffc08001bd10 x29: ffffffc08001bd10 x28: ffffffd4422b2000 x27: 0000000000000001 x26: ffffffd442821168 x25: ffffffd442821000 x24: 00000f89492eab31 x23: 00000000000000c0 x22: ffffff806f5693c0 x21: ffffff806f5693c0 x20: 0000000000000001 x19: 0000000000000000 x18: 0000000000000000 x17: 00000000529c6ef0 x16: 00000000529c6ef0 x15: 00000000023a1adc x14: 0000000000000003 x13: 00000000007ef6d8 x12: 001167c391c78800 x11: 00ffffffffffffff x10: 0000000000000000 x9 : 0000000000000001 x8 : ffffff80816fa3c0 x7 : 0000000000000000 x6 : 49534d702d535449 x5 : ffffffc080c4c2c0 x4 : ffffffd43ee128c8 x3 : ffffffd43ee124dc x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffffff806f5693c0 Call trace: _taskpidnrns+0x74/0xd0 ... _handleirqeventpercpu+0xd4/0x284 handleirqevent+0x48/0xb0 handlefasteoiirq+0x160/0x2d8 generichandledomainirq+0x44/0x60 gichandleirq+0x4c/0x114 callonirqstack+0x3c/0x74 dointerrupthandler+0x4c/0x84 el1interrupt+0x34/0x58 el1h64irqhandler+0x18/0x24 el1h64irq+0x68/0x6c accountkernelstack+0x60/0x144 exittaskstackaccount+0x1c/0x80 doexit+0x7e4/0xaf8 ... getsignal+0x7bc/0x8d8 donotifyresume+0x128/0x828 el0svc+0x6c/0x70 el0t64synchandler+0x68/0xbc el0t64_sync+0x1a8/0x1ac Code: 35fffe54 911a02a8 f9400108 b4000128 (b9405a69) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception in interrupt(CVE-2025-40178)

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

fs/proc: fix uaf in procreaddirde()

Pde is erased from subdir rbtree through rberase(), but not set the node to EMPTY, which may result in uaf access. We should use RBCLEARNODE() set the erased node to EMPTY, then pdesubdir_next() will return NULL to avoid uaf access.

We found an uaf issue while using stress-ng testing, need to run testcase getdent and tun in the same time. The steps of the issue is as follows:

1) use getdent to traverse dir /proc/pid/net/dev_snmp6/, and current pde is tun3;

2) in the [time windows] unregister netdevice tun3 and tun2, and erase them from rbtree. erase tun3 first, and then erase tun2. the pde(tun2) will be released to slab;

3) continue to getdent process, then pdesubdirnext() will return pde(tun2) which is released, it will case uaf access.

CPU 0 | CPU 1

traverse dir /proc/pid/net/devsnmp6/ | unregisternetdevice(tun->dev) //tun3 tun2 sysgetdents64() | iteratedir() | procreaddir() | procreaddirde() | snmp6unregisterdev() pdeget(de); | procremove() readunlock(&procsubdirlock); | removeprocsubtree() | writelock(&procsubdirlock); [time window] | rberase(&root->subdirnode, &parent->subdir); | writeunlock(&procsubdirlock); readlock(&procsubdirlock); | next = pdesubdirnext(de); | pdeput(de); | de = next; //UAF |

rbtree of dev_snmp6 | pde(tun3) / \ NULL pde(tun2)(CVE-2025-40271)