By monitoring the time certain operations take, an attacker could have guessed which external protocol handlers were functional on a user's system.

Last updated 24 July 2024

Cupsd Listen arbitrary chmod 0140777

Last updated 4 February 2025

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:

clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change

While PLL CPUX clock rate change when CPU is running from it works in vast majority of cases, now and then it causes instability. This leads to system crashes and other undefined behaviour. After a lot of testing (30+ hours) while also doing a lot of frequency switches, we can't observe any instability issues anymore when doing reparenting to stable clock like 24 MHz oscillator.

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

mptcp: ensure sndnxt is properly initialized on connect

Christoph reported a splat hinting at a corrupted snduna:

WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 mptcpcleanuna+0x4b3/0x620 net/mptcp/protocol.c:1005 Modules linked in: CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014 Workqueue: events mptcpworker RIP: 0010:mptcpcleanuna+0x4b3/0x620 net/mptcp/protocol.c:1005 Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8 8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe <0f> 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9 RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293 RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4 RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001 RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000 R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000 FS: 0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0 Call Trace: <TASK> mptcpcleanunawakeup net/mptcp/protocol.c:1055 [inline] mptcpcleanunawakeup net/mptcp/protocol.c:1062 [inline] mptcpretrans+0x7f/0x7e0 net/mptcp/protocol.c:2615 mptcpworker+0x434/0x740 net/mptcp/protocol.c:2767 processonework+0x1e0/0x560 kernel/workqueue.c:3254 processscheduledworks kernel/workqueue.c:3335 [inline] workerthread+0x3c7/0x640 kernel/workqueue.c:3416 kthread+0x121/0x170 kernel/kthread.c:388 retfromfork+0x44/0x50 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:243 </TASK>

When fallback to TCP happens early on a client socket, sndnxt is not yet initialized and any incoming ack will copy such value into snduna. If the mptcp worker (dumbly) tries mptcp-level re-injection after such ack, that would unconditionally trigger a send buffer cleanup using 'bad' snduna values.

We could easily disable re-injection for fallback sockets, but such dumb behavior already helped catching a few subtle issues and a very low to zero impact in practice.

Instead address the issue always initializing sndnxt (and writeseq, for consistency) at connect time.

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:

scsi: bnx2fc: Remove spinlockbh while releasing resources after upload

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024053039-CVE-2024-36919-9b97@gregkh/T

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

wifi: nl80211: don't free NULL coalescing rule

If the parsing fails, we can dereference a NULL pointer here.

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:

KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgicv2parseattr()

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024053040-CVE-2024-36953-fc12@gregkh/T

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

octeontx2-af: avoid off-by-one read from userspace

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024053041-CVE-2024-36957-5919@gregkh/T

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

firewire: ohci: mask bus reset interrupts between ISR and bottom half

In the FireWire OHCI interrupt handler, if a bus reset interrupt has occurred, mask bus reset interrupts until busresetwork has serviced and cleared the interrupt.

Normally, we always leave bus reset interrupts masked. We infer the bus reset from the self-ID interrupt that happens shortly thereafter. A scenario where we unmask bus reset interrupts was introduced in 2008 in a007bb857e0b26f5d8b73c2ff90782d9c0972620: If OHCIPARAMDEBUGBUSRESETS (8) is set in the debug parameter bitmask, we will unmask bus reset interrupts so we can log them.

irqhandler logs the bus reset interrupt. However, we can't clear the bus reset event flag in irqhandler, because we won't service the event until later. irqhandler exits with the event flag still set. If the corresponding interrupt is still unmasked, the first bus reset will usually freeze the system due to irqhandler being called again each time it exits. This freeze can be reproduced by loading firewireohci with "modprobe firewireohci debug=-1" (to enable all debugging output). Apparently there are also some cases where busresetwork will get called soon enough to clear the event, and operation will continue normally.

This freeze was first reported a few months after a007bb85 was committed, but until now it was never fixed. The debug level could safely be set to -1 through sysfs after the module was loaded, but this would be ineffectual in logging bus reset interrupts since they were only unmasked during initialization.

irqhandler will now leave the event flag set but mask bus reset interrupts, so irqhandler won't be called again and there will be no freeze. If OHCIPARAMDEBUGBUSRESETS is enabled, busresetwork will unmask the interrupt after servicing the event, so future interrupts will be caught as desired.

As a side effect to this change, OHCIPARAMDEBUGBUSRESETS can now be enabled through sysfs in addition to during initial module loading. However, when enabled through sysfs, logging of bus reset interrupts will be effective only starting with the second bus reset, after busresetwork has executed.

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

tipc: fix a possible memleak in tipcbufappend

skblinearize() doesn't free the skb when it fails, so move 'buf = NULL' after skblinearize(), so that the skb can be freed on the err path.

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

