A flaw was found in the Netfilter module in the Linux kernel. The problem is in the nftbyteordereval() function where the code is iterating through a loop and writing to dst[0], dst[1], dst[2] and so on. On each iteration 8 bytes get written, but dst[] is an array of u32 so each element only has space for 4 bytes. That means that every iteration overwrites part of the previous element.

Upstream commit: https://github.com/torvalds/linux/commit/c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63

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

pinctrl: core: delete incorrect free in pinctrlenable()

The "pctldev" struct is allocated in devmpinctrlregisterandinit(). It's a devm managed pointer that is freed by devmpinctrldevrelease(), so freeing it in pinctrlenable() will lead to a double free.

The devmpinctrldevrelease() function frees the pindescs and destroys the mutex as well.

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

nfs: Handle error of rpcprocregister() in nfsnetinit().

syzkaller reported a warning [0] triggered while destroying immature netns.

rpcprocregister() was called in initnfsfs(), but its error has been ignored since at least the initial commit 1da177e4c3f4 ("Linux-2.6.12-rc2").

Recently, commit d47151b79e32 ("nfs: expose /proc/net/sunrpc/nfs in net namespaces") converted the procfs to per-netns and made the problem more visible.

Even when rpcprocregister() fails, nfsnetinit() could succeed, and thus nfsnetexit() will be called while destroying the netns.

Then, removeprocentry() will be called for non-existing proc directory and trigger the warning below.

Let's handle the error of rpcprocregister() properly in nfsnetinit().

[0]: name 'nfs' WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 removeprocentry+0x1bb/0x2d0 fs/proc/generic.c:711 Modules linked in: CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 RIP: 0010:removeprocentry+0x1bb/0x2d0 fs/proc/generic.c:711 Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff <0f> 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8 FS: 00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> rpcprocunregister+0x64/0x70 net/sunrpc/stats.c:310 nfsnetexit+0x1c/0x30 fs/nfs/inode.c:2438 opsexitlist+0x62/0xb0 net/core/netnamespace.c:170 setupnet+0x46c/0x660 net/core/netnamespace.c:372 copynetns+0x244/0x590 net/core/netnamespace.c:505 createnewnamespaces+0x2ed/0x770 kernel/nsproxy.c:110 unsharensproxynamespaces+0xae/0x160 kernel/nsproxy.c:228 ksysunshare+0x342/0x760 kernel/fork.c:3322 dosysunshare kernel/fork.c:3393 [inline] sesysunshare kernel/fork.c:3391 [inline] x64sysunshare+0x1f/0x30 kernel/fork.c:3391 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x4f/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x46/0x4e RIP: 0033:0x7f30d0febe5d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 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 9f 1b 00 f7 d8 64 89 01 48 RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIGRAX: 0000000000000110 RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600 RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000 </TASK>

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

blk-iocost: avoid out of bounds shift

UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures.

[ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0fbk700debugrc2kbuilder0gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F093A23 12/08/2020 Call Trace: <IRQ> dumpstacklvl+0x8f/0xe0 ubsanhandleshiftoutofbounds+0x22c/0x280 iocgkickdelay+0x30b/0x310 ioctimerfn+0x2fb/0x1f80 runtimerbase+0x1b6/0x250 ...

Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large.

I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug.

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

net: core: reject skbcopy(expand) for fraglist GSO skbs

SKBGSOFRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skbcopy or skbcopyexpand, in order to prevent a crash on a potential later call to skbgsosegment.

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

bna: ensure the copied buf is NUL terminated

Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdupusernul instead of memdupuser.

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

tcp: Use refcountincnotzero() in tcptwskunique().

Anderson Nascimento reported a use-after-free splat in tcptwskunique() with nice analysis.

Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inettwskhashdance() sets TIME-WAIT socket's skrefcnt after putting it into ehash and releasing the bucket lock.

Thus, there is a small race window where other threads could try to reuse the port during connect() and call sockhold() in tcptwskunique() for the TIME-WAIT socket with zero refcnt.

If that happens, the refcnt taken by tcptwskunique() is overwritten and sockput() will cause underflow, triggering a real use-after-free somewhere else.

To avoid the use-after-free, we need to use refcountincnotzero() in tcptwskunique() and give up on reusing the port if it returns false.

[0]: refcountt: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcountwarnsaturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x8664 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcountwarnsaturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcountwarnsaturate+0xe5/0x110 ? warn+0x81/0x130 ? refcountwarnsaturate+0xe5/0x110 ? reportbug+0x171/0x1a0 ? refcountwarnsaturate+0xe5/0x110 ? handlebug+0x3c/0x80 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? refcountwarnsaturate+0xe5/0x110 tcptwskunique+0x186/0x190 inetcheckestablished+0x176/0x2d0 inethashconnect+0x74/0x7d0 ? pfxinetcheckestablished+0x10/0x10 tcpv4connect+0x278/0x530 inetstreamconnect+0x10f/0x3d0 inetstreamconnect+0x3a/0x60 sysconnect+0xa8/0xd0 x64sysconnect+0x18/0x20 dosyscall64+0x83/0x170 entrySYSCALL64afterhwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 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 a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>

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

tcp: defer shutdown(SENDSHUTDOWN) for TCPSYNRECV sockets

TCPSYNRECV state is really special, it is only used by cross-syn connections, mostly used by fuzzers.

In the following crash [1], syzbot managed to trigger a divide by zero in tcprcvspaceadjust()

A socket makes the following state transitions, without ever calling tcpinittransfer(), meaning tcpinitbufferspace() is also not called.

TCPCLOSE connect() TCPSYNSENT TCPSYNRECV shutdown() -> tcpshutdown(sk, SENDSHUTDOWN) TCPFINWAIT1

To fix this issue, change tcpshutdown() to not perform a TCPSYNRECV -> TCPFINWAIT1 transition, which makes no sense anyway.

When tcprcvstateprocess() later changes socket state from TCPSYNRECV to TCPESTABLISH, then look at sk->skshutdown to finally enter TCPFINWAIT1 state, and send a FIN packet from a sane socket state.

This means tcpsendfin() can now be called from BH context, and must use GFPATOMIC allocations.

[1] divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:tcprcvspaceadjust+0x2df/0x890 net/ipv4/tcpinput.c:767 Code: e3 04 4c 01 eb 48 8b 44 24 38 0f b6 04 10 84 c0 49 89 d5 0f 85 a5 03 00 00 41 8b 8e c8 09 00 00 89 e8 29 c8 48 0f af c3 31 d2 <48> f7 f1 48 8d 1c 43 49 8d 96 76 08 00 00 48 89 d0 48 c1 e8 03 48 RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246 RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7 R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30 R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da FS: 00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0 Call Trace: tcprecvmsglocked+0x106d/0x25a0 net/ipv4/tcp.c:2513 tcprecvmsg+0x25d/0x920 net/ipv4/tcp.c:2578 inet6recvmsg+0x16a/0x730 net/ipv6/afinet6.c:680 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x109/0x280 net/socket.c:1068 sysrecvmsg+0x1db/0x470 net/socket.c:2803 sysrecvmsg net/socket.c:2845 [inline] dorecvmmsg+0x474/0xae0 net/socket.c:2939 sysrecvmmsg net/socket.c:3018 [inline] dosysrecvmmsg net/socket.c:3041 [inline] sesysrecvmmsg net/socket.c:3034 [inline] x64sysrecvmmsg+0x199/0x250 net/socket.c:3034 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf5/0x240 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7faeb6363db9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 c1 17 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 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIGRAX: 000000000000012b RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9 RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001

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

mlxsw: spectrumacltcam: Fix warning during rehash

As previously explained, the rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.

When the work runs out of credits it stores the current chunk and entry as markers in the per-work context so that it would know where to resume the migration from the next time the work is scheduled.

Upon error, the chunk marker is reset to NULL, but without resetting the entry markers despite being relative to it. This can result in migration being resumed from an entry that does not belong to the chunk being migrated. In turn, this will eventually lead to a chunk being iterated over as if it is an entry. Because of how the two structures happen to be defined, this does not lead to KASAN splats, but to warnings such as [1].

Fix by creating a helper that resets all the markers and call it from all the places the currently only reset the chunk marker. For good measures also call it when starting a completely new rehash. Add a warning to avoid future cases.

[1] WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/coreaclflexkeys.c:407 mlxswafkencode+0x242/0x2f0 Modules linked in: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork RIP: 0010:mlxswafkencode+0x242/0x2f0 [...] Call Trace: mlxswspaclatcamentryadd+0xd9/0x3c0 mlxswspacltcamentrycreate+0x5e/0xa0 mlxswspacltcamvchunkmigrateall+0x109/0x290 mlxswspacltcamvregionrehashwork+0x6c/0x470 processonework+0x151/0x370 workerthread+0x2cb/0x3e0 kthread+0xd0/0x100 retfromfork+0x34/0x50

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

rtnetlink: Correct nested IFLAVFVLANLIST attribute validation

Each attribute inside a nested IFLAVFVLANLIST is assumed to be a struct iflavfvlaninfo so the size of such attribute needs to be at least of sizeof(struct iflavfvlaninfo) which is 14 bytes. The current size validation in dosetvfinfo is against NLAHDRLEN (4 bytes) which is less than sizeof(struct iflavfvlaninfo) so this validation is not enough and a too small attribute might be cast to a struct iflavfvlaninfo, this might result in an out of bands read access when accessing the saved (casted) entry in ivvl.

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

i40e: fix vf may be used uninitialized in this function warning

The Linux kernel CVE team has assigned CVE-2024-36020 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024053044-CVE-2024-36020-5da7@gregkh/T

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

mlxsw: spectrumacltcam: Fix incorrect list API usage

Both the function that migrates all the chunks within a region and the function that migrates all the entries within a chunk call listfirstentry() on the respective lists without checking that the lists are not empty. This is incorrect usage of the API, which leads to the following warning [1].

Fix by returning if the lists are empty as there is nothing to migrate in this case.

[1] WARNING: CPU: 0 PID: 6437 at drivers/net/ethernet/mellanox/mlxsw/spectrumacltcam.c:1266 mlxswspacltcamvchunkmigrateall+0x1f1/0> Modules linked in: CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork RIP: 0010:mlxswspacltcamvchunkmigrateall+0x1f1/0x2c0 [...] Call Trace: <TASK> mlxswspacltcamvregionrehashwork+0x6c/0x4a0 processonework+0x151/0x370 workerthread+0x2cb/0x3e0 kthread+0xd0/0x100 retfromfork+0x34/0x50 retfromforkasm+0x1a/0x30 </TASK>

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

netfilter: nftables: honor table dormant flag from netdev release event path

Check for table dormant flag otherwise netdev release event path tries to unregister an already unregistered hook.

[524854.857999] ------------[ cut here ]------------ [524854.858010] WARNING: CPU: 0 PID: 3386599 at net/netfilter/core.c:501 nfunregisternethook+0x21a/0x260 [...] [524854.858848] CPU: 0 PID: 3386599 Comm: kworker/u32:2 Not tainted 6.9.0-rc3+ #365 [524854.858869] Workqueue: netns cleanupnet [524854.858886] RIP: 0010:nfunregisternethook+0x21a/0x260 [524854.858903] Code: 24 e8 aa 73 83 ff 48 63 43 1c 83 f8 01 0f 85 3d ff ff ff e8 98 d1 f0 ff 48 8b 3c 24 e8 8f 73 83 ff 48 63 43 1c e9 26 ff ff ff <0f> 0b 48 83 c4 18 48 c7 c7 00 68 e9 82 5b 5d 41 5c 41 5d 41 5e 41 [524854.858914] RSP: 0018:ffff8881e36d79e0 EFLAGS: 00010246 [524854.858926] RAX: 0000000000000000 RBX: ffff8881339ae790 RCX: ffffffff81ba524a [524854.858936] RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881c8a16438 [524854.858945] RBP: ffff8881c8a16438 R08: 0000000000000001 R09: ffffed103c6daf34 [524854.858954] R10: ffff8881e36d79a7 R11: 0000000000000000 R12: 0000000000000005 [524854.858962] R13: ffff8881c8a16000 R14: 0000000000000000 R15: ffff8881351b5a00 [524854.858971] FS: 0000000000000000(0000) GS:ffff888390800000(0000) knlGS:0000000000000000 [524854.858982] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [524854.858991] CR2: 00007fc9be0f16f4 CR3: 00000001437cc004 CR4: 00000000001706f0 [524854.859000] Call Trace: [524854.859006] <TASK> [524854.859013] ? warn+0x9f/0x1a0 [524854.859027] ? nfunregisternethook+0x21a/0x260 [524854.859044] ? reportbug+0x1b1/0x1e0 [524854.859060] ? handlebug+0x3c/0x70 [524854.859071] ? excinvalidop+0x17/0x40 [524854.859083] ? asmexcinvalidop+0x1a/0x20 [524854.859100] ? nfunregisternethook+0x6a/0x260 [524854.859116] ? nfunregisternethook+0x21a/0x260 [524854.859135] nftablesnetdevevent+0x337/0x390 [nftables] [524854.859304] ? pfxnftablesnetdevevent+0x10/0x10 [nftables] [524854.859461] ? packetnotifier+0xb3/0x360 [524854.859476] ? rawspinunlockirqrestore+0x11/0x40 [524854.859489] ? dcbnlnetdeviceevent+0x35/0x140 [524854.859507] ? pfxnftablesnetdevevent+0x10/0x10 [nftables] [524854.859661] notifiercallchain+0x7d/0x140 [524854.859677] unregisternetdevicemanynotify+0x5e1/0xae0

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

i40e: Do not use WQMEMRECLAIM flag for workqueue

Issue reported by customer during SRIOV testing, call trace: When both i40e and the i40iw driver are loaded, a warning in checkflushdependency is being triggered. This seems to be because of the i40e driver workqueue is allocated with the WQMEMRECLAIM flag, and the i40iw one is not.

Similar error was encountered on ice too and it was fixed by removing the flag. Do the same for i40e too.

[Feb 9 09:08] ------------[ cut here ]------------ [ +0.000004] workqueue: WQMEMRECLAIM i40e:i40eservicetask [i40e] is flushing !WQMEMRECLAIM infiniband:0x0 [ +0.000060] WARNING: CPU: 0 PID: 937 at kernel/workqueue.c:2966 checkflushdependency+0x10b/0x120 [ +0.000007] Modules linked in: sndseqdummy sndhrtimer sndseq sndtimer sndseqdevice snd soundcore nlsutf8 cifs cifsarc4 nlsucs2utils rdmacm iwcm ibcm cifsmd4 dnsresolver netfs qrtr rfkill sunrpc vfat fat intelraplmsr intelraplcommon irdma inteluncorefrequency inteluncorefrequencycommon ice ipmissif isstifcommon skxedac nfit libnvdimm x86pkgtempthermal intelpowerclamp gnss coretemp ibuverbs rapl intelcstate ibcore iTCOwdt iTCOvendorsupport acpiipmi meime ipmisi inteluncore ioatdma i2ci801 joydev pcspkr mei ipmidevintf lpcich intelpchthermal i2csmbus ipmimsghandler acpipowermeter acpipad xfs libcrc32c ast sdmod drmshmemhelper t10pi drmkmshelper sg ixgbe drm i40e ahci crct10difpclmul libahci crc32pclmul igb crc32cintel libata ghashclmulniintel i2calgobit mdio dca wmi dmmirror dmregionhash dmlog dmmod fuse [ +0.000050] CPU: 0 PID: 937 Comm: kworker/0:3 Kdump: loaded Not tainted 6.8.0-rc2-Feb-netdev-Qiueue-00279-gbd43c5687e05 #1 [ +0.000003] Hardware name: Intel Corporation S2600BPB/S2600BPB, BIOS SE5C620.86B.02.01.0013.121520200651 12/15/2020 [ +0.000001] Workqueue: i40e i40eservicetask [i40e] [ +0.000024] RIP: 0010:checkflushdependency+0x10b/0x120 [ +0.000003] Code: ff 49 8b 54 24 18 48 8d 8b b0 00 00 00 49 89 e8 48 81 c6 b0 00 00 00 48 c7 c7 b0 97 fa 9f c6 05 8a cc 1f 02 01 e8 35 b3 fd ff <0f> 0b e9 10 ff ff ff 80 3d 78 cc 1f 02 00 75 94 e9 46 ff ff ff 90 [ +0.000002] RSP: 0018:ffffbd294976bcf8 EFLAGS: 00010282 [ +0.000002] RAX: 0000000000000000 RBX: ffff94d4c483c000 RCX: 0000000000000027 [ +0.000001] RDX: ffff94d47f620bc8 RSI: 0000000000000001 RDI: ffff94d47f620bc0 [ +0.000001] RBP: 0000000000000000 R08: 0000000000000000 R09: 00000000ffff7fff [ +0.000001] R10: ffffbd294976bb98 R11: ffffffffa0be65e8 R12: ffff94c5451ea180 [ +0.000001] R13: ffff94c5ab5e8000 R14: ffff94c5c20b6e05 R15: ffff94c5f1330ab0 [ +0.000001] FS: 0000000000000000(0000) GS:ffff94d47f600000(0000) knlGS:0000000000000000 [ +0.000002] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ +0.000001] CR2: 00007f9e6f1fca70 CR3: 0000000038e20004 CR4: 00000000007706f0 [ +0.000000] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ +0.000001] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ +0.000001] PKRU: 55555554 [ +0.000001] Call Trace: [ +0.000001] [ +0.000002] ? warn+0x80/0x130 [ +0.000003] ? checkflushdependency+0x10b/0x120 [ +0.000002] ? reportbug+0x195/0x1a0 [ +0.000005] ? handlebug+0x3c/0x70 [ +0.000003] ? excinvalidop+0x14/0x70 [ +0.000002] ? asmexcinvalidop+0x16/0x20 [ +0.000006] ? checkflushdependency+0x10b/0x120 [ +0.000002] ? checkflushdependency+0x10b/0x120 [ +0.000002] flushworkqueue+0x126/0x3f0 [ +0.000015] ibcachecleanupone+0x1c/0xe0 [ibcore] [ +0.000056] ibunregisterdevice+0x6a/0xb0 [ibcore] [ +0.000023] ibunregisterdeviceandput+0x34/0x50 [ibcore] [ +0.000020] i40iwclose+0x4b/0x90 [irdma] [ +0.000022] i40enotifyclientofnetdevclose+0x54/0xc0 [i40e] [ +0.000035] i40eservicetask+0x126/0x190 [i40e] [ +0.000024] processonework+0x174/0x340 [ +0.000003] workerth ---truncated---

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

cpu: Re-enable CPU mitigations by default for !X86 architectures

Rename x86's to CPUMITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATIONMITIGATIONS=n kinda sorta missed that "cpumitigations" is completely generic, whereas SPECULATIONMITIGATIONS is x86-specific.

Rename x86's SPECULATIVEMITIGATIONS instead of keeping both and have it select CPUMITIGATIONS, as having two configs for the same thing is unnecessary and confusing. This will also allow x86 to use the knob to manage mitigations that aren't strictly related to speculative execution.

Use another Kconfig to communicate to common code that CPUMITIGATIONS is already defined instead of having x86's menu depend on the common CPUMITIGATIONS. This allows keeping a single point of contact for all of x86's mitigations, and it's not clear that other architectures want to allow disabling mitigations at compile-time.

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

riscv: Fix TASKSIZE on 64-bit NOMMU

On NOMMU, userspace memory can come from anywhere in physical RAM. The current definition of TASKSIZE is wrong if any RAM exists above 4G, causing spurious failures in the userspace access routines.

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

geneve: fix header validation in geneve[6]xmitskb

syzbot is able to trigger an uninit-value in genevexmit() [1]

Problem : While most ip tunnel helpers (like iptunnelgetdsfield()) uses skbprotocol(skb, true), pskbinetmaypull() is only using skb->protocol.

If anything else than ETHPIPV6 or ETHPIP is found in skb->protocol, pskbinetmaypull() does nothing at all.

If a vlan tag was provided by the caller (afpacket in the syzbot case), the network header might not point to the correct location, and skb linear part could be smaller than expected.

Add skbvlaninetprepare() to perform a complete mac validation.

Use this in geneve for the moment, I suspect we need to adopt this more broadly.

v4 - Jakub reported v3 broke l2tosttlinherit.sh selftest - Only call vlangetprotocol() for vlan types.

v2,v3 - Addressed Sabrina comments on v1 and v2

[1]

BUG: KMSAN: uninit-value in genevexmitskb drivers/net/geneve.c:910 [inline] BUG: KMSAN: uninit-value in genevexmit+0x302d/0x5420 drivers/net/geneve.c:1030 genevexmitskb drivers/net/geneve.c:910 [inline] genevexmit+0x302d/0x5420 drivers/net/geneve.c:1030 netdevstartxmit include/linux/netdevice.h:4903 [inline] netdevstartxmit include/linux/netdevice.h:4917 [inline] xmitone net/core/dev.c:3531 [inline] devhardstartxmit+0x247/0xa20 net/core/dev.c:3547 devqueuexmit+0x348d/0x52c0 net/core/dev.c:4335 devqueuexmit include/linux/netdevice.h:3091 [inline] packetxmit+0x9c/0x6c0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3081 [inline] packetsendmsg+0x8bb0/0x9ef0 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x30f/0x380 net/socket.c:745 syssendto+0x685/0x830 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x125/0x1d0 net/socket.c:2199 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x613/0xc50 mm/slub.c:3888 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:577 allocskb+0x35b/0x7a0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1318 [inline] allocskbwithfrags+0xc8/0xbf0 net/core/skbuff.c:6504 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2795 packetallocskb net/packet/afpacket.c:2930 [inline] packetsnd net/packet/afpacket.c:3024 [inline] packetsendmsg+0x722d/0x9ef0 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x30f/0x380 net/socket.c:745 syssendto+0x685/0x830 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x125/0x1d0 net/socket.c:2199 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024

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

Bluetooth: SCO: Fix not validating setsockopt user input

syzbot reported scosocksetsockopt() is copying data without checking user input length.

BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in scosocksetsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578

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

ipv6: fix race condition between ipv6getifaddr and ipv6deladdr

Although ipv6getifaddr walks inet6addrlst under the RCU lock, it still means hlistforeachentryrcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane.

In particular, the reference count can be zero. This can happen if ipv6deladdr is called in parallel. ipv6deladdr removes the entry from inet6addrlst (hlistdelinitrcu(&ifp->addrlst)) and drops all references (in6ifaput(ifp) + in6ifaput(ifp)). With bad enough timing, this can happen:

1. In ipv6getifaddr, hlistforeachentryrcu returns an entry.

2. Then, the whole ipv6deladdr is executed for the given entry. The reference count drops to zero and kfreercu is scheduled.

3. ipv6getifaddr continues and tries to increments the reference count (in6ifahold).

4. The rcu is unlocked and the entry is freed.

5. The freed entry is returned.

Prevent increasing of the reference count in such case. The name in6ifaholdsafe is chosen to mimic the existing fib6infoholdsafe.

[ 41.506330] refcountt: addition on 0; use-after-free. [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcountwarnsaturate+0xa5/0x130 [ 41.507413] Modules linked in: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcountwarnsaturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.516799] Call Trace: [ 41.517037] <TASK> [ 41.517249] ? warn+0x7b/0x120 [ 41.517535] ? refcountwarnsaturate+0xa5/0x130 [ 41.517923] ? reportbug+0x164/0x190 [ 41.518240] ? handlebug+0x3d/0x70 [ 41.518541] ? excinvalidop+0x17/0x70 [ 41.520972] ? asmexcinvalidop+0x1a/0x20 [ 41.521325] ? refcountwarnsaturate+0xa5/0x130 [ 41.521708] ipv6getifaddr+0xda/0xe0 [ 41.522035] inet6rtmgetaddr+0x342/0x3f0 [ 41.522376] ? pfxinet6rtmgetaddr+0x10/0x10 [ 41.522758] rtnetlinkrcvmsg+0x334/0x3d0 [ 41.523102] ? netlinkunicast+0x30f/0x390 [ 41.523445] ? pfxrtnetlinkrcvmsg+0x10/0x10 [ 41.523832] netlinkrcvskb+0x53/0x100 [ 41.524157] netlinkunicast+0x23b/0x390 [ 41.524484] netlinksendmsg+0x1f2/0x440 [ 41.524826] syssendto+0x1d8/0x1f0 [ 41.525145] x64syssendto+0x1f/0x30 [ 41.525467] dosyscall64+0xa5/0x1b0 [ 41.525794] entrySYSCALL64afterhwframe+0x72/0x7a [ 41.526213] RIP: 0033:0x7fbc4cfcea9a [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] RSP: 002b:00007f ---truncated---

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

netfilter: complete validation of user input

In my recent commit, I missed that doreplace() handlers use copyfromsockptr() (which I fixed), followed by unsafe copyfromsockptroffset() calls.

In all functions, we can perform the @optlen validation before even calling xtalloctableinfo() with the following check:

if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL;

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

kprobes: Fix possible use-after-free issue on kprobe registration

When unloading a module, its state is changing MODULESTATELIVE -> MODULESTATEGOING -> MODULESTATEUNFORMED. Each change will take a time. ismoduletextaddress() and moduletextaddress() works with MODULESTATELIVE and MODULESTATEGOING. If we use ismoduletextaddress() and moduletextaddress() separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULESTATEUNFORMED between those operations.

In checkkprobeaddresssafe(), if the second moduletextaddress() is failed, that is ignored because it expected a kerneltext address. But it may have failed simply because module->state has been changed to MODULESTATEUNFORMED. In this case, armkprobe() will try to modify non-exist module text address (use-after-free).

To fix this problem, we should not use separated ismoduletextaddress() and moduletextaddress(), but use only moduletextaddress() once and do trymoduleget(module) which is only available with MODULESTATELIVE.

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

net/mlx5: Properly link new fs rules into the tree

Previously, addrulefg would only add newly created rules from the handle into the tree when they had a refcount of 1. On the other hand, createflowhandle tries hard to find and reference already existing identical rules instead of creating new ones.

These two behaviors can result in a situation where createflowhandle 1) creates a new rule and references it, then 2) in a subsequent step during the same handle creation references it again, resulting in a rule with a refcount of 2 that is not linked into the tree, will have a NULL parent and root and will result in a crash when the flow group is deleted because delswhwrule, invoked on rule deletion, assumes node->parent is != NULL.

