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 retfromforkasm+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 skforwardallocadd()

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 | skmemreclaim() | -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().

bpf: Fix overloading of MEMUNINIT's meaning

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

Bluetooth: SCO: Fix UAF on scosocktimeout

conn->sk maybe have been unlinked/freed while waiting for scoconnlock so this checks if the conn->sk is still valid by checking if it part of scosklist.

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

tracing: Consider the NULL character when validating the event length

strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character.

This commit checks this condition and returns failure for it.

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

ksmbd: check outstanding simultaneous SMB operations

If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the "ksmbdworkcache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.

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

sctp: properly validate chunk size in sctpsfootb()

A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctpsfootb() to address a crash reported by syzbot:

BUG: KMSAN: uninit-value in sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpdosm+0x181/0x93d0 net/sctp/smsideeffect.c:1166 sctpendpointbhrcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctpinqpush+0x2ef/0x380 net/sctp/inqueue.c:88 sctprcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4rcv+0x42/0x50 net/sctp/protocol.c:1159 ipprotocoldeliverrcu+0xb51/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233

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

x86/entry32: Clear CPU buffers after register restore in NMI return

CPU buffers are currently cleared after call to excnmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data.

Move CLEARCPUBUFFERS after RESTOREALLNMI.

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

smb: client: fix OOBs when building SMB2IOCTL request

When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2setnextcommand().

SMB2ioctlinit() allocates a small buffer (448 bytes) to hold the SMB2IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2setnextcommand() will end up writing off the end of @rqst->iov[0].iovbase as shown below:

mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link

BUG: KASAN: slab-out-of-bounds in smb2setnextcommand.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859

CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] printreport+0x156/0x4d9 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] ? virtaddrvalid+0x145/0x310 ? physaddr+0x46/0x90 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] kasanreport+0xda/0x110 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] kasancheckrange+0x10f/0x1f0 asanmemcpy+0x3c/0x60 smb2setnextcommand.cold+0x1d6/0x24c [cifs] smb2compoundop+0x238c/0x3840 [cifs] ? kasansavetrack+0x14/0x30 ? kasansavefreeinfo+0x3b/0x70 ? vfssymlink+0x1a1/0x2c0 ? dosymlinkat+0x108/0x1c0 ? pfxsmb2compoundop+0x10/0x10 [cifs] ? kmemcachefree+0x118/0x3e0 ? cifsgetwritablepath+0xeb/0x1a0 [cifs] smb2getreparseinode+0x423/0x540 [cifs] ? pfxsmb2getreparseinode+0x10/0x10 [cifs] ? rcuiswatching+0x20/0x50 ? kmallocnoprof+0x37c/0x480 ? smb2createreparsesymlink+0x257/0x490 [cifs] ? smb2createreparsesymlink+0x38f/0x490 [cifs] smb2createreparsesymlink+0x38f/0x490 [cifs] ? pfxsmb2createreparsesymlink+0x10/0x10 [cifs] ? findheldlock+0x8a/0xa0 ? hlockclass+0x32/0xb0 ? buildpathfromdentryoptionalprefix+0x19d/0x2e0 [cifs] cifssymlink+0x24f/0x960 [cifs] ? pfxmakevfsuid+0x10/0x10 ? pfxcifssymlink+0x10/0x10 [cifs] ? makevfsgid+0x6b/0xc0 ? genericpermission+0x96/0x2d0 vfssymlink+0x1a1/0x2c0 dosymlinkat+0x108/0x1c0 ? pfxdosymlinkat+0x10/0x10 ? strncpyfromuser+0xaa/0x160 x64syssymlinkat+0xb9/0xf0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb

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

wifi: iwlegacy: Clear stale interrupts before resuming device

iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up.

Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume.

Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: ilisr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965irqtasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RFKILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965irqtasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965macstart enter [ 12.052212] ieee80211 phy0: ilprepstation Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965sethwready hardware ready [ 12.052324] ieee80211 phy0: ilapminit Init card's basic functions [ 12.052348] ieee80211 phy0: ilapminit L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965loadbsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965verifybsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965verifybsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965loadbsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: il4965up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965macstart Start UP work done. [ 12.058757] ieee80211 phy0: il4965down iwl4965 is going down [ 12.058761] ieee80211 phy0: ilscancanceltimeout Scan cancel timeout [ 12.058762] ieee80211 phy0: ildoscanabort Not performing scan to abort [ 12.058765] ieee80211 phy0: ilclearucodestations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: ilclearucodestations No active stations found to be cleared [ 12.058819] ieee80211 phy0: ilapmstop Stop card, put in low power state [ 12.058827] ieee80211 phy0: ilapmstopmaster stop master [ 12.058864] ieee80211 phy0: il4965clearfreeframes 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: STARTALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm schfqcodel xttcpudp xtmultiport xtstate iptablefilter iptablenat nfnat nfconntrack nfdefragipv4 iptables xtables binfmtmisc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdhgeneric ecc iTCOwdt i2cdev iwl4965 iwlegacy coretemp sndhdacodecanalog pcspkr psmouse mac80211 sndhdacodecgeneric libarc4 sdhcipci cqhci sha256generic sdhci libsha256 firewireohci sndhdaintel sndinteldspcfg mmccore sndhdacodec sndhwdep firewirecore ledclass iosfmbi sndhdacore uhcihcd lpcich crcitut cfg80211 ehcipci ehcihcd sndpcm usbcore mfdcore rfkill sndtimer snd usbcommon soundcore video parportpc parport intelagp wmi intelgtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async asyncrunentryfn [ 16.132469] RIP: 0010:ieee80211reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---

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

