OESA-2025-1726

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

kcm: close race conditions on skreceivequeue

sk->skreceivequeue is protected by skb queue lock, but for KCM sockets its RX path takes mux->rxlock to protect more than just skb queue. However, kcmrecvmsg() still only grabs the skb queue lock, so race conditions still exist.

We can teach kcmrecvmsg() to grab mux->rxlock too but this would introduce a potential performance regression as struct kcm_mux can be shared by multiple KCM sockets.

So we have to enforce skb queue lock in requeuerxmsgs() and handle skb peek case carefully in kcmwaitdata(). Fortunately, skbrecvdatagram() already handles it nicely and is widely used by other sockets, we can just switch to skbrecvdatagram() after getting rid of the unnecessary sock lock in kcmrecvmsg() and kcmspliceread(). Side note: SOCKDONE is not used by KCM sockets, so it is safe to get rid of this check too.

I ran the original syzbot reproducer for 30 min without seeing any issue.(CVE-2022-49814)

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

ipvs: fix WARNING in ipvsappnetcleanup()

During the initialization of ipvsappnetinit(), if file ipvsapp fails to be created, the initialization is successful by default. Therefore, the ipvsapp file doesn't be found during the remove in ipvsappnetcleanup(). It will cause WRNING.

The following is the stack information: name 'ipvsapp' WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 removeprocentry+0x389/0x460 Modules linked in: Workqueue: netns cleanupnet RIP: 0010:removeprocentry+0x389/0x460 Call Trace: <TASK> opsexitlist+0x125/0x170 cleanupnet+0x4ea/0xb00 processonework+0x9bf/0x1710 workerthread+0x665/0x1080 kthread+0x2e4/0x3a0 retfrom_fork+0x1f/0x30 </TASK>(CVE-2022-49917)

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

HID: hidraw: fix memory leak in hidraw_release()

Free the buffered reports before deleting the list entry.

BUG: memory leak unreferenced object 0xffff88810e72f180 (size 32): comm "softirq", pid 0, jiffies 4294945143 (age 16.080s) hex dump (first 32 bytes): 64 f3 c6 6a d1 88 07 04 00 00 00 00 00 00 00 00 d..j............ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff814ac6c3>] kmemdup+0x23/0x50 mm/util.c:128 [<ffffffff8357c1d2>] kmemdup include/linux/fortify-string.h:440 [inline] [<ffffffff8357c1d2>] hidrawreportevent+0xa2/0x150 drivers/hid/hidraw.c:521 [<ffffffff8356ddad>] hidreportrawevent+0x27d/0x740 drivers/hid/hid-core.c:1992 [<ffffffff8356e41e>] hidinputreport+0x1ae/0x270 drivers/hid/hid-core.c:2065 [<ffffffff835f0d3f>] hidirqin+0x1ff/0x250 drivers/hid/usbhid/hid-core.c:284 [<ffffffff82d3c7f9>] _usbhcdgivebackurb+0xf9/0x230 drivers/usb/core/hcd.c:1670 [<ffffffff82d3cc26>] usbhcdgivebackurb+0x1b6/0x1d0 drivers/usb/core/hcd.c:1747 [<ffffffff82ef1e14>] dummytimer+0x8e4/0x14c0 drivers/usb/gadget/udc/dummyhcd.c:1988 [<ffffffff812f50a8>] calltimerfn+0x38/0x200 kernel/time/timer.c:1474 [<ffffffff812f5586>] expiretimers kernel/time/timer.c:1519 [inline] [<ffffffff812f5586>] _runtimers.part.0+0x316/0x430 kernel/time/timer.c:1790 [<ffffffff812f56e4>] _runtimers kernel/time/timer.c:1768 [inline] [<ffffffff812f56e4>] runtimersoftirq+0x44/0x90 kernel/time/timer.c:1803 [<ffffffff848000e6>] _dosoftirq+0xe6/0x2ea kernel/softirq.c:571 [<ffffffff81246db0>] invokesoftirq kernel/softirq.c:445 [inline] [<ffffffff81246db0>] _irqexitrcu kernel/softirq.c:650 [inline] [<ffffffff81246db0>] irqexitrcu+0xc0/0x110 kernel/softirq.c:662 [<ffffffff84574f02>] sysvecapictimerinterrupt+0xa2/0xd0 arch/x86/kernel/apic/apic.c:1106 [<ffffffff84600c8b>] asmsysvecapictimerinterrupt+0x1b/0x20 arch/x86/include/asm/idtentry.h:649 [<ffffffff8458a070>] nativesafehalt arch/x86/include/asm/irqflags.h:51 [inline] [<ffffffff8458a070>] archsafehalt arch/x86/include/asm/irqflags.h:89 [inline] [<ffffffff8458a070>] acpisafehalt drivers/acpi/processoridle.c:111 [inline] [<ffffffff8458a070>] acpiidledoentry+0xc0/0xd0 drivers/acpi/processor_idle.c:554(CVE-2022-49981)

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