This happened in the wild, due to another bug related to incorrect handling of duplicate pktreformat ids, which lead to the code in createflowhandle incorrectly referencing a just-added rule in the same flow handle, resulting in the problem described above. Full details are at [1].

This patch changes addrulefg to add new rules without parents into the tree, properly initializing them and avoiding the crash. This makes it more consistent with how rules are added to an FTE in createflowhandle.

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

net: ena: Fix incorrect descriptor free behavior

ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDPREDIRECT or XDPTX instructions

The enafreetxbufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napiconsumeskb() for descriptors belonging to an XDP specific queue.

This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.

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

btrfs: send: handle path ref underflow in header iterateinoderef()

Change BUGON to proper error handling if building the path buffer fails. The pointers are not printed so we don't accidentally leak kernel addresses.

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

VMCI: Fix memcpy() run-time warning in dgdispatchashost()

Syzkaller hit 'WARNING in dgdispatchashost' bug.

memcpy: detected field-spanning write (size 56) of single field "&dginfo->msg" at drivers/misc/vmwvmci/vmcidatagram.c:237 (size 24)

WARNING: CPU: 0 PID: 1555 at drivers/misc/vmwvmci/vmcidatagram.c:237 dgdispatchashost+0x88e/0xa60 drivers/misc/vmwvmci/vmcidatagram.c:237