ksmbd: Fix the missing xastore error check

xastore() can fail, it return xaerr(-EINVAL) if the entry cannot be stored in an XArray, or xaerr(-ENOMEM) if memory allocation failed, so check error for xastore() to fix it.

fs/ntfs3: Add rough attr allocsize check

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

usb: typec: fix potential out of bounds in ucsiccgupdatesetnewcamcmd()

The "cmd" variable can be controlled by the user via debugfs. That means "newcam" can be as high as 255 while the size of the uc->updated[] array is UCSIMAXALTMODES (30).

The call tree is: ucsicmd() // val comes from simpleattrwritexsigned() -> ucsisendcommand() -> ucsisendcommandcommon() -> ucsiruncommand() // calls ucsi->ops->synccontrol() -> ucsiccgsynccontrol()

bpf: Fix out-of-bounds write in triegetnextkey()

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

vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans

During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.

drm/amdgpu: add missing size check in amdgpudebugfsgprwaveread()

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

ntfs3: Add bounds checking to mienumattr()

Added bounds checking to make sure that every attr don't stray beyond valid memory region.

fs/ntfs3: Check if more than chunk-size bytes are written

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

mptcp: handle consistently DSS corruption

Bugged peer implementation can send corrupted DSS options, consistently hitting a few warning in the data path. Use DEBUGNET assertions, to avoid the splat on some builds and handle consistently the error, dumping related MIBs and performing fallback and/or reset according to the subflow type.

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

net: explicitly clear the sk pointer, when pf->create fails

We have recently noticed the exact same KASAN splat as in commit 6cd4a78d962b ("net: do not leave a dangling sk pointer, when socket creation fails"). The problem is that commit did not fully address the problem, as some pf->create implementations do not use skcommonrelease in their error paths.

For example, we can use the same reproducer as in the above commit, but changing ping to arping. arping uses AFPACKET socket and if packetcreate fails, it will just skfree the allocated sk object.

While we could chase all the pf->create implementations and make sure they NULL the freed sk object on error from the socket, we can't guarantee future protocols will not make the same mistake.

So it is easier to just explicitly NULL the sk pointer upon return from pf->create in sockcreate. We do know that pf->create always releases the allocated sk object on error, so if the pointer is not NULL, it is definitely dangling.

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

nilfs2: fix kernel bug due to missing clearing of checked flag

Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, blockwritebeginint(), which is called to prepare block writes, may fail the BUGON check for accesses exceeding the folio/page size, triggering a kernel bug.

This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that.

This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.

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

wifi: iwlwifi: mvm: Fix response handling in iwlmvmsendrecoverycmd()

1. The size of the response packet is not validated. 2. The response buffer is not freed.

Resolve these issues by switching to iwlmvmsendcmdstatus(), which handles both size validation and frees the buffer.

dm cache: fix potential out-of-bounds access on the first resume

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

security/keys: fix slab-out-of-bounds in keytaskpermission

KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in kuidval include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uideq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in keytaskpermission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362

CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: dumpstack lib/dumpstack.c:82 [inline] dumpstack+0x107/0x167 lib/dumpstack.c:123 printaddressdescription.constprop.0+0x19/0x170 mm/kasan/report.c:400 kasanreport.cold+0x6c/0x84 mm/kasan/report.c:560 kasanreport+0x3a/0x50 mm/kasan/report.c:585 kuidval include/linux/uidgid.h:36 [inline] uideq include/linux/uidgid.h:63 [inline] keytaskpermission+0x394/0x410 security/keys/permission.c:54 searchnestedkeyrings+0x90e/0xe90 security/keys/keyring.c:793

This issue was also reported by syzbot.

It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1.

The reproducer demonstrates how this issue happened: 1. In the searchnestedkeyrings function, when it iterates through the slots in a node(below tag ascendtonode), if the slot pointer is meta and node->backpointer != NULL(it means a root), it will proceed to descendtonode. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyringptriskeyring function. However, KEYRINGPTRSUBTYPE is 0x2UL, the same as ASSOCARRAYPTRSUBTYPEMASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut.

NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+

4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key, leading to a read out-of-bounds read.

To fix this issue, one should jump to descendtonode if the ptr is a shortcut, regardless of whether the node is root or not.

