The Linux Kernel, the operating system core itself.

Security Fix(es):

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

ksmbd: fix potencial out-of-bounds when buffer offset is invalid

I found potencial out-of-bounds when buffer offset fields of a few requests is invalid. This patch set the minimum value of buffer offset field to ->Buffer offset to validate buffer length.(CVE-2024-26952)

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

ksmbd: fix slab-out-of-bounds in smbstrndupfrom_utf16()

If ->NameOffset of smb2createreq is smaller than Buffer offset of smb2createreq, slab-out-of-bounds read can happen from smb2open. This patch set the minimum value of the name offset to the buffer offset to validate name length of smb2create_req().(CVE-2024-26954)

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

net: dsa: improve shutdown sequence

Alexander Sverdlin presents 2 problems during shutdown with the lan9303 driver. One is specific to lan9303 and the other just happens to reproduce there.

The first problem is that lan9303 is unique among DSA drivers in that it calls devgetdrvdata() at "arbitrary runtime" (not probe, not shutdown, not remove):

phystatemachine() -> ... -> dsauserphyread() -> ds->ops->phyread() -> lan9303phyread() -> chip->ops->phyread() -> lan9303mdiophyread() -> devgetdrvdata()

But we never stop the phystatemachine(), so it may continue to run after dsaswitchshutdown(). Our common pattern in all DSA drivers is to set drvdata to NULL to suppress the remove() method that may come afterwards. But in this case it will result in an NPD.

The second problem is that the way in which we set dp->conduit->dsaptr = NULL; is concurrent with receive packet processing. dsaswitchrcv() checks once whether dev->dsaptr is NULL, but afterwards, rather than continuing to use that non-NULL value, dev->dsaptr is dereferenced again and again without NULL checks: dsaconduitfinduser() and many other places. In between dereferences, there is no locking to ensure that what was valid once continues to be valid.

Both problems have the common aspect that closing the conduit interface solves them.

In the first case, devclose(conduit) triggers the NETDEVGOINGDOWN event in dsausernetdeviceevent() which closes user ports as well. dsaportdisablert() calls phylinkstop(), which synchronously stops the phylink state machine, and ds->ops->phy_read() will thus no longer call into the driver after this point.

In the second case, dev_close(conduit) should do this, as per Documentation/networking/driver.rst:

| Quiescence | ---------- | | After the ndo_stop routine has been called, the hardware must | not receive or transmit any data. All in flight packets must | be aborted. If necessary, poll or wait for completion of | any reset commands.

So it should be sufficient to ensure that later, when we zeroize conduit->dsaptr, there will be no concurrent dsaswitch_rcv() call on this conduit.

The addition of the netifdevicedetach() function is to ensure that ioctls, rtnetlinks and ethtool requests on the user ports no longer propagate down to the driver - we're no longer prepared to handle them.

The race condition actually did not exist when commit 0650bf52b31f ("net: dsa: be compatible with masters which unregister on shutdown") first introduced dsaswitchshutdown(). It was created later, when we stopped unregistering the user interfaces from a bad spot, and we just replaced that sequence with a racy zeroization of conduit->dsa_ptr (one which doesn't ensure that the interfaces aren't up).(CVE-2024-49998)

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

drm/amd/pm: Vangogh: Fix kernel memory out of bounds write

KASAN reports that the GPU metrics table allocated in vangoghtablesinit() is not large enough for the memset done in smucmninitsoftgpu_metrics(). Condensed report follows:

[ 33.861314] BUG: KASAN: slab-out-of-bounds in smucmninitsoftgpumetrics+0x73/0x200 [amdgpu] [ 33.861799] Write of size 168 at addr ffff888129f59500 by task mangoapp/1067 ... [ 33.861808] CPU: 6 UID: 1000 PID: 1067 Comm: mangoapp Tainted: G W 6.12.0-rc4 #356 1a56f59a8b5182eeaf67eb7cb8b13594dd23b544 [ 33.861816] Tainted: [W]=WARN [ 33.861818] Hardware name: Valve Galileo/Galileo, BIOS F7G0107 12/01/2023 [ 33.861822] Call Trace: [ 33.861826] <TASK> [ 33.861829] dumpstacklvl+0x66/0x90 [ 33.861838] printreport+0xce/0x620 [ 33.861853] kasanreport+0xda/0x110 [ 33.862794] kasancheckrange+0xfd/0x1a0 [ 33.862799] _asanmemset+0x23/0x40 [ 33.862803] smucmninitsoftgpumetrics+0x73/0x200 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.863306] vangoghgetgpumetricsv24+0x123/0xad0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.864257] vangoghcommongetgpumetrics+0xb0c/0xbc0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.865682] amdgpudpmgetgpumetrics+0xcc/0x110 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.866160] amdgpugetgpumetrics+0x154/0x2d0 [amdgpu 13b1bc364ec578808f676eba412c20eaab792779] [ 33.867135] devattrshow+0x43/0xc0 [ 33.867147] sysfskfseqshow+0x1f1/0x3b0 [ 33.867155] seqreaditer+0x3f8/0x1140 [ 33.867173] vfsread+0x76c/0xc50 [ 33.867198] ksysread+0xfb/0x1d0 [ 33.867214] dosyscall64+0x90/0x160 ... [ 33.867353] Allocated by task 378 on cpu 7 at 22.794876s: [ 33.867358] kasansavestack+0x33/0x50 [ 33.867364] kasansavetrack+0x17/0x60 [ 33.867367] _kasankmalloc+0x87/0x90 [ 33.867371] vangoghinitsmctables+0x3f9/0x840 [amdgpu] [ 33.867835] smuswinit+0xa32/0x1850 [amdgpu] [ 33.868299] amdgpudeviceinit+0x467b/0x8d90 [amdgpu] [ 33.868733] amdgpudriverloadkms+0x19/0xf0 [amdgpu] [ 33.869167] amdgpupciprobe+0x2d6/0xcd0 [amdgpu] [ 33.869608] localpciprobe+0xda/0x180 [ 33.869614] pcidevice_probe+0x43f/0x6b0

Empirically we can confirm that the former allocates 152 bytes for the table, while the latter memsets the 168 large block.

Root cause appears that when GPU metrics tables for v2_4 parts were added it was not considered to enlarge the table to fit.

The fix in this patch is rather "brute force" and perhaps later should be done in a smarter way, by extracting and consolidating the part version to size logic to a common helper, instead of brute forcing the largest possible allocation. Nevertheless, for now this works and fixes the out of bounds write.

v2: * Drop impossible v3_0 case. (Mario)

(cherry picked from commit 0880f58f9609f0200483a49429af0f050d281703)(CVE-2024-50221)

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

ipv4: iptunnel: Fix suspicious RCU usage warning in iptunnel_find()

The per-netns IP tunnel hash table is protected by the RTNL mutex and iptunnelfind() is only called from the control path where the mutex is taken.

Add a lockdep expression to hlistforeachentryrcu() in iptunnelfind() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1].

[1] WARNING: suspicious RCU usage

6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted

net/ipv4/ip_tunnel.c:221 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnlmutex){+.+.}-{3:3}, at: rtnetlinkrcvmsg+0x377/0xf60

stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl+0xba/0x110 lockdeprcususpicious.cold+0x4f/0xd6 iptunnelfind+0x435/0x4d0 iptunnelnewlink+0x517/0x7a0 ipgrenewlink+0x14c/0x170 rtnlnewlink+0x1173/0x19c0 rtnlnewlink+0x6c/0xa0 rtnetlinkrcvmsg+0x3cc/0xf60 netlinkrcvskb+0x171/0x450 netlinkunicast+0x539/0x7f0 netlinksendmsg+0x8c1/0xd80 _syssendmsg+0x8f9/0xc20 _syssendmsg+0x197/0x1e0 _syssendmsg+0x122/0x1f0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f(CVE-2024-50304)

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

drm/i915/hdcp: Add encoder check in intelhdcpget_capability

Sometimes during hotplug scenario or suspend/resume scenario encoder is not always initialized when intelhdcpget_capability add a check to avoid kernel null pointer dereference.(CVE-2024-53051)

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

nommu: pass NULL argument to vmaiterprealloc()

When deleting a vma entry from a maple tree, it has to pass NULL to vmaiterprealloc() in order to calculate internal state of the tree, but it passed a wrong argument. As a result, nommu kernels crashed upon accessing a vma iterator, such as acctcollect() reading the size of vma entries after domunmap().

This commit fixes this issue by passing a right argument to the preallocation call.(CVE-2024-53109)

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

mm: fix NULL pointer dereference in allocpagesbulk_noprof

We triggered a NULL pointer dereference for ac.preferredzoneref->zone in allocpagesbulknoprof() when the task is migrated between cpusets.

When cpuset is enabled, in prepareallocpages(), ac->nodemask may be &current->memsallowed. when firstzoneszonelist() is called to find preferredzoneref, the ac->nodemask may be modified concurrently if the task is migrated between different cpusets. Assuming we have 2 NUMA Node, when traversing Node1 in ac->zonelist, the nodemask is 2, and when traversing Node2 in ac->zonelist, the nodemask is 1. As a result, the ac->preferred_zoneref points to NULL zone.

In allocpagesbulknoprof(), foreachzonezonelistnodemask() finds a allowable zone and calls zonelistnodeidx(ac.preferredzoneref), leading to NULL pointer dereference.

_allocpagesnoprof() fixes this issue by checking NULL pointer in commit ea57485af8f4 ("mm, pagealloc: fix check for NULL preferredzone") and commit df76cee6bbeb ("mm, pagealloc: remove redundant checks from alloc fastpath").

To fix it, check NULL pointer for preferred_zoneref->zone.(CVE-2024-53113)

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

virtio/vsock: Fix accept_queue memory leak

As the final stages of socket destruction may be delayed, it is possible that virtiotransportrecvlisten() will be called after the acceptqueue has been flushed, but before the SOCK_DONE flag has been set. As a result, sockets enqueued after the flush would remain unremoved, leading to a memory leak.

vsockrelease _vsockrelease lock virtiotransportrelease virtiotransportclose scheduledelayedwork(closework) skshutdown = SHUTDOWNMASK (!) flush acceptqueue release virtiotransportrecvpkt vsockfindboundsocket lock if flag(SOCKDONE) return virtiotransportrecvlisten child = vsockcreateconnected (!) vsockenqueueaccept(child) release closework lock virtiotransportdoclose setflag(SOCKDONE) virtiotransportremovesock vsockremovesock vsockremovebound release

Introduce a skshutdown check to disallow vsockenqueue_accept() during socket destruction.