Some code commentry, based on my understanding:

544 #define VMCIDGSIZE(dg) (VMCIDGHEADERSIZE + (sizet)(dg)->payloadsize) /// This is 24 + payloadsize

memcpy(&dginfo->msg, dg, dgsize); Destination = dginfo->msg ---> this is a 24 byte structure(struct vmcidatagram) Source = dg --> this is a 24 byte structure (struct vmcidatagram) Size = dgsize = 24 + payloadsize

{payloadsize = 56-24 =32} -- Syzkaller managed to set payloadsize to 32.

35 struct delayeddatagraminfo { 36 struct datagramentry entry; 37 struct workstruct work; 38 bool indghostqueue; 39 / msg and msgpayload must be together. / 40 struct vmcidatagram msg; 41 u8 msgpayload[]; 42 };

So those extra bytes of payload are copied into msgpayload[], a run time warning is seen while fuzzing with Syzkaller.

One possible way to fix the warning is to split the memcpy() into two parts -- one -- direct assignment of msg and second taking care of payload.

Gustavo quoted: "Under FORTIFYSOURCE we should not copy data across multiple members in a structure."

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

pstore/zone: Add a null pointer check to the pszkmsgread

kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity.

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

btrfs: handle chunk tree lookup error in btrfsrelocatesyschunks()

The unhandled case in btrfsrelocatesyschunks() loop is a corruption, as it could be caused only by two impossible conditions:

- at first the search key is set up to look for a chunk tree item, with offset -1, this is an inexact search and the key->offset will contain the correct offset upon a successful search, a valid chunk tree item cannot have an offset -1

- after first successful search, the foundkey corresponds to a chunk item, the offset is decremented by 1 before the next loop, it's impossible to find a chunk item there due to alignment and size constraints

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

drm/client: Fully protect modes[] with dev->modeconfig.mutex

The Linux kernel CVE team has assigned CVE-2024-35950 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052015-CVE-2024-35950-41bf@gregkh/T

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

block: prevent division by zero in blkrqstatsum()

The expression dst->nrsamples + src->nrsamples may have zero value on overflow. It is necessary to add a check to avoid division by zero.

Found by Linux Verification Center (linuxtesting.org) with Svace.

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

scsi: lpfc: Fix possible memory leak in lpfcrcvpadisc()

The call to lpfcsli4resumerpi() in lpfcrcvpadisc() may return an unsuccessful status. In such cases, the elsiocb is not issued, the completion is not called, and thus the elsiocb resource is leaked.

Check return value after calling lpfcsli4resumerpi() and conditionally release the elsiocb resource.