[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/

[jarkko: tweaked the commit message a bit to have an appropriate closes tag.]

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

mm: resolve faulty mmapregion() error path behaviour

The mmapregion() function is somewhat terrifying, with spaghetti-like control flow and numerous means by which issues can arise and incomplete state, memory leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late in the process of mapping a VMA, which forms the basis of recently observed issues with resource leaks and observable inconsistent state.

Taking advantage of previous patches in this series we move a number of checks earlier in the code, simplifying things by moving the core of the logic into a static internal function mmapregion().

Doing this allows us to perform a number of checks up front before we do any real work, and allows us to unwind the writable unmap check unconditionally as required and to perform a CONFIGDEBUGVMMAPLETREE validation unconditionally also.

We move a number of things here:

1. We preallocate memory for the iterator before we call the file-backed memory hook, allowing us to exit early and avoid having to perform complicated and error-prone close/free logic. We carefully free iterator state on both success and error paths.

2. The enclosing mmapregion() function handles the mappingmapwritable() logic early. Previously the logic had the mappingmapwritable() at the point of mapping a newly allocated file-backed VMA, and a matching mappingunmapwritable() on success and error paths.

We now do this unconditionally if this is a file-backed, shared writable mapping. If a driver changes the flags to eliminate VMMAYWRITE, however doing so does not invalidate the seal check we just performed, and we in any case always decrement the counter in the wrapper.

We perform a debug assert to ensure a driver does not attempt to do the opposite.

3. We also move archvalidateflags() up into the mmapregion() function. This is only relevant on arm64 and sparc64, and the check is only meaningful for SPARC with ADI enabled. We explicitly add a warning for this arch if a driver invalidates this check, though the code ought eventually to be fixed to eliminate the need for this.

With all of these measures in place, we no longer need to explicitly close the VMA on error paths, as we place all checks which might fail prior to a call to any driver mmap hook.

This eliminates an entire class of errors, makes the code easier to reason about and more robust.

i40e: fix race condition by adding filter's intermediate sync state

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

posix-clock: Fix missing timespec64 check in pcclocksettime()

As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tvsec and tvnsec range before calling ptp->info->settime64().

As the man manual of clocksettime() said, if tp.tvsec is negative or tp.tvnsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64valid(). As Thomas suggested, timespec64valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64validstrict() in pcclocksettime() and return -EINVAL if not valid.

There are some drivers that use tp->tvsec and tp->tvnsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclgeptpsettime(), igbptpsettimei210(), rcargen4ptpsettime(), and some drivers can remove the checks of itself.

bpf: Add skisinet and ISICSK check in tlsswhasctxtx/rx

btrfs: reinitialize delayed ref list after deleting it from the list

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

nvme-multipath: defer partition scanning

We need to suppress the partition scan from occuring within the controller's scanwork context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scanwork, so it would deadlock. Defer the partion scan to a different context that does not block scanwork.

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

nvme: tcp: avoid race between queuelock lock and destroy

Commit 76d54bf20cdc ("nvme-tcp: don't access released socket during error recovery") added a mutexlock() call for the queue->queuelock in nvmetcpgetaddress(). However, the mutexlock() races with mutexdestroy() in nvmetcpfreequeue(), and causes the WARN below.

DEBUGLOCKSWARNON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 mutexlock+0xcf0/0x1220 Modules linked in: nvmettcp nvmet nvmetcp nvmefabrics iwcm ibcm ibcore pktcdvd nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables qrtr sunrpc ppdev 9pnetvirtio 9pnet pcspkr netfs parportpc parport e1000 i2cpiix4 i2csmbus loop fuse nfnetlink zram bochs drmvramhelper drmttmhelper ttm drmkmshelper xfs drm sym53c8xx floppy nvme scsitransportspi nvmecore nvmeauth serioraw atageneric pataacpi dmmultipath qemufwcfg [last unloaded: ibuverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mutexlock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? warn.cold+0x5b/0x1af ? mutexlock+0xcf0/0x1220 ? reportbug+0x1ec/0x390 ? handlebug+0x3c/0x80 ? excinvalidop+0x13/0x40 ? asmexcinvalidop+0x16/0x20 ? mutexlock+0xcf0/0x1220 ? nvmetcpgetaddress+0xc2/0x1e0 [nvmetcp] ? pfxmutexlock+0x10/0x10 ? lockacquire+0xd6a/0x59e0 ? nvmetcpgetaddress+0xc2/0x1e0 [nvmetcp] nvmetcpgetaddress+0xc2/0x1e0 [nvmetcp] ? pfxnvmetcpgetaddress+0x10/0x10 [nvmetcp] nvmesysfsshowaddress+0x81/0xc0 [nvmecore] devattrshow+0x42/0x80 ? asanmemset+0x1f/0x40 sysfskfseqshow+0x1f0/0x370 seqreaditer+0x2cb/0x1130 ? rwverifyarea+0x3b1/0x590 ? mutexlock+0x433/0x1220 vfsread+0x6a6/0xa20 ? lockdephardirqson+0x78/0x100 ? pfxvfsread+0x10/0x10 ksysread+0xf7/0x1d0 ? pfxksysread+0x10/0x10 ? x64sysopenat+0x105/0x1d0 dosyscall64+0x93/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? pfxksysread+0x10/0x10 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? dosyscall64+0x9f/0x180 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---