OESA-2025-1283

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

net: sfc: add missing xdp queue reinitialization

After rx/tx ring buffer size is changed, kernel panic occurs when it acts XDPTX or XDPREDIRECT.

When tx/rx ring buffer size is changed(ethtool -G), sfc driver reallocates and reinitializes rx and tx queues and their buffer (txqueue->buffer). But it misses reinitializing xdp queues(efx->xdptxqueues). So, while it is acting XDPTX or XDPREDIRECT, it uses the uninitialized txqueue->buffer.

A new function efxsetxdpchannels() is separated from efxset_channels() to handle only xdp queues.

Splat looks like: BUG: kernel NULL pointer dereference, address: 000000000000002a #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page PGD 0 P4D 0 Oops: 0002 [#4] PREEMPT SMP NOPTI RIP: 0010:efxtxmapchunk+0x54/0x90 [sfc] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G D 5.17.0+ #55 e8beeee8289528f11357029357cf Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80 RSP: 0018:ffff92f121e45c60 EFLAGS: 00010297 RIP: 0010:efxtxmapchunk+0x54/0x90 [sfc] RAX: 0000000000000040 RBX: ffff92ea506895c0 RCX: ffffffffc0330870 RDX: 0000000000000001 RSI: 00000001139b10ce RDI: ffff92ea506895c0 RBP: ffffffffc0358a80 R08: 00000001139b110d R09: 0000000000000000 R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040 R13: 0000000000000018 R14: 00000001139b10ce R15: ffff92ea506895c0 FS: 0000000000000000(0000) GS:ffff92f121ec0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Code: 48 8b 8d a8 01 00 00 48 8d 14 52 4c 8d 2c d0 44 89 e0 48 85 c9 74 0e 44 89 e2 4c 89 f6 48 80 CR2: 000000000000002a CR3: 00000003e6810004 CR4: 00000000007706e0 RSP: 0018:ffff92f121e85c60 EFLAGS: 00010297 PKRU: 55555554 RAX: 0000000000000040 RBX: ffff92ea50689700 RCX: ffffffffc0330870 RDX: 0000000000000001 RSI: 00000001145a90ce RDI: ffff92ea50689700 RBP: ffffffffc0358a80 R08: 00000001145a910d R09: 0000000000000000 R10: 0000000000000001 R11: ffff92ea414c0088 R12: 0000000000000040 R13: 0000000000000018 R14: 00000001145a90ce R15: ffff92ea50689700 FS: 0000000000000000(0000) GS:ffff92f121e80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000002a CR3: 00000003e6810005 CR4: 00000000007706e0 PKRU: 55555554 Call Trace: <IRQ> efxxdptxbuffers+0x12b/0x3d0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] _efxrxpacket+0x5c3/0x930 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] efxrxpacket+0x28c/0x2e0 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] efxef10evprocess+0x5f8/0xf40 [sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5] ? enqueuetaskfair+0x95/0x550 efx_poll+0xc4/0x360 sfc 84c94b8e32d44d296c17e10a634d3ad454de4ba5

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

crypto: qat - add param check for DH

Reject requests with a source buffer that is bigger than the size of the key. This is to prevent a possible integer underflow that might happen when copying the source scatterlist into a linear buffer.(CVE-2022-49564)

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

srcu: Tighten cleanupsrcustruct() GP checks

Currently, cleanupsrcustruct() checks for a grace period in progress, but it does not check for a grace period that has not yet started but which might start at any time. Such a situation could result in a use-after-free bug, so this commit adds a check for a grace period that is needed but not yet started to cleanupsrcustruct().(CVE-2022-49651)

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

cifs: Fix UAF in cifsdemultiplexthread()

There is a UAF when xfstests on cifs:

BUG: KASAN: use-after-free in smb2isnetworknamedeleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923

CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 ... Call Trace: <TASK> dumpstacklvl+0x34/0x44 printreport+0x171/0x472 kasanreport+0xad/0x130 kasancheckrange+0x145/0x1a0 smb2isnetworknamedeleted+0x27/0x160 cifsdemultiplexthread.cold+0x172/0x5a4 kthread+0x165/0x1a0 retfromfork+0x1f/0x30 </TASK>

Allocated by task 923: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 _kasanslaballoc+0x54/0x60 kmemcachealloc+0x147/0x320 mempoolalloc+0xe1/0x260 cifssmallbufget+0x24/0x60 allocatebuffers+0xa1/0x1c0 cifsdemultiplexthread+0x199/0x10d0 kthread+0x165/0x1a0 retfromfork+0x1f/0x30