media: pvrusb2: fix memory leak in pvr_probe

The error handling code in pvr2hdwcreate forgets to unregister the v4l2 device. When pvr2hdwcreate returns back to pvr2contextcreate, it calls pvr2contextdestroy to destroy context, but mp->hdw is NULL, which leads to that pvr2hdwdestroy directly returns.

Fix this by adding v4l2deviceunregister to decrease the refcount of usb interface.(CVE-2022-49982)

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

tee: add overflow check in registershmhelper()

With special lengths supplied by user space, registershmhelper() has an integer overflow when calculating the number of pages covered by a supplied user space memory region.

This causes internalgetuserpagesfast() a helper function of pinuserpages_fast() to do a NULL pointer dereference:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000010 Modules linked in: CPU: 1 PID: 173 Comm: opteeexamplea Not tainted 5.19.0 #11 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 pc : internalgetuserpagesfast+0x474/0xa80 Call trace: internalgetuserpagesfast+0x474/0xa80 pinuserpagesfast+0x24/0x4c registershmhelper+0x194/0x330 teeshmregisteruserbuf+0x78/0x120 teeioctl+0xd0/0x11a0 _arm64sysioctl+0xa8/0xec invokesyscall+0x48/0x114

Fix this by adding an an explicit call to accessok() in teeshmregisteruser_buf() to catch an invalid user space address early.(CVE-2022-50080)

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

spmi: trace: fix stack-out-of-bound access in SPMI tracing functions

tracespmiwritebegin() and tracespmireadend() both call memcpy() with a length of "len + 1". This leads to one extra byte being read beyond the end of the specified buffer. Fix this out-of-bound memory access by using a length of "len" instead.

Here is a KASAN log showing the issue:

BUG: KASAN: stack-out-of-bounds in traceeventraweventspmireadend+0x1d0/0x234 Read of size 2 at addr ffffffc0265b7540 by task (CVE-2022-50094)

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

ARM: OMAP2+: display: Fix refcount leak bug

In omapdssinitfbdev(), offindnodebyname() will return a node pointer with refcount incremented. We should use ofnodeput() when it is not used anymore.(CVE-2022-50203)

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

tty: vt: initialize unicode screen buffer

syzbot reports kernel infoleak at vcs_read() [1], for buffer can be read immediately after resize operation. Initialize buffer using kzalloc().

#include <fcntl.h> #include <unistd.h> #include <sys/ioctl.h> #include <linux/fb.h>

int main(int argc, char *argv[]) { struct fbvarscreeninfo var = { }; const int fbfd = open("/dev/fb0", 3); ioctl(fbfd, FBIOGETVSCREENINFO, &var); var.yres = 0x21; ioctl(fbfd, FBIOPUTVSCREENINFO, &var); return read(open("/dev/vcsu", ORDONLY), &var, sizeof(var)) == -1; } ----------(CVE-2022-50222)

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

erspan: do not use skbmacheader() in ndostartxmit()

Drivers should not assume skbmacheader(skb) == skb->data in their ndostartxmit().

Use skbnetworkoffset() and skbtransportoffset() which better describe what is needed in erspanfbxmit() and ip6erspantunnelxmit()