unreferenced object 0xffff888109e3f800 (size 2040): comm "kworker/5:2", pid 371, jiffies 4294940105 hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 28 00 0b 40 00 00 00 00 00 00 00 00 00 00 00 00 (..@............ backtrace (crc 9e5f4e84): [<ffffffff81418ff1>] kmemcacheallocnoprof+0x2c1/0x360 [<ffffffff81d27aa0>] skprotalloc+0x30/0x120 [<ffffffff81d2b54c>] skalloc+0x2c/0x4b0 [<ffffffff81fe049a>] _vsockcreate.constprop.0+0x2a/0x310 [<ffffffff81fe6d6c>] virtiotransportrecvpkt+0x4dc/0x9a0 [<ffffffff81fe745d>] vsockloopbackwork+0xfd/0x140 [<ffffffff810fc6ac>] processonework+0x20c/0x570 [<ffffffff810fce3f>] workerthread+0x1bf/0x3a0 [<ffffffff811070dd>] kthread+0xdd/0x110 [<ffffffff81044fdd>] retfromfork+0x2d/0x50 [<ffffffff8100785a>] retfromfork_asm+0x1a/0x30(CVE-2024-53119)

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

net/mlx5e: CT: Fix null-ptr-deref in add rule err flow

In error flow of mlx5tcctentryaddrule(), in case ctruleadd() callback returns error, zonerule->attr is used uninitiated. Fix it to use attr which has the needed pointer value.

Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5tcctentryaddrule+0x2b1/0x2f0 [mlx5core] … Call Trace: <TASK> ? _die+0x20/0x70 ? pagefaultoops+0x150/0x3e0 ? excpagefault+0x74/0x140 ? asmexcpagefault+0x22/0x30 ? mlx5tcctentryaddrule+0x2b1/0x2f0 [mlx5core] ? mlx5tcctentryaddrule+0x1d5/0x2f0 [mlx5core] mlx5tcctblockflowoffload+0xc6a/0xf90 [mlx5core] ? nfflowoffloadtuple+0xd8/0x190 [nfflowtable] nfflowoffloadtuple+0xd8/0x190 [nfflowtable] flowoffloadworkhandler+0x142/0x320 [nfflowtable] ? finishtaskswitch.isra.0+0x15b/0x2b0 processonework+0x16c/0x320 workerthread+0x28c/0x3a0 ? _pfxworkerthread+0x10/0x10 kthread+0xb8/0xf0 ? _pfxkthread+0x10/0x10 retfromfork+0x2d/0x50 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>(CVE-2024-53120)

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

net/mlx5: fs, lock FTE when checking if active

The referenced commits introduced a two-step process for deleting FTEs:

• Lock the FTE, delete it from hardware, set the hardware deletion function to NULL and unlock the FTE.
• Lock the parent flow group, delete the software copy of the FTE, and remove it from the xarray.

However, this approach encounters a race condition if a rule with the same match value is added simultaneously. In this scenario, fs_core may set the hardware deletion function to NULL prematurely, causing a panic during subsequent rule deletions.

To prevent this, ensure the active flag of the FTE is checked under a lock, which will prevent the fs_core layer from attaching a new steering rule to an FTE that is in the process of deletion.

[ 438.967589] MOSHE: 2496 mlx5delflowrules delhwfunc [ 438.968205] ------------[ cut here ]------------ [ 438.968654] refcountt: decrement hit 0; leaking memory. [ 438.969249] WARNING: CPU: 0 PID: 8957 at lib/refcount.c:31 refcountwarnsaturate+0xfb/0x110 [ 438.970054] Modules linked in: actmirred clsflower actgact schingress openvswitch nsh mlx5vdpa vringh vhostiotlb vdpa mlx5ib mlx5core xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry overlay rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi ibumad rdmacm ibipoib iwcm ibcm ibuverbs ibcore zram zsmalloc fuse [last unloaded: clsflower] [ 438.973288] CPU: 0 UID: 0 PID: 8957 Comm: tc Not tainted 6.12.0-rc1+ #8 [ 438.973888] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 [ 438.974874] RIP: 0010:refcountwarnsaturate+0xfb/0x110 [ 438.975363] Code: 40 66 3b 82 c6 05 16 e9 4d 01 01 e8 1f 7c a0 ff 0f 0b c3 cc cc cc cc 48 c7 c7 10 66 3b 82 c6 05 fd e8 4d 01 01 e8 05 7c a0 ff <0f> 0b c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 90 [ 438.976947] RSP: 0018:ffff888124a53610 EFLAGS: 00010286 [ 438.977446] RAX: 0000000000000000 RBX: ffff888119d56de0 RCX: 0000000000000000 [ 438.978090] RDX: ffff88852c828700 RSI: ffff88852c81b3c0 RDI: ffff88852c81b3c0 [ 438.978721] RBP: ffff888120fa0e88 R08: 0000000000000000 R09: ffff888124a534b0 [ 438.979353] R10: 0000000000000001 R11: 0000000000000001 R12: ffff888119d56de0 [ 438.979979] R13: ffff888120fa0ec0 R14: ffff888120fa0ee8 R15: ffff888119d56de0 [ 438.980607] FS: 00007fe6dcc0f800(0000) GS:ffff88852c800000(0000) knlGS:0000000000000000 [ 438.983984] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 438.984544] CR2: 00000000004275e0 CR3: 0000000186982001 CR4: 0000000000372eb0 [ 438.985205] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 438.985842] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 438.986507] Call Trace: [ 438.986799] <TASK> [ 438.987070] ? _warn+0x7d/0x110 [ 438.987426] ? refcountwarnsaturate+0xfb/0x110 [ 438.987877] ? reportbug+0x17d/0x190 [ 438.988261] ? prbreadvalid+0x17/0x20 [ 438.988659] ? handlebug+0x53/0x90 [ 438.989054] ? excinvalidop+0x14/0x70 [ 438.989458] ? asmexcinvalidop+0x16/0x20 [ 438.989883] ? refcountwarnsaturate+0xfb/0x110 [ 438.990348] mlx5delflowrules+0x2f7/0x340 [mlx5core] [ 438.990932] _mlx5eswitchdelrule+0x49/0x170 [mlx5core] [ 438.991519] ? mlx5lagissriov+0x3c/0x50 [mlx5core] [ 438.992054] ? xasload+0x9/0xb0 [ 438.992407] mlx5etcruleunoffload+0x45/0xe0 [mlx5core] [ 438.993037] mlx5etcdelfdbflow+0x2a6/0x2e0 [mlx5core] [ 438.993623] mlx5eflowput+0x29/0x60 [mlx5core] [ 438.994161] mlx5edeleteflower+0x261/0x390 [mlx5core] [ 438.994728] tcsetupcbdestroy+0xb9/0x190 [ 438.995150] flhwdestroyfilter+0x94/0xc0 [clsflower] [ 438.995650] flchange+0x11a4/0x13c0 [clsflower] [ 438.996105] tcnewtfilter+0x347/0xbc0 [ 438.996503] ? __ ---truncated---(CVE-2024-53121)

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

mptcp: cope racing subflow creation in mptcprcvspace_adjust

Additional active subflows - i.e. created by the in kernel path manager - are included into the subflow list before starting the 3whs.

A racing recvmsg() spooling data received on an already established subflow would unconditionally call tcpcleanuprbuf() on all the current subflows, potentially hitting a divide by zero error on the newly created ones.

Explicitly check that the subflow is in a suitable state before invoking tcpcleanuprbuf().(CVE-2024-53122)

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

mptcp: error out earlier on disconnect

Eric reported a division by zero splat in the MPTCP protocol:

Oops: divide error: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 UID: 0 PID: 6094 Comm: syz-executor317 Not tainted 6.12.0-rc5-syzkaller-00291-g05b92660cdfe #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:_tcpselectwindow+0x5b4/0x1310 net/ipv4/tcpoutput.c:3163 Code: f6 44 01 e3 89 df e8 9b 75 09 f8 44 39 f3 0f 8d 11 ff ff ff e8 0d 74 09 f8 45 89 f4 e9 04 ff ff ff e8 00 74 09 f8 44 89 f0 99 <f7> 7c 24 14 41 29 d6 45 89 f4 e9 ec fe ff ff e8 e8 73 09 f8 48 89 RSP: 0018:ffffc900041f7930 EFLAGS: 00010293 RAX: 0000000000017e67 RBX: 0000000000017e67 RCX: ffffffff8983314b RDX: 0000000000000000 RSI: ffffffff898331b0 RDI: 0000000000000004 RBP: 00000000005d6000 R08: 0000000000000004 R09: 0000000000017e67 R10: 0000000000003e80 R11: 0000000000000000 R12: 0000000000003e80 R13: ffff888031d9b440 R14: 0000000000017e67 R15: 00000000002eb000 FS: 00007feb5d7f16c0(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007feb5d8adbb8 CR3: 0000000074e4c000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> _tcpcleanuprbuf+0x3e7/0x4b0 net/ipv4/tcp.c:1493 mptcprcvspaceadjust net/mptcp/protocol.c:2085 [inline] mptcprecvmsg+0x2156/0x2600 net/mptcp/protocol.c:2289 inetrecvmsg+0x469/0x6a0 net/ipv4/afinet.c:885 sockrecvmsgnosec net/socket.c:1051 [inline] sockrecvmsg+0x1b2/0x250 net/socket.c:1073 _sysrecvfrom+0x1a5/0x2e0 net/socket.c:2265 _dosysrecvfrom net/socket.c:2283 [inline] _sesysrecvfrom net/socket.c:2279 [inline] _x64sysrecvfrom+0xe0/0x1c0 net/socket.c:2279 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7feb5d857559 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 51 18 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 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007feb5d7f1208 EFLAGS: 00000246 ORIGRAX: 000000000000002d RAX: ffffffffffffffda RBX: 00007feb5d8e1318 RCX: 00007feb5d857559 RDX: 000000800000000e RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007feb5d8e1310 R08: 0000000000000000 R09: ffffffff81000000 R10: 0000000000000100 R11: 0000000000000246 R12: 00007feb5d8e131c R13: 00007feb5d8ae074 R14: 000000800000000e R15: 00000000fffffdef

and provided a nice reproducer.

The root cause is the current bad handling of racing disconnect. After the blamed commit below, skwaitdata() can return (with error) with the underlying socket disconnected and a zero rcv_mss.

Catch the error and return without performing any additional operations on the current socket.(CVE-2024-53123)

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

net: fix data-races around sk->skforwardalloc

Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/afinet.c:156 inetsockdestruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inetsockdestruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? _warn+0x88/0x130 ? inetsockdestruct+0x1c5/0x1e0 ? reportbug+0x18e/0x1a0 ? handlebug+0x53/0x90 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x1c5/0x1e0 _skdestruct+0x2a/0x200 rcudobatch+0x1aa/0x530 ? rcudobatch+0x13b/0x530 rcucore+0x159/0x2f0 handlesoftirqs+0xd3/0x2b0 ? _pfxsmpbootthreadfn+0x10/0x10 runksoftirqd+0x25/0x30 smpbootthreadfn+0xdd/0x1d0 kthread+0xd3/0x100 ? _pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---

Its possible that two threads call tcpv6dorcv()/skforwardallocadd() concurrently when sk->skstate == TCPLISTEN with sk->sklock unlocked, which triggers a data-race around sk->skforwardalloc: tcpv6rcv tcpv6dorcv skbcloneandcharger skrmemschedule _skmemschedule skforwardallocadd() skbsetownerr skmemcharge skforwardallocadd() _kfreeskb skbreleaseall skbreleaseheadstate sockrfree skmemuncharge skforwardallocadd() skmemreclaim // set local var reclaimable _skmemreclaim skforwardalloc_add()

In this syzkaller testcase, two threads call tcpv6dorcv() with skb->truesize=768, the skforwardalloc changes like this: (cpu 1) | (cpu 2) | skforwardalloc ... | ... | 0 _skmemschedule() | | +4096 = 4096 | _skmemschedule() | +4096 = 8192 skmemcharge() | | -768 = 7424 | skmemcharge() | -768 = 6656 ... | ... | skmemuncharge() | | +768 = 7424 reclaimable=7424 | | | skmemuncharge() | +768 = 8192 | reclaimable=8192 | _skmemreclaim() | | -4096 = 4096 | _skmem_reclaim() | -8192 = -4096 != 0

The skbcloneandcharger() should not be called in tcpv6dorcv() when sk->skstate is TCPLISTEN, it happens later in tcpv6synrecvsock(). Fix the same issue in dccpv6dorcv().(CVE-2024-53124)

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

KVM: VMX: Bury Intel PT virtualization (guest/host mode) behind CONFIG_BROKEN

Hide KVM's ptmode module param behind CONFIGBROKEN, i.e. disable support for virtualizing Intel PT via guest/host mode unless BROKEN=y. There are myriad bugs in the implementation, some of which are fatal to the guest, and others which put the stability and health of the host at risk.

For guest fatalities, the most glaring issue is that KVM fails to ensure tracing is disabled, and stays disabled prior to VM-Enter, which is necessary as hardware disallows loading (the guest's) RTIT_CTL if tracing is enabled (enforced via a VMX consistency check). Per the SDM:

If the logical processor is operating with Intel PT enabled (if IA32RTITCTL.TraceEn = 1) at the time of VM entry, the "load IA32RTITCTL" VM-entry control must be 0.

On the host side, KVM doesn't validate the guest CPUID configuration provided by userspace, and even worse, uses the guest configuration to decide what MSRs to save/load at VM-Enter and VM-Exit. E.g. configuring guest CPUID to enumerate more address ranges than are supported in hardware will result in KVM trying to passthrough, save, and load non-existent MSRs, which generates a variety of WARNs, ToPA ERRORs in the host, a potential deadlock, etc.(CVE-2024-53135)

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

net/mlx5e: kTLS, Fix incorrect page refcounting

The kTLS tx handling code is using a mix of getpage() and pagerefinc() APIs to increment the page reference. But on the release path (mlx5ektlstxhandleresyncdumpcomp()), only putpage() is used.

This is an issue when using pages from large folios: the getpage() references are stored on the folio page while the pageref_inc() references are stored directly in the given page. On release the folio page will be dereferenced too many times.

This was found while doing kTLS testing with sendfile() + ZC when the served file was read from NFS on a kernel with NFS large folios support (commit 49b29a573da8 ("nfs: add support for large folios")).(CVE-2024-53138)

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

sctp: fix possible UAF in sctpv6available()

A lockdep report [1] with CONFIGPROVERCULIST=y hints that sctpv6available() is calling devgetbyindexrcu() and ipv6chk_addr() without holding rcu.

[1] ============================= WARNING: suspicious RCU usage 6.12.0-rc5-virtme #1216 Tainted: G W

net/core/dev.c:876 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by sctphello/31495: #0: ffff9f1ebbdb7418 (sklock-AFINET6){+.+.}-{0:0}, at: sctpbind (./arch/x86/include/asm/jumplabel.h:27 net/sctp/socket.c:315) sctp

stack backtrace: CPU: 7 UID: 0 PID: 31495 Comm: sctphello Tainted: G W 6.12.0-rc5-virtme #1216 Tainted: [W]=WARN Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:123) lockdeprcususpicious (kernel/locking/lockdep.c:6822) devgetbyindexrcu (net/core/dev.c:876 (discriminator 7)) sctpv6available (net/sctp/ipv6.c:701) sctp sctpdobind (net/sctp/socket.c:400 (discriminator 1)) sctp sctpbind (net/sctp/socket.c:320) sctp inet6bindsk (net/ipv6/afinet6.c:465) ? securitysocketbind (security/security.c:4581 (discriminator 1)) _sysbind (net/socket.c:1848 net/socket.c:1869) ? douseraddrfault (./include/linux/rcupdate.h:347 ./include/linux/rcupdate.h:880 ./include/linux/mm.h:729 arch/x86/mm/fault.c:1340) ? douseraddrfault (./arch/x86/include/asm/preempt.h:84 (discriminator 13) ./include/linux/rcupdate.h:98 (discriminator 13) ./include/linux/rcupdate.h:882 (discriminator 13) ./include/linux/mm.h:729 (discriminator 13) arch/x86/mm/fault.c:1340 (discriminator 13)) _x64sysbind (net/socket.c:1877 (discriminator 1) net/socket.c:1875 (discriminator 1) net/socket.c:1875 (discriminator 1)) dosyscall64 (arch/x86/entry/common.c:52 (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1)) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130) RIP: 0033:0x7f59b934a1e7 Code: 44 00 00 48 8b 15 39 8c 0c 00 f7 d8 64 89 02 b8 ff ff ff ff eb bd 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 b8 31 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 09 8c 0c 00 f7 d8 64 89 01 48

All code

0: 44 00 00 add %r8b,(%rax) 3: 48 8b 15 39 8c 0c 00 mov 0xc8c39(%rip),%rdx # 0xc8c43 a: f7 d8 neg %eax c: 64 89 02 mov %eax,%fs:(%rdx) f: b8 ff ff ff ff mov $0xffffffff,%eax 14: eb bd jmp 0xffffffffffffffd3 16: 66 2e 0f 1f 84 00 00 cs nopw 0x0(%rax,%rax,1) 1d: 00 00 00 20: 0f 1f 00 nopl (%rax) 23: b8 31 00 00 00 mov $0x31,%eax 28: 0f 05 syscall 2a:* 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax <-- trapping instruction 30: 73 01 jae 0x33 32: c3 ret 33: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c43 3a: f7 d8 neg %eax 3c: 64 89 01 mov %eax,%fs:(%rcx) 3f: 48 rex.W

Code starting with the faulting instruction

0: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax 6: 73 01 jae 0x9 8: c3 ret 9: 48 8b 0d 09 8c 0c 00 mov 0xc8c09(%rip),%rcx # 0xc8c19 10: f7 d8 neg %eax 12: 64 89 01 mov %eax,%fs:(%rcx) 15: 48 rex.W RSP: 002b:00007ffe2d0ad398 EFLAGS: 00000202 ORIG_RAX: 0000000000000031 RAX: ffffffffffffffda RBX: 00007ffe2d0ad3d0 RCX: 00007f59b934a1e7 RDX: 000000000000001c RSI: 00007ffe2d0ad3d0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 1999999999999999 R09: 0000000000000000 R10: 00007f59b9253298 R11: 000000000000 ---truncated---(CVE-2024-53139)

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

netlink: terminate outstanding dump on socket close

Netlink supports iterative dumping of data. It provides the families the following ops: - start - (optional) kicks off the dumping process - dump - actual dump helper, keeps getting called until it returns 0 - done - (optional) pairs with .start, can be used for cleanup The whole process is asynchronous and the repeated calls to .dump don't actually happen in a tight loop, but rather are triggered in response to recvmsg() on the socket.

This gives the user full control over the dump, but also means that the user can close the socket without getting to the end of the dump. To make sure .start is always paired with .done we check if there is an ongoing dump before freeing the socket, and if so call .done.

The complication is that sockets can get freed from BH and .done is allowed to sleep. So we use a workqueue to defer the call, when needed.

Unfortunately this does not work correctly. What we defer is not the cleanup but rather releasing a reference on the socket. We have no guarantee that we own the last reference, if someone else holds the socket they may release it in BH and we're back to square one.

The whole dance, however, appears to be unnecessary. Only the user can interact with dumps, so we can clean up when socket is closed. And close always happens in process context. Some async code may still access the socket after close, queue notification skbs to it etc. but no dumps can start, end or otherwise make progress.

Delete the workqueue and flush the dump state directly from the release handler. Note that further cleanup is possible in -next, for instance we now always call .done before releasing the main module reference, so dump doesn't have to take a reference of its own.(CVE-2024-53140)

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

um: Fix potential integer overflow during physmem setup

This issue happens when the real map size is greater than LONG_MAX, which can be easily triggered on UML/i386.(CVE-2024-53145)

In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null check for pipectx->planestate in dcn20programpipeThis commit addresses a null pointer dereference issue indcn20programpipe(). Previously, commit 8e4ed3cf1642 ( drm/amd/display:Add null check for pipectx->planestate in dcn20programpipe )partially fixed the null pointer dereference issue. However, indcn20updatedchubpdpp(), the variable pipectx is passed in, andplanestate is accessed again through pipectx. Multiple if statementsdirectly call attributes of plane_state, leading to potential nullpointer dereference issues. This patch adds necessary null checks toensure stability.(CVE-2024-53201)

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

Bluetooth: MGMT: Fix possible deadlocks

This fixes possible deadlocks like the following caused by hcicmdsync_dequeue causing the destroy function to run:

INFO: task kworker/u19:0:143 blocked for more than 120 seconds. Tainted: G W O 6.8.0-2024-03-19-intel-next-iLS-24ww14 #1 "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:kworker/u19:0 state:D stack:0 pid:143 tgid:143 ppid:2 flags:0x00004000 Workqueue: hci0 hcicmdsyncwork [bluetooth] Call Trace: <TASK> _schedule+0x374/0xaf0 schedule+0x3c/0xf0 schedulepreemptdisabled+0x1c/0x30 _mutexlock.constprop.0+0x3ef/0x7a0 _mutexlockslowpath+0x13/0x20 mutexlock+0x3c/0x50 mgmtsetconnectablecomplete+0xa4/0x150 [bluetooth] ? kfree+0x211/0x2a0 hcicmdsyncdequeue+0xae/0x130 [bluetooth] ? _pfxcmdcompletersp+0x10/0x10 [bluetooth] cmdcompletersp+0x26/0x80 [bluetooth] mgmtpendingforeach+0x4d/0x70 [bluetooth] _mgmtpoweroff+0x8d/0x180 [bluetooth] ? rawspinunlockirq+0x23/0x40 hcidevclosesync+0x445/0x5b0 [bluetooth] hcisetpoweredsync+0x149/0x250 [bluetooth] setpoweredsync+0x24/0x60 [bluetooth] hcicmdsyncwork+0x90/0x150 [bluetooth] processonework+0x13e/0x300 workerthread+0x2f7/0x420 ? _pfxworkerthread+0x10/0x10 kthread+0x107/0x140 ? _pfxkthread+0x10/0x10 retfromfork+0x3d/0x60 ? _pfxkthread+0x10/0x10 retfromforkasm+0x1b/0x30 </TASK>(CVE-2024-53207)

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

bnxt_en: Fix receive ring space parameters when XDP is active

The MTU setting at the time an XDP multi-buffer is attached determines whether the aggregation ring will be used and the rxskbfunc handler. This is done in bnxtsetrxskbmode().

If the MTU is later changed, the aggregation ring setting may need to be changed and it may become out-of-sync with the settings initially done in bnxtsetrxskbmode(). This may result in random memory corruption and crashes as the HW may DMA data larger than the allocated buffer size, such as:

BUG: kernel NULL pointer dereference, address: 00000000000003c0 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 17 PID: 0 Comm: swapper/17 Kdump: loaded Tainted: G S OE 6.1.0-226bf9805506 #1 Hardware name: Wiwynn Delta Lake PVT BZA.02601.0150/Delta Lake-Class1, BIOS F0E3A12 08/26/2021 RIP: 0010:bnxtrxpkt+0xe97/0x1ae0 [bnxten] Code: 8b 95 70 ff ff ff 4c 8b 9d 48 ff ff ff 66 41 89 87 b4 00 00 00 e9 0b f7 ff ff 0f b7 43 0a 49 8b 95 a8 04 00 00 25 ff 0f 00 00 <0f> b7 14 42 48 c1 e2 06 49 03 95 a0 04 00 00 0f b6 42 33f RSP: 0018:ffffa19f40cc0d18 EFLAGS: 00010202 RAX: 00000000000001e0 RBX: ffff8e2c805c6100 RCX: 00000000000007ff RDX: 0000000000000000 RSI: ffff8e2c271ab990 RDI: ffff8e2c84f12380 RBP: ffffa19f40cc0e48 R08: 000000000001000d R09: 974ea2fcddfa4cbf R10: 0000000000000000 R11: ffffa19f40cc0ff8 R12: ffff8e2c94b58980 R13: ffff8e2c952d6600 R14: 0000000000000016 R15: ffff8e2c271ab990 FS: 0000000000000000(0000) GS:ffff8e3b3f840000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000000003c0 CR3: 0000000e8580a004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <IRQ> _bnxtpollwork+0x1c2/0x3e0 [bnxten]

To address the issue, we now call bnxtsetrxskbmode() within bnxtchangemtu() to properly set the AGG rings configuration and update rxskbfunc based on the new MTU value. Additionally, BNXTFLAGNOAGGRINGS is cleared at the beginning of bnxtsetrxskbmode() to make sure it gets set or cleared based on the current MTU.(CVE-2024-53209)

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

clk: ralink: mtmips: fix clocks probe order in oldest ralink SoCs

Base clocks are the first in being probed and are real dependencies of the rest of fixed, factor and peripheral clocks. For old ralink SoCs RT2880, RT305x and RT3883 'xtal' must be defined first since in any other case, when fixed clocks are probed they are delayed until 'xtal' is probed so the following warning appears:

WARNING: CPU: 0 PID: 0 at drivers/clk/ralink/clk-mtmips.c:499 rt3883busrecalcrate+0x98/0x138 Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.43 #0 Stack : 805e58d0 00000000 00000004 8004f950 00000000 00000004 00000000 00000000 80669c54 80830000 80700000 805ae570 80670068 00000001 80669bf8 00000000 00000000 00000000 805ae570 80669b38 00000020 804db7dc 00000000 00000000 203a6d6d 80669b78 80669e48 70617773 00000000 805ae570 00000000 00000009 00000000 00000001 00000004 00000001 00000000 00000000 83fe43b0 00000000 ... Call Trace: [<800065d0>] showstack+0x64/0xf4 [<804bca14>] dumpstacklvl+0x38/0x60 [<800218ac>] _warn+0x94/0xe4 [<8002195c>] warnslowpathfmt+0x60/0x94 [<80259ff8>] rt3883busrecalcrate+0x98/0x138 [<80254530>] _clkregister+0x568/0x688 [<80254838>] ofclkhwregister+0x18/0x2c [<8070b910>] rt2880clkofclkinitdriver+0x18c/0x594 [<8070b628>] ofclkinit+0x1c0/0x23c [<806fc448>] plattimeinit+0x58/0x18c [<806fdaf0>] timeinit+0x10/0x6c [<806f9bc4>] startkernel+0x458/0x67c

---[ end trace 0000000000000000 ]---

When this driver was mainlined we could not find any active users of old ralink SoCs so we cannot perform any real tests for them. Now, one user of a Belkin f9k1109 version 1 device which uses RT3883 SoC appeared and reported some issues in openWRT: - https://github.com/openwrt/openwrt/issues/16054

Thus, define a 'rt2880xtalrecalc_rate()' just returning the expected frequency 40Mhz and use it along the old ralink SoCs to have a correct boot trace with no warnings and a working clock plan from the beggining.(CVE-2024-53223)

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

Bluetooth: fix use-after-free in deviceforeach_child()

Syzbot has reported the following KASAN splat:

BUG: KASAN: slab-use-after-free in deviceforeach_child+0x18f/0x1a0 Read of size 8 at addr ffff88801f605308 by task kbnepd bnep0/4980

CPU: 0 UID: 0 PID: 4980 Comm: kbnepd bnep0 Not tainted 6.12.0-rc4-00161-gae90f6a6170d #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x100/0x190 ? deviceforeachchild+0x18f/0x1a0 printreport+0x13a/0x4cb ? _virtaddrvalid+0x5e/0x590 ? _physaddr+0xc6/0x150 ? deviceforeachchild+0x18f/0x1a0 kasanreport+0xda/0x110 ? deviceforeachchild+0x18f/0x1a0 ? _pfxdevmemallocnoio+0x10/0x10 deviceforeachchild+0x18f/0x1a0 ? _pfxdeviceforeachchild+0x10/0x10 pmruntimesetmemallocnoio+0xf2/0x180 netdevunregisterkobject+0x1ed/0x270 unregisternetdevicemanynotify+0x123c/0x1d80 ? _mutextrylockcommon+0xde/0x250 ? _pfxunregisternetdevicemanynotify+0x10/0x10 ? tracecontentionend+0xe6/0x140 ? _mutexlock+0x4e7/0x8f0 ? _pfxlockacquire.part.0+0x10/0x10 ? rcuiswatching+0x12/0xc0 ? unregisternetdev+0x12/0x30 unregisternetdevicequeue+0x30d/0x3f0 ? _pfxunregisternetdevicequeue+0x10/0x10 ? _pfxdownwrite+0x10/0x10 unregisternetdev+0x1c/0x30 bnepsession+0x1fb3/0x2ab0 ? _pfxbnepsession+0x10/0x10 ? _pfxlockrelease+0x10/0x10 ? _pfxwokenwakefunction+0x10/0x10 ? _kthreadparkme+0x132/0x200 ? _pfxbnepsession+0x10/0x10 ? kthread+0x13a/0x370 ? _pfxbnepsession+0x10/0x10 kthread+0x2b7/0x370 ? _pfxkthread+0x10/0x10 retfromfork+0x48/0x80 ? _pfxkthread+0x10/0x10 retfromfork_asm+0x1a/0x30 </TASK>

Allocated by task 4974: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 _kasankmalloc+0xaa/0xb0 _kmallocnoprof+0x1d1/0x440 hciallocdevpriv+0x1d/0x2820 _vhcicreatedevice+0xef/0x7d0 vhciwrite+0x2c7/0x480 vfswrite+0x6a0/0xfc0 ksyswrite+0x12f/0x260 dosyscall64+0xc7/0x250 entrySYSCALL64after_hwframe+0x77/0x7f

Freed by task 4979: kasansavestack+0x30/0x50 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 _kasanslabfree+0x4f/0x70 kfree+0x141/0x490 hcireleasedev+0x4d9/0x600 bthostrelease+0x6a/0xb0 devicerelease+0xa4/0x240 kobjectput+0x1ec/0x5a0 putdevice+0x1f/0x30 vhcirelease+0x81/0xf0 _fput+0x3f6/0xb30 taskworkrun+0x151/0x250 doexit+0xa79/0x2c30 dogroupexit+0xd5/0x2a0 getsignal+0x1fcd/0x2210 archdosignalorrestart+0x93/0x780 syscallexittousermode+0x140/0x290 dosyscall64+0xd4/0x250 entrySYSCALL64after_hwframe+0x77/0x7f

In 'hciconndelsysfs()', 'deviceunregister()' may be called when an underlying (kobject) reference counter is greater than 1. This means that reparenting (happened when the device is actually freed) is delayed and, during that delay, parent controller device (hciX) may be deleted. Since the latter may create a dangling pointer to freed parent, avoid that scenario by reparenting to NULL explicitly.(CVE-2024-53237)

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

accel/ivpu: Fix WARN in ivpuipcsendreceiveinternal()

Move pmruntimesetactive() to ivpupminit() so when ivpuipcsendreceiveinternal() is executed before ivpupm_enable() it already has correct runtime state, even if last resume was not successful..(CVE-2024-54193)

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

iio: adc: ad7923: Fix buffer overflow for txbuf and ringxfer

The AD7923 was updated to support devices with 8 channels, but the size of txbuf and ringxfer was not increased accordingly, leading to a potential buffer overflow in ad7923updatescan_mode().(CVE-2024-56557)

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

ad7780: fix division by zero in ad7780writeraw()

In the ad7780writeraw() , val2 can be zero, which might lead to a division by zero error in DIVROUNDCLOSEST(). The ad7780writeraw() is based on iioinfo's writeraw. While val is explicitly declared that can be zero (in read mode), val2 is not specified to be non-zero.(CVE-2024-56567)

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

Bluetooth: hcicore: Fix not checking skb length on hciacldata_packet

This fixes not checking if skb really contains an ACL header otherwise the code may attempt to access some uninitilized/invalid memory past the valid skb->data.(CVE-2024-56590)

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

xsk: fix OOB map writes when deleting elements

Jordy says:

" In the xskmapdeleteelem function an unsigned integer (map->maxentries) is compared with a user-controlled signed integer (k). Due to implicit type conversion, a large unsigned value for map->max_entries can bypass the intended bounds check:

if (k >= map->max_entries)
    return -EINVAL;

This allows k to hold a negative value (between -2147483648 and -2), which is then used as an array index in m->xsk_map[k], which results in an out-of-bounds access.

spin_lock_bh(&m->lock);
map_entry = &m->xsk_map[k]; // Out-of-bounds map_entry
old_xs = unrcu_pointer(xchg(map_entry, NULL));  // Oob write
if (old_xs)
    xsk_map_sock_delete(old_xs, map_entry);
spin_unlock_bh(&m->lock);

The xchg operation can then be used to cause an out-of-bounds write. Moreover, the invalid mapentry passed to xskmapsockdelete can lead to further memory corruption. "

It indeed results in following splat:

[76612.897343] BUG: unable to handle page fault for address: ffffc8fc2e461108 [76612.904330] #PF: supervisor write access in kernel mode [76612.909639] #PF: errorcode(0x0002) - not-present page [76612.914855] PGD 0 P4D 0 [76612.917431] Oops: Oops: 0002 [#1] PREEMPT SMP [76612.921859] CPU: 11 UID: 0 PID: 10318 Comm: a.out Not tainted 6.12.0-rc1+ #470 [76612.929189] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019 [76612.939781] RIP: 0010:xskmapdeleteelem+0x2d/0x60 [76612.944738] Code: 00 00 41 54 55 53 48 63 2e 3b 6f 24 73 38 4c 8d a7 f8 00 00 00 48 89 fb 4c 89 e7 e8 2d bf 05 00 48 8d b4 eb 00 01 00 00 31 ff <48> 87 3e 48 85 ff 74 05 e8 16 ff ff ff 4c 89 e7 e8 3e bc 05 00 31 [76612.963774] RSP: 0018:ffffc9002e407df8 EFLAGS: 00010246 [76612.969079] RAX: 0000000000000000 RBX: ffffc9002e461000 RCX: 0000000000000000 [76612.976323] RDX: 0000000000000001 RSI: ffffc8fc2e461108 RDI: 0000000000000000 [76612.983569] RBP: ffffffff80000001 R08: 0000000000000000 R09: 0000000000000007 [76612.990812] R10: ffffc9002e407e18 R11: ffff888108a38858 R12: ffffc9002e4610f8 [76612.998060] R13: ffff888108a38858 R14: 00007ffd1ae0ac78 R15: ffffc9002e4610c0 [76613.005303] FS: 00007f80b6f59740(0000) GS:ffff8897e0ec0000(0000) knlGS:0000000000000000 [76613.013517] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [76613.019349] CR2: ffffc8fc2e461108 CR3: 000000011e3ef001 CR4: 00000000007726f0 [76613.026595] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [76613.033841] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [76613.041086] PKRU: 55555554 [76613.043842] Call Trace: [76613.046331] <TASK> [76613.048468] ? _die+0x20/0x60 [76613.051581] ? pagefaultoops+0x15a/0x450 [76613.055747] ? searchextable+0x22/0x30 [76613.059649] ? searchbpfextables+0x5f/0x80 [76613.063988] ? excpagefault+0xa9/0x140 [76613.067975] ? asmexcpagefault+0x22/0x30 [76613.072229] ? xskmapdeleteelem+0x2d/0x60 [76613.076573] ? xskmapdeleteelem+0x23/0x60 [76613.080914] _sysbpf+0x19b7/0x23c0 [76613.084555] _x64sysbpf+0x1a/0x20 [76613.088194] dosyscall64+0x37/0xb0 [76613.091832] entrySYSCALL64afterhwframe+0x4b/0x53 [76613.096962] RIP: 0033:0x7f80b6d1e88d [76613.100592] Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 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 8b 0d 73 b5 0f 00 f7 d8 64 89 01 48 [76613.119631] RSP: 002b:00007ffd1ae0ac68 EFLAGS: 00000206 ORIG_RAX: 0000000000000141 [76613.131330] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f80b6d1e88d [76613.142632] RDX: 0000000000000098 RSI: 00007ffd1ae0ad20 RDI: 0000000000000003 [76613.153967] RBP: 00007ffd1ae0adc0 R08: 0000000000000000 R09: 0000000000000000 [76613.166030] R10: 00007f80b6f77040 R11: 0000000000000206 R12: 00007ffd1ae0aed8 [76613.177130] R13: 000055ddf42ce1e9 R14: 000055ddf42d0d98 R15: 00 ---truncated---(CVE-2024-56614)

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

scsi: qla2xxx: Fix use after free on unload

System crash is observed with stack trace warning of use after free. There are 2 signals to tell dpcthread to terminate (UNLOADING flag and kthreadstop).

On setting the UNLOADING flag when dpcthread happens to run at the time and sees the flag, this causes dpcthread to exit and clean up itself. When kthread_stop is called for final cleanup, this causes use after free.

Remove UNLOADING signal to terminate dpcthread. Use the kthreadstop as the main signal to exit dpc_thread.

[596663.812935] kernel BUG at mm/slub.c:294! [596663.812950] invalid opcode: 0000 [#1] SMP PTI [596663.812957] CPU: 13 PID: 1475935 Comm: rmmod Kdump: loaded Tainted: G IOE --------- - - 4.18.0-240.el8.x8664 #1 [596663.812960] Hardware name: HP ProLiant DL380p Gen8, BIOS P70 08/20/2012 [596663.812974] RIP: 0010:slabfree+0x17d/0x360

... [596663.813008] Call Trace: [596663.813022] ? _dentrykill+0x121/0x170 [596663.813030] ? condresched+0x15/0x30 [596663.813034] ? condresched+0x15/0x30 [596663.813039] ? waitforcompletion+0x35/0x190 [596663.813048] ? trytowakeup+0x63/0x540 [596663.813055] freetask+0x5a/0x60 [596663.813061] kthreadstop+0xf3/0x100 [596663.813103] qla2x00remove_one+0x284/0x440 qla2xxx

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

net/smc: fix LGR and link use-after-free issue

We encountered a LGR/link use-after-free issue, which manifested as the LGR/link refcnt reaching 0 early and entering the clear process, making resource access unsafe.

refcountt: addition on 0; use-after-free. WARNING: CPU: 14 PID: 107447 at lib/refcount.c:25 refcountwarnsaturate+0x9c/0x140 Workqueue: events smclgrterminatework [smc] Call trace: refcountwarnsaturate+0x9c/0x140 _smclgrterminate.part.45+0x2a8/0x370 [smc] smclgrterminatework+0x28/0x30 [smc] processonework+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118

or

refcountt: underflow; use-after-free. WARNING: CPU: 6 PID: 93140 at lib/refcount.c:28 refcountwarnsaturate+0xf0/0x140 Workqueue: smchswq smclistenwork [smc] Call trace: refcountwarnsaturate+0xf0/0x140 smcrlinkput+0x1cc/0x1d8 [smc] smcconnfree+0x110/0x1b0 [smc] smcconnabort+0x50/0x60 [smc] smclistenfinddevice+0x75c/0x790 [smc] smclistenwork+0x368/0x8a0 [smc] processonework+0x1b8/0x420 worker_thread+0x158/0x510 kthread+0x114/0x118

It is caused by repeated release of LGR/link refcnt. One suspect is that smcconnfree() is called repeatedly because some smcconnfree() from server listening path are not protected by sock lock.

e.g.

Calls under socklock | smclistenwork

locksock(sk) | smcconnabort smcconnfree | - smcconnfree - smcrlinkput | - smcrlinkput (duplicated) releasesock(sk)

So here add sock lock protection in smclistenwork() path, making it exclusive with other connection operations.(CVE-2024-56640)

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

net/smc: initialize close_work early to avoid warning

We encountered a warning that close_work was canceled before initialization.

WARNING: CPU: 7 PID: 111103 at kernel/workqueue.c:3047 flushwork+0x19e/0x1b0 Workqueue: events smclgrterminatework [smc] RIP: 0010:flushwork+0x19e/0x1b0 Call Trace: ? _wakeupcommon+0x7a/0x190 ? workbusy+0x80/0x80 _cancelworktimer+0xe3/0x160 smcclosecancelwork+0x1a/0x70 [smc] smccloseactiveabort+0x207/0x360 [smc] _smclgrterminate.part.38+0xc8/0x180 [smc] processonework+0x19e/0x340 workerthread+0x30/0x370 ? processonework+0x340/0x340 kthread+0x117/0x130 ? _kthreadcancelwork+0x50/0x50 retfrom_fork+0x22/0x30

This is because when smcclosecancelwork is triggered, e.g. the RDMA driver is rmmod and the LGR is terminated, the conn->closework is flushed before initialization, resulting in WARN_ON(!work->func).

_smclgrterminate | smcconnect_{rdma|ism}

                            | smc_conn_create
            | \- smc_lgr_register_conn

for conn in lgr->connsall | - smcconnkill | - smccloseactiveabort | - smcclosecancelwork | - cancelworksync | - _flushwork | (closework) | | smccloseinit | - INITWORK(&closework)

So fix this by initializing close_work before establishing the connection.(CVE-2024-56641)

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

Bluetooth: btmtk: avoid UAF in btmtkprocesscoredump

hcidevcdappend may lead to the release of the skb, so it cannot be accessed once it is called.

================================================================== BUG: KASAN: slab-use-after-free in btmtkprocesscoredump+0x2a7/0x2d0 [btmtk] Read of size 4 at addr ffff888033cfabb0 by task kworker/0:3/82

CPU: 0 PID: 82 Comm: kworker/0:3 Tainted: G U 6.6.40-lockdep-03464-g1d8b4eb3060e #1 b0b3c1cc0c842735643fb411799d97921d1f688c Hardware name: Google YaviksUfs/YaviksUfs, BIOS GoogleYaviksUfs.15217.552.0 05/07/2024 Workqueue: events btusbrxwork [btusb] Call Trace: <TASK> dumpstacklvl+0xfd/0x150 printreport+0x131/0x780 kasanreport+0x177/0x1c0 btmtkprocesscoredump+0x2a7/0x2d0 [btmtk 03edd567dd71a65958807c95a65db31d433e1d01] btusbrecvaclmtk+0x11c/0x1a0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] btusbrxwork+0x9e/0xe0 [btusb 675430d1e87c4f24d0c1f80efe600757a0f32bec] workerthread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 retfromfork+0x51/0x80 retfromfork_asm+0x1b/0x30 </TASK>

Allocated by task 82: stacktracesave+0xdc/0x190 kasansettrack+0x4e/0x80 _kasanslaballoc+0x4e/0x60 kmemcachealloc+0x19f/0x360 skbclone+0x132/0xf70 btusbrecvaclmtk+0x104/0x1a0 [btusb] btusbrxwork+0x9e/0xe0 [btusb] workerthread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 retfromfork+0x51/0x80 retfromfork_asm+0x1b/0x30

Freed by task 1733: stacktracesave+0xdc/0x190 kasansettrack+0x4e/0x80 kasansavefreeinfo+0x28/0xb0 __kasanslabfree+0xfd/0x170 kmemcachefree+0x183/0x3f0 hcidevcdrx+0x91a/0x2060 [bluetooth] workerthread+0xe44/0x2cc0 kthread+0x2ff/0x3a0 retfromfork+0x51/0x80 retfromfork_asm+0x1b/0x30

The buggy address belongs to the object at ffff888033cfab40 which belongs to the cache skbuffheadcache of size 232 The buggy address is located 112 bytes inside of freed 232-byte region [ffff888033cfab40, ffff888033cfac28)

The buggy address belongs to the physical page: page:00000000a174ba93 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x33cfa head:00000000a174ba93 order:1 entiremapcount:0 nrpagesmapped:0 pincount:0 anon flags: 0x4000000000000840(slab|head|zone=1) pagetype: 0xffffffff() raw: 4000000000000840 ffff888100848a00 0000000000000000 0000000000000001 raw: 0000000000000000 0000000080190019 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected

Memory state around the buggy address: ffff888033cfaa80: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc ffff888033cfab00: fc fc fc fc fc fc fc fc fa fb fb fb fb fb fb fb >ffff888033cfab80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb ^ ffff888033cfac00: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc

ffff888033cfac80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

Check if we need to call hcidevcdcomplete before calling hcidevcdappend. That requires that we check data->cdinfo.cnt >= MTKCOREDUMPNUM instead of data->cdinfo.cnt > MTKCOREDUMPNUM, as we increment data->cdinfo.cnt only once the call to hcidevcd_append succeeds.(CVE-2024-56653)

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

powerpc/fadump: Move fadumpcmainit to setuparch() after initmeminit()

During early init CMAMINALIGNMENTBYTES can be PAGESIZE, since pageblockorder is still zero and it gets initialized later during initmeminit() e.g. setuparch() -> initmeminit() -> sparseinit() -> setpageblock_order()

One such use case where this causes issue is - earlysetup() -> earlyinitdevtree() -> fadumpreservemem() -> fadumpcma_init()

This causes CMA memory alignment check to be bypassed in cmainitreservedmem(). Then later cmaactivatearea() can hit a VMBUGONPAGE(pfn & ((1 << order) - 1)) if the reserved memory area was not pageblock_order aligned.

Fix it by moving the fadumpcmainit() after initmem_init(), where other such cma reservations also gets called.

<stack trace>

page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010 flags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA raw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: VMBUGONPAGE(pfn & ((1 << order) - 1)) ------------[ cut here ]------------ kernel BUG at mm/pagealloc.c:778!

Call Trace: _freeonepage+0x57c/0x7b0 (unreliable) freepcppagesbulk+0x1a8/0x2c8 freeunrefpagecommit+0x3d4/0x4e4 freeunrefpage+0x458/0x6d0 initcmareservedpageblock+0x114/0x198 cmainitreservedareas+0x270/0x3e0 dooneinitcall+0x80/0x2f8 kernelinitfreeable+0x33c/0x530 kernelinit+0x34/0x26c retfromkerneluser_thread+0x14/0x1c(CVE-2024-56677)

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

usb: musb: Fix hardware lockup on first Rx endpoint request

There is a possibility that a request's callback could be invoked from usbepqueue() (call trace below, supplemented with missing calls):

req->complete from usbgadgetgivebackrequest (drivers/usb/gadget/udc/core.c:999) usbgadgetgivebackrequest from musbggiveback (drivers/usb/musb/musbgadget.c:147) musbggiveback from rxstate (drivers/usb/musb/musbgadget.c:784) rxstate from musbeprestart (drivers/usb/musb/musbgadget.c:1169) musbeprestart from musbeprestartresumework (drivers/usb/musb/musbgadget.c:1176) musbeprestartresumework from musbqueueresumework (drivers/usb/musb/musbcore.c:2279) musbqueueresumework from musbgadgetqueue (drivers/usb/musb/musbgadget.c:1241) musbgadgetqueue from usbepqueue (drivers/usb/gadget/udc/core.c:300)

According to the docstring of usbepqueue(), this should not happen:

"Note that @req's ->complete() callback must never be called from within usbepqueue() as that can create deadlock situations."

In fact, a hardware lockup might occur in the following sequence:

1. The gadget is initialized using musbgadgetenable().
2. Meanwhile, a packet arrives, and the RXPKTRDY flag is set, raising an interrupt.
3. If IRQs are enabled, the interrupt is handled, but musbgrx() finds an empty queue (next_request() returns NULL). The interrupt flag has already been cleared by the glue layer handler, but the RXPKTRDY flag remains set.
4. The first request is enqueued using usbepqueue(), leading to the call of req->complete(), as shown in the call trace above.
5. If the callback enables IRQs and another packet is waiting, step (3) repeats. The request queue is empty because usbggiveback() removes the request before invoking the callback.
6. The endpoint remains locked up, as the interrupt triggered by hardware setting the RXPKTRDY flag has been handled, but the flag itself remains set.

For this scenario to occur, it is only necessary for IRQs to be enabled at some point during the complete callback. This happens with the USB Ethernet gadget, whose rxcomplete() callback calls netifrx(). If called in the task context, netifrx() disables the bottom halves (BHs). When the BHs are re-enabled, IRQs are also enabled to allow soft IRQs to be processed. The gadget itself is initialized at module load (or at boot if built-in), but the first request is enqueued when the network interface is brought up, triggering rxcomplete() in the task context via ioctl(). If a packet arrives while the interface is down, it can prevent the interface from receiving any further packets from the USB host.

The situation is quite complicated with many parties involved. This particular issue can be resolved in several possible ways:

1. Ensure that callbacks never enable IRQs. This would be difficult to enforce, as discovering how netifrx() interacts with interrupts was already quite challenging and uether is not the only function driver. Similar "bugs" could be hidden in other drivers as well.
2. Disable MUSB interrupts in musbggiveback() before calling the callback and re-enable them afterwars (by calling musb{dis,en}ableinterrupts(), for example). This would ensure that MUSB interrupts are not handled during the callback, even if IRQs are enabled. In fact, it would allow IRQs to be enabled when releasing the lock. However, this feels like an inelegant hack.
3. Modify the interrupt handler to clear the RXPKTRDY flag if the request queue is empty. While this approach also feels like a hack, it wastes CPU time by attempting to handle incoming packets when the software is not ready to process them.
4. Flush the Rx FIFO instead of calling rxstate() in musbeprestart(). This ensures that the hardware can receive packets when there is at least one request in the queue. Once I ---truncated---(CVE-2024-56687)

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

sunrpc: clear XPRTSOCKUPD_TIMEOUT when reset transport

Since transport->sock has been set to NULL during reset transport, XPRTSOCKUPDTIMEOUT also needs to be cleared. Otherwise, the xstcpsetsockettimeouts() may be triggered in xstcpsendrequest() to dereference the transport->sock that has been set to NULL.(CVE-2024-56688)

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

powerpc/pseries: Fix dtlaccesslock to be a rw_semaphore

The dtlaccesslock needs to be a rw_sempahore, a sleeping lock, because the code calls kmalloc() while holding it, which can sleep:

# echo 1 > /proc/powerpc/vcpudispatchstats BUG: sleeping function called from invalid context at include/linux/sched/mm.h:337 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 199, name: sh preemptcount: 1, expected: 0 3 locks held by sh/199: #0: c00000000a0743f8 (sbwriters#3){.+.+}-{0:0}, at: vfswrite+0x324/0x438 #1: c0000000028c7058 (dtlenablemutex){+.+.}-{3:3}, at: vcpudispatchstatswrite+0xd4/0x5f4 #2: c0000000028c70b8 (dtlaccesslock){+.+.}-{2:2}, at: vcpudispatchstatswrite+0x220/0x5f4 CPU: 0 PID: 199 Comm: sh Not tainted 6.10.0-rc4 #152 Hardware name: IBM pSeries (emulated by qemu) POWER9 (raw) 0x4e1202 0xf000005 of:SLOF,HEAD hv:linux,kvm pSeries Call Trace: dumpstacklvl+0x130/0x148 (unreliable) _mightresched+0x174/0x410 kmemcacheallocnoprof+0x340/0x3d0 allocdtlbuffers+0x124/0x1ac vcpudispatchstatswrite+0x2a8/0x5f4 procregwrite+0xf4/0x150 vfswrite+0xfc/0x438 ksyswrite+0x88/0x148 systemcallexception+0x1c4/0x5a0 systemcallcommon+0xf4/0x258(CVE-2024-56701)

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

net/smc: protect link down work from execute after lgr freed

link down work may be scheduled before lgr freed but execute after lgr freed, which may result in crash. So it is need to hold a reference before shedule link down work, and put the reference after work executed or canceled.

The relevant crash call stack as follows: listdel corruption. prev->next should be ffffb638c9c0fe20, but was 0000000000000000 ------------[ cut here ]------------ kernel BUG at lib/listdebug.c:51! invalid opcode: 0000 [#1] SMP NOPTI CPU: 6 PID: 978112 Comm: kworker/6:119 Kdump: loaded Tainted: G #1 Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 2221b89 04/01/2014 Workqueue: events smclinkdownwork [smc] RIP: 0010:listdelentryvalid.cold+0x31/0x47 RSP: 0018:ffffb638c9c0fdd8 EFLAGS: 00010086 RAX: 0000000000000054 RBX: ffff942fb75e5128 RCX: 0000000000000000 RDX: ffff943520930aa0 RSI: ffff94352091fc80 RDI: ffff94352091fc80 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffb638c9c0fc38 R10: ffffb638c9c0fc30 R11: ffffffffa015eb28 R12: 0000000000000002 R13: ffffb638c9c0fe20 R14: 0000000000000001 R15: ffff942f9cd051c0 FS: 0000000000000000(0000) GS:ffff943520900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4f25214000 CR3: 000000025fbae004 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: rwsemdownwriteslowpath+0x17e/0x470 smclinkdownwork+0x3c/0x60 [smc] processonework+0x1ac/0x350 workerthread+0x49/0x2f0 ? rescuerthread+0x360/0x360 kthread+0x118/0x140 ? _kthreadbindmask+0x60/0x60 retfrom_fork+0x1f/0x30(CVE-2024-56718)

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

smb: Initialize cfid->tcon before performing network ops

Avoid leaking a tcon ref when a lease break races with opening the cached directory. Processing the leak break might take a reference to the tcon in cacheddirleasebreak() and then fail to release the ref in cacheddiroffloadclose, since cfid->tcon is still NULL.(CVE-2024-56729)

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

btrfs: check folio mapping after unlock in relocateonefolio()

When we call btrfsreadfolio() to bring a folio uptodate, we unlock the folio. The result of that is that a different thread can modify the mapping (like remove it with invalidate) before we call folio_lock(). This results in an invalid page and we need to try again.

In particular, if we are relocating concurrently with aborting a transaction, this can result in a crash like the following:

BUG: kernel NULL pointer dereference, address: 0000000000000000 PGD 0 P4D 0 Oops: 0000 [#1] SMP CPU: 76 PID: 1411631 Comm: kworker/u322:5 Workqueue: eventsunbound btrfsreclaimbgswork RIP: 0010:setpageextentmapped+0x20/0xb0 RSP: 0018:ffffc900516a7be8 EFLAGS: 00010246 RAX: ffffea009e851d08 RBX: ffffea009e0b1880 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffc900516a7b90 RDI: ffffea009e0b1880 RBP: 0000000003573000 R08: 0000000000000001 R09: ffff88c07fd2f3f0 R10: 0000000000000000 R11: 0000194754b575be R12: 0000000003572000 R13: 0000000003572fff R14: 0000000000100cca R15: 0000000005582fff FS: 0000000000000000(0000) GS:ffff88c07fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000407d00f002 CR4: 00000000007706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? _die+0x78/0xc0 ? pagefaultoops+0x2a8/0x3a0 ? _switchto+0x133/0x530 ? wqworkerrunning+0xa/0x40 ? excpagefault+0x63/0x130 ? asmexcpagefault+0x22/0x30 ? setpageextentmapped+0x20/0xb0 relocatefileextentcluster+0x1a7/0x940 relocatedataextent+0xaf/0x120 relocateblockgroup+0x20f/0x480 btrfsrelocateblockgroup+0x152/0x320 btrfsrelocatechunk+0x3d/0x120 btrfsreclaimbgswork+0x2ae/0x4e0 processscheduledworks+0x184/0x370 workerthread+0xc6/0x3e0 ? blkaddtimer+0xb0/0xb0 kthread+0xae/0xe0 ? flushtlbkernelrange+0x90/0x90 retfromfork+0x2f/0x40 ? flushtlbkernelrange+0x90/0x90 retfromfork_asm+0x11/0x20 </TASK>

This occurs because cleanuponetransaction() calls destroydelallocinodes() which calls invalidateinodepages2() which takes the foliolock before setting mapping to NULL. We fail to check this, and subsequently call setextent_mapping(), which assumes that mapping != NULL (in fact it asserts that in debug mode)

Note that the "fixes" patch here is not the one that introduced the race (the very first iteration of this code from 2009) but a more recent change that made this particular crash happen in practice..(CVE-2024-56758)

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

media: dvb-frontends: dib3000mb: fix uninit-value in dib3000writereg

Syzbot reports [1] an uninitialized value issue found by KMSAN in dib3000readreg().

Local u8 rb[2] is used in i2c_transfer() as a read buffer; in case that call fails, the buffer may end up with some undefined values.

Since no elaborate error handling is expected in dib3000writereg(), simply zero out rb buffer to mitigate the problem.

[1] Syzkaller report

dvb-usb: bulk message failed: -22 (6/0)

BUG: KMSAN: uninit-value in dib3000mbattach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dib3000mbattach+0x2d8/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 dibusbdib3000mbfrontendattach+0x155/0x2f0 drivers/media/usb/dvb-usb/dibusb-mb.c:31 dvbusbadapterfrontendinit+0xed/0x9a0 drivers/media/usb/dvb-usb/dvb-usb-dvb.c:290 dvbusbadapterinit drivers/media/usb/dvb-usb/dvb-usb-init.c:90 [inline] dvbusbinit drivers/media/usb/dvb-usb/dvb-usb-init.c:186 [inline] dvbusbdeviceinit+0x25a8/0x3760 drivers/media/usb/dvb-usb/dvb-usb-init.c:310 dibusbprobe+0x46/0x250 drivers/media/usb/dvb-usb/dibusb-mb.c:110 ... Local variable rb created at: dib3000readreg+0x86/0x4e0 drivers/media/dvb-frontends/dib3000mb.c:54 dib3000mb_attach+0x123/0x3c0 drivers/media/dvb-frontends/dib3000mb.c:758 ...(CVE-2024-56769)

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

nfsd: fix nfs4openowner leak when concurrent nfsd4open occur

The action force umount(umount -f) will attempt to kill all rpctask even umount operation may ultimately fail if some files remain open. Consequently, if an action attempts to open a file, it can potentially send two rpctask to nfs server.

               NFS CLIENT

thread1 thread2 open("file") ... nfs4doopen nfs4doopen _nfs4openandgetstate _nfs4procopen nfs4runopentask /* rpctask1 */ rpcruntask rpcwaitforcompletion_task

                                umount -f
                                nfs_umount_begin
                                 rpc_killall_tasks
                                  rpc_signal_task
 rpc_task1 been wakeup
 and return -512

nfs4doopen // while loop ... nfs4runopentask /* rpctask2 */ rpcruntask rpcwaitforcompletion_task

While processing an open request, nfsd will first attempt to find or allocate an nfs4openowner. If it finds an nfs4openowner that is not marked as NFS4OOCONFIRMED, this nfs4openowner will released. Since two rpctask can attempt to open the same file simultaneously from the client to server, and because two instances of nfsd can run concurrently, this situation can lead to lots of memory leak. Additionally, when we echo 0 to /proc/fs/nfsd/threads, warning will be triggered.

                NFS SERVER

nfsd1 nfsd2 echo 0 > /proc/fs/nfsd/threads

nfsd4open nfsd4processopen1 findorallocopenstateowner // alloc oo1, stateid1 nfsd4open nfsd4processopen1 findorallocopenstateowner // find oo1, without NFS4OOCONFIRMED releaseopenowner unhashopenownerlocked listdelinit(&oo->ooperclient) // cannot find this oo // from client, LEAK!!! alloc_stateowner // alloc oo2

nfsd4processopen2 initopenstateid // associate oo1 // with stateid1, stateid1 LEAK!!! nfs4getvfsfile // alloc nfsdfile1 and nfsdfilemark1 // all LEAK!!!

                     nfsd4_process_open2
                     ...

                                write_threads
                                 ...
                                 nfsd_destroy_serv
                                  nfsd_shutdown_net
                                   nfs4_state_shutdown_net
                                    nfs4_state_destroy_net
                                     destroy_client
                                      __destroy_client
                                      // won't find oo1!!!
                                 nfsd_shutdown_generic
                                  nfsd_file_cache_shutdown
                                   kmem_cache_destroy
                                   for nfsd_file_slab
                                   and nfsd_file_mark_slab
                                   // bark since nfsd_file1
                                   // and nfsd_file_mark1
                                   // still alive

======================================================================= BUG nfsdfile (Not tainted): Objects remaining in nfsdfile on

_kmemcache_shutdown()

Slab 0xffd4000004438a80 objects=34 used=1 fp=0xff11000110e2ad28 flags=0x17ffffc0000240(workingset|head|node=0|zone=2|lastcpupid=0x1fffff) CPU: 4 UID: 0 PID: 757 Comm: sh Not tainted 6.12.0-rc6+ #19 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.1-2.fc37 04/01/2014 Call Trace: <TASK> dum ---truncated---(CVE-2024-56779)

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

PCI: imx6: Fix suspend/resume support on i.MX6QDL

The suspend/resume functionality is currently broken on the i.MX6QDL platform, as documented in the NXP errata (ERR005723):

https://www.nxp.com/docs/en/errata/IMX6DQCE.pdf

This patch addresses the issue by sharing most of the suspend/resume sequences used by other i.MX devices, while avoiding modifications to critical registers that disrupt the PCIe functionality. It targets the same problem as the following downstream commit:

https://github.com/nxp-imx/linux-imx/commit/4e92355e1f79d225ea842511fcfd42b343b32995

Unlike the downstream commit, this patch also resets the connected PCIe device if possible. Without this reset, certain drivers, such as ath10k or iwlwifi, will crash on resume. The device reset is also done by the driver on other i.MX platforms, making this patch consistent with existing practices.

Upon resuming, the kernel will hang and display an error. Here's an example of the error encountered with the ath10k driver:

ath10k_pci 0000:01:00.0: Unable to change power state from D3hot to D0, device inaccessible Unhandled fault: imprecise external abort (0x1406) at 0x0106f944

Without this patch, suspend/resume will fail on i.MX6QDL devices if a PCIe device is connected.

kwilczynski: commit log, added tag for stable releases

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

arm64: ptrace: fix partial SETREGSET for NTARMTAGGEDADDRCTRL

Currently taggedaddrctrlset() doesn't initialize the temporary 'ctrl' variable, and a SETREGSET call with a length of zero will leave this uninitialized. Consequently taggedaddrctrlset() will consume an arbitrary value, potentially leaking up to 64 bits of memory from the kernel stack. The read is limited to a specific slot on the stack, and the issue does not provide a write mechanism.

As settaggedaddr_ctrl() only accepts values where bits [63:4] zero and rejects other values, a partial SETREGSET attempt will randomly succeed or fail depending on the value of the uninitialized value, and the exposure is significantly limited.

Fix this by initializing the temporary value before copying the regset from userspace, as for other regsets (e.g. NTPRSTATUS, NTPRFPREG, NTARMSYSTEM_CALL). In the case of a zero-length write, the existing value of the tagged address ctrl will be retained.

The NTARMTAGGEDADDRCTRL regset is only visible in the useraarch64view used by a native AArch64 task to manipulate another native AArch64 task. As gettaggedaddrctrl() only returns an error value when called for a compat task, taggedaddrctrlget() and taggedaddrctrlset() should never observe an error value from gettaggedaddrctrl(). Add a WARNONONCE() to both to indicate that such an error would be unexpected, and error handlnig is not missing in either case.(CVE-2024-57874)

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

ocfs2: fix slab-use-after-free due to dangling pointer dqi_priv

When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quotagetnextquota. Specifically, sbdqinfo(sb, type)->dqi_priv is the dangling pointer.

During the remounting process, the pointer dqipriv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOTSUSPENDED flag instead of setting the DQUOTUSAGEENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2getnext_id is called and only checks the quota usage flags and not the quota suspended flags.

To fix this, I set dqipriv to null when it is freed after remounting with read-only and put a check for DQUOTSUSPENDED in ocfs2getnext_id.

akpm@linux-foundation.org: coding-style cleanups

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

iio: adc: ti-ads8688: fix information leak in triggered buffer

The 'buffer' local array is used to push data to user space from a triggered buffer, but it does not set values for inactive channels, as it only uses iioforeachactivechannel() to assign new values.

Initialize the array to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57906)

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

iio: light: vcnl4035: fix information leak in triggered buffer

The 'buffer' local array is used to push data to userspace from a triggered buffer, but it does not set an initial value for the single data element, which is an u16 aligned to 8 bytes. That leaves at least 4 bytes uninitialized even after writing an integer value with regmap_read().

Initialize the array to zero before using it to avoid pushing uninitialized information to userspace.(CVE-2024-57910)

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

topology: Keep the cpumask unchanged when printing cpumap

During fuzz testing, the following warning was discovered:

different return values (15 and 11) from vsnprintf("%*pbl ", ...)

test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmapprinttobuf+0x89/0x100 coresiblingslistread+0x7e/0xb0 kernfsfilereaditer+0x15b/0x270 newsyncread+0x153/0x260 vfsread+0x215/0x290 ksysread+0xb9/0x160 dosyscall64+0x56/0x100 entrySYSCALL64after_hwframe+0x78/0xe2

The call trace shows that kvasprintf() reported this warning during the printing of coresiblingslist. kvasprintf() has several steps:

(1) First, calculate the length of the resulting formatted string.

(2) Allocate a buffer based on the returned length.

(3) Then, perform the actual string formatting.

(4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.

If the corecpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify corecpumask while printing.

To fix this issue, cache the cpumask into a temporary variable before calling cpumapprint{list, cpumask}tobuf(), to keep it unchanged during the printing process.(CVE-2024-57917)

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

drm/amd/display: Add check for granularity in dml ceil/floor helpers

[Why] Wrapper functions for dcnbwceil2() and dcnbwfloor2() should check for granularity is non zero to avoid assert and divide-by-zero error in dcnbw functions.

[How] Add check for granularity 0.

(cherry picked from commit f6e09701c3eb2ccb8cb0518e0b67f1c69742a4ec)(CVE-2024-57922)

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

drm/mediatek: Set private->alldrmprivate[i]->drm to NULL if mtkdrmbind returns err

The pointer need to be set to NULL, otherwise KASAN complains about use-after-free. Because in mtkdrmbind, all private's drm are set as follows.

private->alldrmprivate[i]->drm = drm;

And drm will be released by drmdevput in case mtkdrmkmsinit returns failure. However, the shutdown path still accesses the previous allocated memory in drmatomichelpershutdown.

[ 84.874820] watchdog: watchdog0: watchdog did not stop! [ 86.512054] ================================================================== [ 86.513162] BUG: KASAN: use-after-free in drmatomichelpershutdown+0x33c/0x378 [ 86.514258] Read of size 8 at addr ffff0000d46fc068 by task shutdown/1 [ 86.515213] [ 86.515455] CPU: 1 UID: 0 PID: 1 Comm: shutdown Not tainted 6.13.0-rc1-mtk+gfa1a78e5d24b-dirty #55 [ 86.516752] Hardware name: Unknown Product/Unknown Product, BIOS 2022.10 10/01/2022 [ 86.517960] Call trace: [ 86.518333] showstack+0x20/0x38 (C) [ 86.518891] dumpstacklvl+0x90/0xd0 [ 86.519443] printreport+0xf8/0x5b0 [ 86.519985] kasanreport+0xb4/0x100 [ 86.520526] _asanreportload8noabort+0x20/0x30 [ 86.521240] drmatomichelpershutdown+0x33c/0x378 [ 86.521966] mtkdrmshutdown+0x54/0x80 [ 86.522546] platformshutdown+0x64/0x90 [ 86.523137] deviceshutdown+0x260/0x5b8 [ 86.523728] kernelrestart+0x78/0xf0 [ 86.524282] _dosysreboot+0x258/0x2f0 [ 86.524871] _arm64sysreboot+0x90/0xd8 [ 86.525473] invokesyscall+0x74/0x268 [ 86.526041] el0svccommon.constprop.0+0xb0/0x240 [ 86.526751] doel0svc+0x4c/0x70 [ 86.527251] el0svc+0x4c/0xc0 [ 86.527719] el0t64synchandler+0x144/0x168 [ 86.528367] el0t64_sync+0x198/0x1a0 [ 86.528920] [ 86.529157] The buggy address belongs to the physical page: [ 86.529972] page: refcount:0 mapcount:0 mapping:0000000000000000 index:0xffff0000d46fd4d0 pfn:0x1146fc [ 86.531319] flags: 0xbfffc0000000000(node=0|zone=2|lastcpupid=0xffff) [ 86.532267] raw: 0bfffc0000000000 0000000000000000 dead000000000122 0000000000000000 [ 86.533390] raw: ffff0000d46fd4d0 0000000000000000 00000000ffffffff 0000000000000000 [ 86.534511] page dumped because: kasan: bad access detected [ 86.535323] [ 86.535559] Memory state around the buggy address: [ 86.536265] ffff0000d46fbf00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.537314] ffff0000d46fbf80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.538363] >ffff0000d46fc000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.544733] ^ [ 86.551057] ffff0000d46fc080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.557510] ffff0000d46fc100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [ 86.563928] ================================================================== [ 86.571093] Disabling lock debugging due to kernel taint [ 86.577642] Unable to handle kernel paging request at virtual address e0e9c0920000000b [ 86.581834] KASAN: maybe wild-memory-access in range [0x0752049000000058-0x075204900000005f] ...(CVE-2024-57926)

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

x86/fpu: Ensure shadow stack is active before "getting" registers

The x86 shadow stack support has its own set of registers. Those registers are XSAVE-managed, but they are "supervisor state components" which means that userspace can not touch them with XSAVE/XRSTOR. It also means that they are not accessible from the existing ptrace ABI for XSAVE state. Thus, there is a new ptrace get/set interface for it.

The regset code that ptrace uses provides an ->active() handler in addition to the get/set ones. For shadow stack this ->active() handler verifies that shadow stack is enabled via the ARCHSHSTKSHSTK bit in the thread struct. The ->active() handler is checked from some call sites of the regset get/set handlers, but not the ptrace ones. This was not understood when shadow stack support was put in place.

As a result, both the set/get handlers can be called with XFEATURECETUSER in its init state, which would cause getxsaveaddr() to return NULL and trigger a WARNON(). The sspset() handler luckily has an sspactive() check to avoid surprising the kernel with shadow stack behavior when the kernel is not ready for it (ARCHSHSTK_SHSTK==0). That check just happened to avoid the warning.

But the ->get() side wasn't so lucky. It can be called with shadow stacks disabled, triggering the warning in practice, as reported by Christina Schimpe:

WARNING: CPU: 5 PID: 1773 at arch/x86/kernel/fpu/regset.c:198 sspget+0x89/0xa0 [...] Call Trace: <TASK> ? showregs+0x6e/0x80 ? sspget+0x89/0xa0 ? _warn+0x91/0x150 ? sspget+0x89/0xa0 ? reportbug+0x19d/0x1b0 ? handlebug+0x46/0x80 ? excinvalidop+0x1d/0x80 ? asmexcinvalidop+0x1f/0x30 ? _pfxsspget+0x10/0x10 ? sspget+0x89/0xa0 ? sspget+0x52/0xa0 _regsetget+0xad/0xf0 copyregsettouser+0x52/0xc0 ptraceregset+0x119/0x140 ptracerequest+0x13c/0x850 ? waittaskinactive+0x142/0x1d0 ? dosyscall64+0x6d/0x90 arch_ptrace+0x102/0x300 [...]

Ensure that shadow stacks are active in a thread before looking them up in the XSAVE buffer. Since ARCHSHSTKSHSTK and userssp[SHSTKEN] are set at the same time, the active check ensures that there will be something to find in the XSAVE buffer.

dhansen: changelog/subject tweaks

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

btrfs: avoid NULL pointer dereference if no valid extent tree

[BUG] Syzbot reported a crash with the following call trace:

BTRFS info (device loop0): scrub: started on devid 1 BUG: kernel NULL pointer dereference, address: 0000000000000208 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 106e70067 P4D 106e70067 PUD 107143067 PMD 0 Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 UID: 0 PID: 689 Comm: repro Kdump: loaded Tainted: G O 6.13.0-rc4-custom+ #206 Tainted: [O]=OOTMODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 02/02/2022 RIP: 0010:findfirstextentitem+0x26/0x1f0 [btrfs] Call Trace: <TASK> scrubfindfillfirststripe+0x13d/0x3b0 [btrfs] scrubsimplemirror+0x175/0x260 [btrfs] scrubstripe+0x5d4/0x6c0 [btrfs] scrubchunk+0xbb/0x170 [btrfs] scrubenumeratechunks+0x2f4/0x5f0 [btrfs] btrfsscrubdev+0x240/0x600 [btrfs] btrfsioctl+0x1dc8/0x2fa0 [btrfs] ? dosysopenat2+0xa5/0xf0 _x64sysioctl+0x97/0xc0 dosyscall64+0x4f/0x120 entrySYSCALL64after_hwframe+0x76/0x7e </TASK>

[CAUSE] The reproducer is using a corrupted image where extent tree root is corrupted, thus forcing to use "rescue=all,ro" mount option to mount the image.

Then it triggered a scrub, but since scrub relies on extent tree to find where the data/metadata extents are, scrubfindfillfirststripe() relies on an non-empty extent root.

But unfortunately scrubfindfillfirststripe() doesn't really expect an NULL pointer for extent root, it use extentroot to grab fsinfo and triggered a NULL pointer dereference.

[FIX] Add an extra check for a valid extent root at the beginning of scrubfindfillfirststripe().

The new error path is introduced by 42437a6386ff ("btrfs: introduce mount option rescue=ignorebadroots"), but that's pretty old, and later commit b979547513ff ("btrfs: scrub: introduce helper to find and fill sector info for a scrub_stripe") changed how we do scrub.

So for kernels older than 6.6, the fix will need manual backport.(CVE-2025-21658)

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

vsock/bpf: return early if transport is not assigned

Some of the core functions can only be called if the transport has been assigned.

As Michal reported, a socket might have the transport at NULL, for example after a failed connect(), causing the following trace:

BUG: kernel NULL pointer dereference, address: 00000000000000a0
#PF: supervisor read access in kernel mode
#PF: error_code(0x0000) - not-present page
PGD 12faf8067 P4D 12faf8067 PUD 113670067 PMD 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 15 UID: 0 PID: 1198 Comm: a.out Not tainted 6.13.0-rc2+
RIP: 0010:vsock_connectible_has_data+0x1f/0x40
Call Trace:
 vsock_bpf_recvmsg+0xca/0x5e0
 sock_recvmsg+0xb9/0xc0
 __sys_recvfrom+0xb3/0x130
 __x64_sys_recvfrom+0x20/0x30
 do_syscall_64+0x93/0x180
 entry_SYSCALL_64_after_hwframe+0x76/0x7e

So we need to check the vsk->transport in vsockbpfrecvmsg(), especially for connected sockets (stream/seqpacket) as we already do in _vsockconnectible_recvmsg().(CVE-2025-21670)