Freed by task 921: kasansavestack+0x1e/0x40 kasansettrack+0x21/0x30 kasansavefreeinfo+0x2a/0x40 __kasanslabfree+0x143/0x1b0 kmemcachefree+0xe3/0x4d0 cifssmallbufrelease+0x29/0x90 SMB2negotiate+0x8b7/0x1c60 smb2negotiate+0x51/0x70 cifsnegotiateprotocol+0xf0/0x160 cifsgetsmbses+0x5fa/0x13c0 mountgetconns+0x7a/0x750 cifsmount+0x103/0xd00 cifssmb3domount+0x1dd/0xcb0 smb3gettree+0x1d5/0x300 vfsgettree+0x41/0xf0 pathmount+0x9b3/0xdd0 _x64sysmount+0x190/0x1d0 dosyscall64+0x35/0x80 entrySYSCALL64after_hwframe+0x46/0xb0

The UAF is because:

mount(pid: 921) | cifsd(pid: 923) -------------------------------|------------------------------- | cifsdemultiplexthread SMB2negotiate | cifssendrecv | compoundsendrecv | smbsendrqst | waitforresponse | waiteventstate [1] | | standardreceive3 | cifshandlestandard | handlemid | mid->respbuf = buf; [2] | dequeuemid [3] KILL the process [4] | respiov[i].iovbase = buf | freerspbuf [5] | | isnetworknamedeleted [6] | callback

1. After send request to server, wait the response until mid->mid_state != SUBMITTED;
2. Receive response from server, and set it to mid;
3. Set the mid state to RECEIVED;
4. Kill the process, the mid state already RECEIVED, get 0;
5. Handle and release the negotiate response;
6. UAF.

It can be easily reproduce with add some delay in [3] - [6].

Only sync call has the problem since async call's callback is executed in cifsd process.

Add an extra state to mark the mid state to READY before wakeup the waitter, then it can get the resp safely.(CVE-2023-52572)

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

smb: client: fix TCP timers deadlock after rmmod

Commit ef7134c7fc48 ("smb: client: Fix use-after-free of network namespace.") fixed a netns UAF by manually enabled socket refcounting (sk->sknetrefcnt=1 and sockinuseadd(net, 1)).

The reason the patch worked for that bug was because we now hold references to the netns (getnettrack() gets a ref internally) and they're properly released (internally, on _skdestruct()), but only because sk->sknetrefcnt was set.

Problem: (this happens regardless of CONFIGNETNSREFCNTTRACKER and regardless if init_net or other)

Setting sk->sknetrefcnt=1 manually and after socket creation is not only out of cifs scope, but also technically wrong -- it's set conditionally based on user (=1) vs kernel (=0) sockets. And net/ implementations seem to base their user vs kernel space operations on it.

e.g. upon TCP socket close, the TCP timers are not cleared because sk->sknetrefcnt=1: (cf. commit 151c9c724d05 ("tcp: properly terminate timers for kernel sockets"))

net/ipv4/tcp.c: void tcpclose(struct sock *sk, long timeout) { locksock(sk); _tcpclose(sk, timeout); releasesock(sk); if (!sk->sknetrefcnt) inetcskclearxmittimerssync(sk); sock_put(sk); }

Which will throw a lockdep warning and then, as expected, deadlock on tcpwritetimer().

A way to reproduce this is by running the reproducer from ef7134c7fc48 and then 'rmmod cifs'. A few seconds later, the deadlock/lockdep warning shows up.

Fix: We shouldn't mess with socket internals ourselves, so do not set sknetrefcnt manually.

Also change _sockcreate() to sockcreatekern() for explicitness.

As for non-init_net network namespaces, we deal with it the best way we can -- hold an extra netns reference for server->ssocket and drop it when it's released. This ensures that the netns still exists whenever we need to create/destroy server->ssocket, but is not directly tied to it.(CVE-2024-54680)

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

mfd: intelsocpmic_bxtwc: Use IRQ domain for PMIC devices

While design wise the idea of converting the driver to use the hierarchy of the IRQ chips is correct, the implementation has (inherited) flaws. This was unveiled when platformgetirq() had started WARN() on IRQ 0 that is supposed to be a Linux IRQ number (also known as vIRQ).

Rework the driver to respect IRQ domain when creating each MFD device separately, as the domain is not the same for all of them.(CVE-2024-56723)

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

netfilter: nfsetpipapo: fix initial map fill

The initial buffer has to be inited to all-ones, but it must restrict it to the size of the first field, not the total field size.

After each round in the map search step, the result and the fill map are swapped, so if we have a set where f->bsize of the first element is smaller than m->bsize_max, those one-bits are leaked into future rounds result map.

This makes pipapo find an incorrect matching results for sets where first field size is not the largest.