syzbot reported: WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 skbmacheader include/linux/skbuff.h:2873 [inline] WARNING: CPU: 0 PID: 5083 at include/linux/skbuff.h:2873 ip6erspantunnelxmit+0x1d9c/0x2d90 net/ipv6/ip6gre.c:962 Modules linked in: CPU: 0 PID: 5083 Comm: syz-executor406 Not tainted 6.3.0-rc2-syzkaller-00866-gd4671cb96fa3 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/02/2023 RIP: 0010:skbmacheader include/linux/skbuff.h:2873 [inline] RIP: 0010:ip6erspantunnelxmit+0x1d9c/0x2d90 net/ipv6/ip6gre.c:962 Code: 04 02 41 01 de 84 c0 74 08 3c 03 0f 8e 1c 0a 00 00 45 89 b4 24 c8 00 00 00 c6 85 77 fe ff ff 01 e9 33 e7 ff ff e8 b4 27 a1 f8 <0f> 0b e9 b6 e7 ff ff e8 a8 27 a1 f8 49 8d bf f0 0c 00 00 48 b8 00 RSP: 0018:ffffc90003b2f830 EFLAGS: 00010293 RAX: 0000000000000000 RBX: 000000000000ffff RCX: 0000000000000000 RDX: ffff888021273a80 RSI: ffffffff88e1bd4c RDI: 0000000000000003 RBP: ffffc90003b2f9d8 R08: 0000000000000003 R09: 000000000000ffff R10: 000000000000ffff R11: 0000000000000000 R12: ffff88802b28da00 R13: 00000000000000d0 R14: ffff88807e25b6d0 R15: ffff888023408000 FS: 0000555556a61300(0000) GS:ffff8880b9800000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055e5b11eb6e8 CR3: 0000000027c1b000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _netdevstartxmit include/linux/netdevice.h:4900 [inline] netdevstartxmit include/linux/netdevice.h:4914 [inline] _devdirectxmit+0x504/0x730 net/core/dev.c:4300 devdirectxmit include/linux/netdevice.h:3088 [inline] packetxmit+0x20a/0x390 net/packet/afpacket.c:285 packetsnd net/packet/afpacket.c:3075 [inline] packetsendmsg+0x31a0/0x5150 net/packet/afpacket.c:3107 socksendmsgnosec net/socket.c:724 [inline] socksendmsg+0xde/0x190 net/socket.c:747 _syssendto+0x23a/0x340 net/socket.c:2142 _dosyssendto net/socket.c:2154 [inline] _sesyssendto net/socket.c:2150 [inline] _x64syssendto+0xe1/0x1b0 net/socket.c:2150 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x39/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7f123aaa1039 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 b1 14 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 c0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffc15d12058 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f123aaa1039 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 0000000000000000 R08: 0000000020000040 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 00007f123aa648c0 R13: 431bde82d7b634db R14: 0000000000000000 R15: 0000000000000000(CVE-2023-53053)

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

net: usb: smsc95xx: Limit packet length to skb->len

Packet length retrieved from descriptor may be larger than the actual socket buffer length. In such case the cloned skb passed up the network stack will leak kernel memory contents.(CVE-2023-53062)

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

qed/qedsriov: guard against NULL derefs from qediovgetvf_info

We have to make sure that the info returned by the helper is valid before using it.

Found by Linux Verification Center (linuxtesting.org) with the SVACE static analysis tool.(CVE-2023-53066)

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

net: usb: smsc75xx: Limit packet length to skb->len

Packet length retrieved from skb data may be larger than the actual socket buffer length (up to 9026 bytes). In such case the cloned skb passed up the network stack will leak kernel memory contents.(CVE-2023-53125)

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

_legitimizemnt(): check for MNTSYNCUMOUNT should be under mount_lock

... or we risk stealing final mntput from sync umount - raising mntcount after umount(2) has verified that victim is not busy, but before it has set MNTSYNCUMOUNT; in that case _legitimizemnt() doesn't see that it's safe to quietly undo mntcount increment and leaves dropping the reference to caller, where it'll be a full-blown mntput().

Check under mount_lock is needed; leaving the current one done before taking that makes no sense - it's nowhere near common enough to bother with.(CVE-2025-38058)