phonet: fix rtmphonetnotify() skb allocation

fillroute() stores three components in the skb:

- struct rtmsg - RTADST (u8) - RTAOIF (u32)

Therefore, rtmphonetnotify() should use

NLMSGALIGN(sizeof(struct rtmsg)) + nlatotalsize(1) + nlatotalsize(4)

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:

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:

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:

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:

net/rds: fix possible cp null dereference

cp might be null, calling cp->cpconn would produce null dereference

[Simon Horman adds:]

Analysis:

cp is a parameter of rdsrdmamap and is not reassigned.

The following call-sites pass a NULL cp argument to rdsrdmamap()

- rdsgetmr() - rdsgetmrfordest

Prior to the code above, the following assumes that cp may be NULL (which is indicative, but could itself be unnecessary)

transprivate = rs->rstransport->getmr( sg, nents, rs, &mr->rkey, cp ? cp->cpconn : NULL, args->vec.addr, args->vec.bytes, needodp ? ODPZEROBASED : ODPNOTNEEDED);

The code modified by this patch is guarded by ISERR(transprivate), where transprivate is assigned as per the previous point in this analysis.

The only implementation of getmr that I could locate is rdsibgetmr() which can return an ERRPTR if the conn (4th) argument is NULL.

ret is set to PTRERR(transprivate). rdsibgetmr can return ERRPTR(-ENODEV) if the conn (4th) argument is NULL. Thus ret may be -ENODEV in which case the code in question will execute.

Conclusion: cp may be NULL at the point where this patch adds a check; this patch does seem to address a possible bug

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

bpf, sockmap: Prevent lock inversion deadlock in map delete elem

syzkaller started using corpuses where a BPF tracing program deletes elements from a sockmap/sockhash map. Because BPF tracing programs can be invoked from any interrupt context, locks taken during a mapdeleteelem operation must be hardirq-safe. Otherwise a deadlock due to lock inversion is possible, as reported by lockdep:

CPU0 CPU1 ---- ---- lock(&htab->buckets[i].lock); localirqdisable(); lock(&host->lock); lock(&htab->buckets[i].lock); <Interrupt> lock(&host->lock);

Locks in sockmap are hardirq-unsafe by design. We expects elements to be deleted from sockmap/sockhash only in task (normal) context with interrupts enabled, or in softirq context.

Detect when mapdeleteelem operation is invoked from a context which is not hardirq-unsafe, that is interrupts are disabled, and bail out with an error.

Note that map updates are not affected by this issue. BPF verifier does not allow updating sockmap/sockhash from a BPF tracing program today.

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

x86/mm/pat: fix VMPAT handling in COW mappings

PAT handling won't do the right thing in COW mappings: the first PTE (or, in fact, all PTEs) can be replaced during write faults to point at anon folios. Reliably recovering the correct PFN and cachemode using followphys() from PTEs will not work in COW mappings.

Using followphys(), we might just get the address+protection of the anon folio (which is very wrong), or fail on swap/nonswap entries, failing followphys() and triggering a WARNONONCE() in untrackpfn() and trackpfncopy(), not properly calling freepfnrange().

In freepfnrange(), we either wouldn't call memtypefree() or would call it with the wrong range, possibly leaking memory.

To fix that, let's update followphys() to refuse returning anon folios, and fallback to using the stored PFN inside vma->vmpgoff for COW mappings if we run into that.

We will now properly handle untrackpfn() with COW mappings, where we don't need the cachemode. We'll have to fail fork()->trackpfncopy() if the first page was replaced by an anon folio, though: we'd have to store the cachemode in the VMA to make this work, likely growing the VMA size.

For now, lets keep it simple and let trackpfncopy() just fail in that case: it would have failed in the past with swap/nonswap entries already, and it would have done the wrong thing with anon folios.

Simple reproducer to trigger the WARNONONCE() in untrackpfn():

<--- C reproducer ---> #include <stdio.h> #include <sys/mman.h> #include <unistd.h> #include <liburing.h>