Followup patch adds a test case to nftconcatrange.sh selftest script.

Thanks to Stefano Brivio for pointing out that we need to zero out the remainder explicitly, only correcting memset() argument isn't enough.(CVE-2024-57947)

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

ocfs2: handle a symlink read error correctly

Patch series "Convert ocfs2 to use folios".

Mark did a conversion of ocfs2 to use folios and sent it to me as a giant patch for review ;-)

So I've redone it as individual patches, and credited Mark for the patches where his code is substantially the same. It's not a bad way to do it; his patch had some bugs and my patches had some bugs. Hopefully all our bugs were different from each other. And hopefully Mark likes all the changes I made to his code!

This patch (of 23):

If we can't read the buffer, be sure to unlock the page before returning.(CVE-2024-58001)

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

Bluetooth: L2CAP: handle NULL sock pointer in l2capsockalloc

A NULL sock pointer is passed into l2capsockalloc() when it is called from l2capsocknewconnectioncb() and the error handling paths should also be aware of it.

Seemingly a more elegant solution would be to swap btsockalloc() and l2capchancreate() calls since they are not interdependent to that moment but then l2capchancreate() adds the soon to be deallocated and still dummy-initialized channel to the global list accessible by many L2CAP paths. The channel would be removed from the list in short period of time but be a bit more straight-forward here and just check for NULL instead of changing the order of function calls.

Found by Linux Verification Center (linuxtesting.org) with SVACE static analysis tool.(CVE-2024-58009)

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

ipmr: do not call mrmfcuses_dev() for unres entries

syzbot found that calling mrmfcusesdev() for unres entries would crash [1], because c->mfcun.res.minvif / c->mfcun.res.maxvif alias to "struct skbuff_head unresolved", which contain two pointers.

This code never worked, lets remove it.

[1] Unable to handle kernel paging request at virtual address ffff5fff2d536613 KASAN: maybe wild-memory-access in range [0xfffefff96a9b3098-0xfffefff96a9b309f] Modules linked in: CPU: 1 UID: 0 PID: 7321 Comm: syz.0.16 Not tainted 6.13.0-rc7-syzkaller-g1950a0af2d55 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : mrmfcusesdev net/ipv4/ipmrbase.c:290 [inline] pc : mrtabledump+0x5a4/0x8b0 net/ipv4/ipmrbase.c:334 lr : mrmfcusesdev net/ipv4/ipmrbase.c:289 [inline] lr : mrtabledump+0x694/0x8b0 net/ipv4/ipmrbase.c:334 Call trace: mrmfcusesdev net/ipv4/ipmrbase.c:290 [inline] (P) mrtabledump+0x5a4/0x8b0 net/ipv4/ipmrbase.c:334 (P) mrrtmdumproute+0x254/0x454 net/ipv4/ipmrbase.c:382 ipmrrtmdumproute+0x248/0x4b4 net/ipv4/ipmr.c:2648 rtnldumpall+0x2e4/0x4e8 net/core/rtnetlink.c:4327 rtnldumpit+0x98/0x1d0 net/core/rtnetlink.c:6791 netlinkdump+0x4f0/0xbc0 net/netlink/afnetlink.c:2317 netlinkrecvmsg+0x56c/0xe64 net/netlink/afnetlink.c:1973 sockrecvmsgnosec net/socket.c:1033 [inline] sockrecvmsg net/socket.c:1055 [inline] sockreaditer+0x2d8/0x40c net/socket.c:1125 newsyncread fs/readwrite.c:484 [inline] vfsread+0x740/0x970 fs/readwrite.c:565 ksysread+0x15c/0x26c fs/read_write.c:708(CVE-2025-21719)

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

NFC: nci: Add bounds checking in ncihcicreate_pipe()

The "pipe" variable is a u8 which comes from the network. If it's more than 127, then it results in memory corruption in the caller, ncihciconnect_gate().(CVE-2025-21735)

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

vsock: Keep the binding until socket destruction

Preserve sockets bindings; this includes both resulting from an explicit bind() and those implicitly bound through autobind during connect().

Prevents socket unbinding during a transport reassignment, which fixes a use-after-free:

1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
2. transport->release() calls vsock_remove_bound() without checking if
   sk was bound and moved to bound list (refcnt=1)
3. vsock_bind() assumes sk is in unbound list and before
   __vsock_insert_bound(vsock_bound_sockets()) calls
   __vsock_remove_bound() which does:
       list_del_init(&vsk->bound_table); // nop
       sock_put(&vsk->sk);               // refcnt=0

BUG: KASAN: slab-use-after-free in _vsockbind+0x62e/0x730 Read of size 4 at addr ffff88816b46a74c by task a.out/2057 dumpstacklvl+0x68/0x90 printreport+0x174/0x4f6 kasanreport+0xb9/0x190 _vsockbind+0x62e/0x730 vsockbind+0x97/0xe0 _sysbind+0x154/0x1f0 _x64sysbind+0x6e/0xb0 dosyscall64+0x93/0x1b0 entrySYSCALL64afterhwframe+0x76/0x7e

Allocated by task 2057: kasansavestack+0x1e/0x40 kasansavetrack+0x10/0x30 _kasanslaballoc+0x85/0x90 kmemcacheallocnoprof+0x131/0x450 skprotalloc+0x5b/0x220 skalloc+0x2c/0x870 _vsockcreate.constprop.0+0x2e/0xb60 vsockcreate+0xe4/0x420 _sockcreate+0x241/0x650 _syssocket+0xf2/0x1a0 _x64syssocket+0x6e/0xb0 dosyscall64+0x93/0x1b0 entrySYSCALL64after_hwframe+0x76/0x7e

Freed by task 2057: kasansavestack+0x1e/0x40 kasansavetrack+0x10/0x30 kasansavefreeinfo+0x37/0x60 _kasanslabfree+0x4b/0x70 kmemcachefree+0x1a1/0x590 _skdestruct+0x388/0x5a0 _vsockbind+0x5e1/0x730 vsockbind+0x97/0xe0 _sysbind+0x154/0x1f0 _x64sysbind+0x6e/0xb0 dosyscall64+0x93/0x1b0 entrySYSCALL64afterhwframe+0x76/0x7e

refcountt: addition on 0; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:25 refcountwarnsaturate+0xce/0x150 RIP: 0010:refcountwarnsaturate+0xce/0x150 _vsockbind+0x66d/0x730 vsockbind+0x97/0xe0 _sysbind+0x154/0x1f0 _x64sysbind+0x6e/0xb0 dosyscall64+0x93/0x1b0 entrySYSCALL64after_hwframe+0x76/0x7e

refcountt: underflow; use-after-free. WARNING: CPU: 7 PID: 2057 at lib/refcount.c:28 refcountwarnsaturate+0xee/0x150 RIP: 0010:refcountwarnsaturate+0xee/0x150 vsockremovebound+0x187/0x1e0 _vsockrelease+0x383/0x4a0 vsockrelease+0x90/0x120 _sockrelease+0xa3/0x250 sockclose+0x14/0x20 _fput+0x359/0xa80 taskworkrun+0x107/0x1d0 doexit+0x847/0x2560 dogroupexit+0xb8/0x250 _x64sysexitgroup+0x3a/0x50 x64syscall+0xfec/0x14f0 dosyscall64+0x93/0x1b0 entrySYSCALL64after_hwframe+0x76/0x7e(CVE-2025-21756)

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

KVM: x86: Reject Hyper-V's SEND_IPI hypercalls if local APIC isn't in-kernel

Advertise support for Hyper-V's SENDIPI and SENDIPIEX hypercalls if and only if the local API is emulated/virtualized by KVM, and explicitly reject said hypercalls if the local APIC is emulated in userspace, i.e. don't rely on userspace to opt-in to KVMCAPHYPERVENFORCE_CPUID.

Rejecting SENDIPI and SENDIPI_EX fixes a NULL-pointer dereference if Hyper-V enlightenments are exposed to the guest without an in-kernel local APIC:

dumpstack+0xbe/0xfd _kasanreport.cold+0x34/0x84 kasanreport+0x3a/0x50 _apicacceptirq+0x3a/0x5c0 kvmhvsendipi.isra.0+0x34e/0x820 kvmhvhypercall+0x8d9/0x9d0 kvmemulatehypercall+0x506/0x7e0 _vmxhandleexit+0x283/0xb60 vmxhandleexit+0x1d/0xd0 vcpuenterguest+0x16b0/0x24c0 vcpurun+0xc0/0x550 kvmarchvcpuioctlrun+0x170/0x6d0 kvmvcpuioctl+0x413/0xb20 _sesysioctl+0x111/0x160 dosyscal164+0x30/0x40 entrySYSCALL64after_hwframe+0x67/0xd1

Note, checking the sending vCPU is sufficient, as the per-VM irqchip_mode can't be modified after vCPUs are created, i.e. if one vCPU has an in-kernel local APIC, then all vCPUs have an in-kernel local APIC.(CVE-2025-21779)

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

orangefs: fix a oob in orangefsdebugwrite

I got a syzbot report: slab-out-of-bounds Read in orangefsdebugwrite... several people suggested fixes, I tested Al Viro's suggestion and made this patch.(CVE-2025-21782)