int main(void) { struct iouringparams p = {}; int ringfd; sizet size; char map;

ringfd = iouringsetup(1, &p); if (ringfd < 0) { perror("iouringsetup"); return 1; } size = p.sqoff.array + p.sqentries sizeof(unsigned);

/ Map the submission queue ring MAPPRIVATE / map = mmap(0, size, PROTREAD | PROTWRITE, MAPPRIVATE, ringfd, IORINGOFFSQRING); if (map == MAPFAILED) { perror("mmap"); return 1; }

/ We have at least one page. Let's COW it. / map = 0; pause(); return 0; } <--- C reproducer --->

On a system with 16 GiB RAM and swap configured: # ./iouring & # memhog 16G # killall iouring [ 301.552930] ------------[ cut here ]------------ [ 301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrackpfn+0xf4/0x100 [ 301.553989] Modules linked in: binfmtmisc nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectg [ 301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x8664 #1 [ 301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4 [ 301.559569] RIP: 0010:untrackpfn+0xf4/0x100 [ 301.559893] Code: 75 c4 eb cf 48 8b 43 10 8b a8 e8 00 00 00 3b 6b 28 74 b8 48 8b 7b 30 e8 ea 1a f7 000 [ 301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282 [ 301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047 [ 301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200 [ 301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000 [ 301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000 [ 301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000 [ 301.564186] FS: 0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000 [ 301.564773] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0 [ 301.565725] PKRU: 55555554 [ 301.565944] Call Trace: [ 301.566148] <TASK> [ 301.566325] ? untrackpfn+0xf4/0x100 [ 301.566618] ? warn+0x81/0x130 [ 301.566876] ? untrackpfn+0xf4/0x100 [ 3 ---truncated---

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

netfilter: nftables: reject new basechain after table flag update

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

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051952-CVE-2024-35900-c2c9@gregkh/T

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

net/sched: actskbmod: prevent kernel-infoleak

syzbot found that tcfskbmoddump() was copying four bytes from kernel stack to user space [1].

The issue here is that 'struct tcskbmod' has a four bytes hole.

We need to clear the structure before filling fields.

[1] BUG: KMSAN: kernel-infoleak in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak in copytouseriter lib/ioviter.c:24 [inline] BUG: KMSAN: kernel-infoleak in iterateubuf include/linux/ioviter.h:29 [inline] BUG: KMSAN: kernel-infoleak in iterateandadvance2 include/linux/ioviter.h:245 [inline] BUG: KMSAN: kernel-infoleak in iterateandadvance include/linux/ioviter.h:271 [inline] BUG: KMSAN: kernel-infoleak in copytoiter+0x366/0x2520 lib/ioviter.c:185 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouseriter lib/ioviter.c:24 [inline] iterateubuf include/linux/ioviter.h:29 [inline] iterateandadvance2 include/linux/ioviter.h:245 [inline] iterateandadvance include/linux/ioviter.h:271 [inline] copytoiter+0x366/0x2520 lib/ioviter.c:185 copytoiter include/linux/uio.h:196 [inline] simplecopytoiter net/core/datagram.c:532 [inline] skbdatagramiter+0x185/0x1000 net/core/datagram.c:420 skbcopydatagramiter+0x5c/0x200 net/core/datagram.c:546 skbcopydatagrammsg include/linux/skbuff.h:4050 [inline] netlinkrecvmsg+0x432/0x1610 net/netlink/afnetlink.c:1962 sockrecvmsgnosec net/socket.c:1046 [inline] sockrecvmsg+0x2c4/0x340 net/socket.c:1068 sysrecvfrom+0x35a/0x5f0 net/socket.c:2242 dosysrecvfrom net/socket.c:2260 [inline] sesysrecvfrom net/socket.c:2256 [inline] x64sysrecvfrom+0x126/0x1d0 net/socket.c:2256 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was stored to memory at: pskbexpandhead+0x30f/0x19d0 net/core/skbuff.c:2253 netlinktrim+0x2c2/0x330 net/netlink/afnetlink.c:1317 netlinkunicast+0x9f/0x1260 net/netlink/afnetlink.c:1351 nlmsgunicast include/net/netlink.h:1144 [inline] nlmsgnotify+0x21d/0x2f0 net/netlink/afnetlink.c:2610 rtnetlinksend+0x73/0x90 net/core/rtnetlink.c:741 rtnetlinkmaybesend include/linux/rtnetlink.h:17 [inline] tcfaddnotify net/sched/actapi.c:2048 [inline] tcfactionadd net/sched/actapi.c:2071 [inline] tcctlaction+0x146e/0x19d0 net/sched/actapi.c:2119 rtnetlinkrcvmsg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlinkrcvskb+0x375/0x650 net/netlink/afnetlink.c:2559 rtnetlinkrcv+0x34/0x40 net/core/rtnetlink.c:6613 netlinkunicastkernel net/netlink/afnetlink.c:1335 [inline] netlinkunicast+0xf4c/0x1260 net/netlink/afnetlink.c:1361 netlinksendmsg+0x10df/0x11f0 net/netlink/afnetlink.c:1905 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x30f/0x380 net/socket.c:745 syssendmsg+0x877/0xb60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x4a0 net/socket.c:2674 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75

Uninit was stored to memory at: nlaput lib/nlattr.c:1041 [inline] nlaput+0x1c6/0x230 lib/nlattr.c:1099 tcfskbmoddump+0x23f/0xc20 net/sched/actskbmod.c:256 tcfactiondumpold net/sched/actapi.c:1191 [inline] tcfactiondump1+0x85e/0x970 net/sched/actapi.c:1227 tcfactiondump+0x1fd/0x460 net/sched/actapi.c:1251 tcagetfill+0x519/0x7a0 net/sched/actapi.c:1628 tcfaddnotifymsg net/sched/actapi.c:2023 [inline] tcfaddnotify net/sched/actapi.c:2042 [inline] tcfactionadd net/sched/actapi.c:2071 [inline] tcctlaction+0x1365/0x19d0 net/sched/actapi.c:2119 rtnetlinkrcvmsg+0x1737/0x1900 net/core/rtnetlink.c:6595 netlinkrcvskb+0x375/0x650 net/netlink/afnetli ---truncated---

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.

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

net/smc: reduce rtnl pressure in smcpnetcreatepnetidslist()

Many syzbot reports show extreme rtnl pressure, and many of them hint that smc acquires rtnl in netns creation for no good reason [1]

This patch returns early from smcpnetnetinit() if there is no netdevice yet.

I am not even sure why smcpnetcreatepnetidslist() even exists, because smcpnetnetdevevent() is also calling smcpnetaddbasepnetid() when handling NETDEVUP event.

[1] extract of typical syzbot reports

2 locks held by syz-executor.3/12252: #0: ffffffff8f369610 (pernetopsrwsem){++++}-{3:3}, at: copynetns+0x4c7/0x7b0 net/core/netnamespace.c:491 #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetcreatepnetidslist net/smc/smcpnet.c:809 [inline] #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetnetinit+0x10a/0x1e0 net/smc/smcpnet.c:878 2 locks held by syz-executor.4/12253: #0: ffffffff8f369610 (pernetopsrwsem){++++}-{3:3}, at: copynetns+0x4c7/0x7b0 net/core/netnamespace.c:491 #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetcreatepnetidslist net/smc/smcpnet.c:809 [inline] #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetnetinit+0x10a/0x1e0 net/smc/smcpnet.c:878 2 locks held by syz-executor.1/12257: #0: ffffffff8f369610 (pernetopsrwsem){++++}-{3:3}, at: copynetns+0x4c7/0x7b0 net/core/netnamespace.c:491 #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetcreatepnetidslist net/smc/smcpnet.c:809 [inline] #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetnetinit+0x10a/0x1e0 net/smc/smcpnet.c:878 2 locks held by syz-executor.2/12261: #0: ffffffff8f369610 (pernetopsrwsem){++++}-{3:3}, at: copynetns+0x4c7/0x7b0 net/core/netnamespace.c:491 #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetcreatepnetidslist net/smc/smcpnet.c:809 [inline] #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetnetinit+0x10a/0x1e0 net/smc/smcpnet.c:878 2 locks held by syz-executor.0/12265: #0: ffffffff8f369610 (pernetopsrwsem){++++}-{3:3}, at: copynetns+0x4c7/0x7b0 net/core/netnamespace.c:491 #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetcreatepnetidslist net/smc/smcpnet.c:809 [inline] #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetnetinit+0x10a/0x1e0 net/smc/smcpnet.c:878 2 locks held by syz-executor.3/12268: #0: ffffffff8f369610 (pernetopsrwsem){++++}-{3:3}, at: copynetns+0x4c7/0x7b0 net/core/netnamespace.c:491 #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetcreatepnetidslist net/smc/smcpnet.c:809 [inline] #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetnetinit+0x10a/0x1e0 net/smc/smcpnet.c:878 2 locks held by syz-executor.4/12271: #0: ffffffff8f369610 (pernetopsrwsem){++++}-{3:3}, at: copynetns+0x4c7/0x7b0 net/core/netnamespace.c:491 #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetcreatepnetidslist net/smc/smcpnet.c:809 [inline] #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetnetinit+0x10a/0x1e0 net/smc/smcpnet.c:878 2 locks held by syz-executor.1/12274: #0: ffffffff8f369610 (pernetopsrwsem){++++}-{3:3}, at: copynetns+0x4c7/0x7b0 net/core/netnamespace.c:491 #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetcreatepnetidslist net/smc/smcpnet.c:809 [inline] #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetnetinit+0x10a/0x1e0 net/smc/smcpnet.c:878 2 locks held by syz-executor.2/12280: #0: ffffffff8f369610 (pernetopsrwsem){++++}-{3:3}, at: copynetns+0x4c7/0x7b0 net/core/netnamespace.c:491 #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetcreatepnetidslist net/smc/smcpnet.c:809 [inline] #1: ffffffff8f375b88 (rtnlmutex){+.+.}-{3:3}, at: smcpnetnetinit+0x10a/0x1e0 net/smc/smcpnet.c:878