In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix race condition between session lookup and expire
Thread A + Thread B ksmbdsessionlookup | smb2sesssetup sess = xaload | | | xaerase(&conn->sessions, sess->id); | | ksmbdsessiondestroy(sess) --> kfree(sess) | // UAF! | sess->lastactive = jiffies | +
This patch add rwsem to fix race condition between ksmbdsessionlookup and ksmbdexpiresession.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab out of bounds write in smbinheritdacl()
slab out-of-bounds write is caused by that offsets is bigger than pntsd allocation size. This patch add the check to validate 3 offsets using allocation size.
In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Use variable length array instead of fixed size
Should fix smatch warning: ntfssetlabel() error: builtinmemcpy() 'uni->name' too small (20 vs 256)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible UAF in ip6xmit()
If skbexpandhead() returns NULL, skb has been freed and the associated dst/idev could also have been freed.
We must use rcureadlock() to prevent a possible UAF.
In the Linux kernel, the following vulnerability has been resolved:
net: mana: Fix race on per-CQ variable napi workdone
After calling napicompletedone(), the NAPIFSTATESCHED bit may be cleared, and another CPU can start napi thread and access per-CQ variable, cq->workdone. If the other thread (for example, from busypoll) sets it to a value >= budget, this thread will continue to run when it should stop, and cause memory corruption and panic.
To fix this issue, save the per-CQ workdone variable in a local variable before napicompletedone(), so it won't be corrupted by a possible concurrent thread after napicompletedone().
Also, add a flag bit to advertise to the NIC firmware: the NAPI workdone variable race is fixed, so the driver is able to reliably support features like busypoll.
In the Linux kernel, the following vulnerability has been resolved:
nvme: fix SRCU protection of nvmenshead list
Walking the nvmenshead siblings list is protected by the head's srcu in nvmensheadsubmitbio() but not nvmempathrevalidatepaths(). Removing namespaces from the list also fails to synchronize the srcu. Concurrent scan work can therefore cause use-after-frees.
Hold the head's srcu lock in nvmempathrevalidatepaths() and synchronize with the srcu, not the global RCU, in nvmensremove().
Observed the following panic when making NVMe/RDMA connections with native multipath on the Rocky Linux 8.6 kernel (it seems the upstream kernel has the same race condition). Disassembly shows the faulting instruction is cmp 0x50(%rdx),%rcx; computing capacity != getcapacity(ns->disk). Address 0x50 is dereferenced because ns->disk is NULL. The NULL disk appears to be the result of concurrent scan work freeing the namespace (note the log line in the middle of the panic).
[37314.206036] BUG: unable to handle kernel NULL pointer dereference at 0000000000000050 [37314.206036] nvme0n3: detected capacity change from 0 to 11811160064 [37314.299753] PGD 0 P4D 0 [37314.299756] Oops: 0000 [#1] SMP PTI [37314.299759] CPU: 29 PID: 322046 Comm: kworker/u98:3 Kdump: loaded Tainted: G W X --------- - - 4.18.0-372.32.1.el8test86.x8664 #1 [37314.299762] Hardware name: Dell Inc. PowerEdge R720/0JP31P, BIOS 2.7.0 05/23/2018 [37314.299763] Workqueue: nvme-wq nvmescanwork [nvmecore] [37314.299783] RIP: 0010:nvmempathrevalidatepaths+0x26/0xb0 [nvmecore] [37314.299790] Code: 1f 44 00 00 66 66 66 66 90 55 53 48 8b 5f 50 48 8b 83 c8 c9 00 00 48 8b 13 48 8b 48 50 48 39 d3 74 20 48 8d 42 d0 48 8b 50 20 <48> 3b 4a 50 74 05 f0 80 60 70 ef 48 8b 50 30 48 8d 42 d0 48 39 d3 [37315.058803] RSP: 0018:ffffabe28f913d10 EFLAGS: 00010202 [37315.121316] RAX: ffff927a077da800 RBX: ffff92991dd70000 RCX: 0000000001600000 [37315.206704] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff92991b719800 [37315.292106] RBP: ffff929a6b70c000 R08: 000000010234cd4a R09: c0000000ffff7fff [37315.377501] R10: 0000000000000001 R11: ffffabe28f913a30 R12: 0000000000000000 [37315.462889] R13: ffff92992716600c R14: ffff929964e6e030 R15: ffff92991dd70000 [37315.548286] FS: 0000000000000000(0000) GS:ffff92b87fb80000(0000) knlGS:0000000000000000 [37315.645111] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [37315.713871] CR2: 0000000000000050 CR3: 0000002208810006 CR4: 00000000000606e0 [37315.799267] Call Trace: [37315.828515] nvmeupdatensinfo+0x1ac/0x250 [nvmecore] [37315.892075] nvmevalidateorallocns+0x2ff/0xa00 [nvmecore] [37315.961871] ? blkmqfreerequest+0x6b/0x90 [37316.015021] nvmescanwork+0x151/0x240 [nvmecore] [37316.073371] processonework+0x1a7/0x360 [37316.121318] ? createworker+0x1a0/0x1a0 [37316.168227] workerthread+0x30/0x390 [37316.212024] ? createworker+0x1a0/0x1a0 [37316.258939] kthread+0x10a/0x120 [37316.297557] ? setkthreadstruct+0x50/0x50 [37316.347590] retfromfork+0x35/0x40 [37316.390360] Modules linked in: nvmerdma nvmetcp(X) nvmefabrics nvmecore netconsole iscsitcp libiscsitcp dmqueuelength dmservicetime nfconntracknetlink brnetfilter bridge stp llc overlay nftchainnat iptMASQUERADE nfnat xtaddrtype xtCT nftcounter xtstate xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 xtcomment xtmultiport nftcompat nftables libcrc32c nfnetlink dmmultipath tg3 rpcrdma sunrpc rdmaucm ibsrpt ibisert iscsitargetmod targetcoremod ibiser libiscsi scsitransportiscsi ibumad rdmacm ibipoib iwcm ibcm intelraplmsr iTCOwdt iTCOvendorsupport dcdbas intelraplcommon sbedac x86pkgtempthermal intelpowerclamp coretemp kvmintel ipmissif kvm irqbypass crct10difpclmul crc32pclmul mlx5ib ghashclmulniintel ibuverbs rapl intelcstate inteluncore ibcore ipmisi joydev meime pcspkr ipmidevintf mei lpcich wmi ipmimsghandler acpipowermeter ex ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix TCP options overflow.
Syzbot reported the following splat:
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] CPU: 1 UID: 0 PID: 5836 Comm: sshd Not tainted 6.13.0-rc3-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/25/2024 RIP: 0010:compoundhead include/linux/page-flags.h:242 [inline] RIP: 0010:putpage+0x23/0x260 include/linux/mm.h:1552 Code: 90 90 90 90 90 90 90 55 41 57 41 56 53 49 89 fe 48 bd 00 00 00 00 00 fc ff df e8 f8 5e 12 f8 49 8d 5e 08 48 89 d8 48 c1 e8 03 <80> 3c 28 00 74 08 48 89 df e8 8f c7 78 f8 48 8b 1b 48 89 de 48 83 RSP: 0000:ffffc90003916c90 EFLAGS: 00010202 RAX: 0000000000000001 RBX: 0000000000000008 RCX: ffff888030458000 RDX: 0000000000000100 RSI: 0000000000000000 RDI: 0000000000000000 RBP: dffffc0000000000 R08: ffffffff898ca81d R09: 1ffff110054414ac R10: dffffc0000000000 R11: ffffed10054414ad R12: 0000000000000007 R13: ffff88802a20a542 R14: 0000000000000000 R15: 0000000000000000 FS: 00007f34f496e800(0000) GS:ffff8880b8700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9d6ec9ec28 CR3: 000000004d260000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbpageunref include/linux/skbuffref.h:43 [inline] skbfragunref include/linux/skbuffref.h:56 [inline] skbreleasedata+0x483/0x8a0 net/core/skbuff.c:1119 skbreleaseall net/core/skbuff.c:1190 [inline] kfreeskb+0x55/0x70 net/core/skbuff.c:1204 tcpcleanrtxqueue net/ipv4/tcpinput.c:3436 [inline] tcpack+0x2442/0x6bc0 net/ipv4/tcpinput.c:4032 tcprcvstateprocess+0x8eb/0x44e0 net/ipv4/tcpinput.c:6805 tcpv4dorcv+0x77d/0xc70 net/ipv4/tcpipv4.c:1939 tcpv4rcv+0x2dc0/0x37f0 net/ipv4/tcpipv4.c:2351 ipprotocoldeliverrcu+0x22e/0x440 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x341/0x5f0 net/ipv4/ipinput.c:233 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 NFHOOK+0x3a4/0x450 include/linux/netfilter.h:314 netifreceiveskbonecore net/core/dev.c:5672 [inline] netifreceiveskb+0x2bf/0x650 net/core/dev.c:5785 processbacklog+0x662/0x15b0 net/core/dev.c:6117 napipoll+0xcb/0x490 net/core/dev.c:6883 napipoll net/core/dev.c:6952 [inline] netrxaction+0x89b/0x1240 net/core/dev.c:7074 handlesoftirqs+0x2d4/0x9b0 kernel/softirq.c:561 dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] irqexitrcu+0xf7/0x220 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimerinterrupt+0x57/0xc0 arch/x86/kernel/apic/apic.c:1049 asmsysvecapictimerinterrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 RIP: 0033:0x7f34f4519ad5 Code: 85 d2 74 0d 0f 10 02 48 8d 54 24 20 0f 11 44 24 20 64 8b 04 25 18 00 00 00 85 c0 75 27 41 b8 08 00 00 00 b8 0f 01 00 00 0f 05 <48> 3d 00 f0 ff ff 76 75 48 8b 15 24 73 0d 00 f7 d8 64 89 02 48 83 RSP: 002b:00007ffec5b32ce0 EFLAGS: 00000246 RAX: 0000000000000001 RBX: 00000000000668a0 RCX: 00007f34f4519ad5 RDX: 00007ffec5b32d00 RSI: 0000000000000004 RDI: 0000564f4bc6cae0 RBP: 0000564f4bc6b5a0 R08: 0000000000000008 R09: 0000000000000000 R10: 00007ffec5b32de8 R11: 0000000000000246 R12: 0000564f48ea8aa4 R13: 0000000000000001 R14: 0000564f48ea93e8 R15: 00007ffec5b32d68 </TASK>
Eric noted a probable shinfo->nrfrags corruption, which indeed occurs.
The root cause is a buggy MPTCP option len computation in some circumstances: the ADDADDR option should be mutually exclusive with DSS since the blamed commit.
Still, mptcpestablishedoptionsaddaddr() tries to set the relevant info in mptcpoutoptions, if ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
skbuff: fix coalescing for pagepool fragment recycling
Fix a use-after-free when using pagepool with page fragments. We encountered this problem during normal RX in the hns3 driver:
(1) Initially we have three descriptors in the RX queue. The first one allocates PAGE1 through pagepool, and the other two allocate one half of PAGE2 each. Page references look like this:
RXBD1 PAGE1 RXBD2 PAGE2 RXBD3 /
(2) Handle RX on the first descriptor. Allocate SKB1, eventually added to the receive queue by tcpqueuercv().
(3) Handle RX on the second descriptor. Allocate SKB2 and pass it to netifreceiveskb():
netifreceiveskb(SKB2) iprcv(SKB2) SKB3 = skbclone(SKB2)
SKB2 and SKB3 share a reference to PAGE2 through skbshinfo()->dataref. The other ref to PAGE2 is still held by RXBD3:
SKB2 ---+- PAGE2 SKB3 / / RXBD3 /
(3b) Now while handling TCP, coalesce SKB3 with SKB1:
tcpv4rcv(SKB3) tcptrycoalesce(to=SKB1, from=SKB3) // succeeds kfreeskbpartial(SKB3) skbreleasedata(SKB3) // drops one dataref
SKB1 PAGE1 \ SKB2 PAGE2 / RXBD3 /
In skbtrycoalesce(), skbfragref() takes a page reference to PAGE2, where it should instead have increased the pagepool frag reference, ppfragcount. Without coalescing, when releasing both SKB2 and SKB3, a single reference to PAGE2 would be dropped. Now when releasing SKB1 and SKB2, two references to PAGE2 will be dropped, resulting in underflow.
(3c) Drop SKB2:
afpacketrcv(SKB2) consumeskb(SKB2) skbreleasedata(SKB2) // drops second dataref pagepoolreturnskbpage(PAGE2) // drops one ppfragcount
SKB1 PAGE1 \ PAGE2 / RXBD3 /
(4) Userspace calls recvmsg() Copies SKB1 and releases it. Since SKB3 was coalesced with SKB1, we release the SKB3 page as well:
tcpeatrecvskb(SKB1) skbreleasedata(SKB1) pagepoolreturnskbpage(PAGE1) pagepoolreturnskbpage(PAGE2) // drops second ppfragcount
(5) PAGE2 is freed, but the third RX descriptor was still using it! In our case this causes IOMMU faults, but it would silently corrupt memory if the IOMMU was disabled.
Change the logic that checks whether pprecycle SKBs can be coalesced. We still reject differing pprecycle between 'from' and 'to' SKBs, but in order to avoid the situation described above, we also reject coalescing when both 'from' and 'to' are pprecycled and 'from' is cloned.
The new logic allows coalescing a cloned pprecycle SKB into a page refcounted one, because in this case the release (4) will drop the right reference, the one taken by skbtrycoalesce().
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix integer overflows on 32 bit systems
On 32bit systems the addition operations in ipcmsgalloc() can potentially overflow leading to memory corruption. Add bounds checking using KSMBDIPCMAXPAYLOAD to avoid overflow.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: Fix dangling pointer in krbauthenticate
krbauthenticate frees sess->user and does not set the pointer to NULL. It calls ksmbdkrb5authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2sesssetup, which calls krbauthenticate, will be accessing free'd memory when it later uses sess->user.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in kerberos authentication
Setting sess->user = NULL was introduced to fix the dangling pointer created by ksmbdfreeuser. However, it is possible another thread could be operating on the session and make use of sess->user after it has been passed to ksmbdfreeuser but before sess->user is set to NULL.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix PreauhHashValue race condition
If client send multiple session setup requests to ksmbd, PreauhHashValue race condition could happen. There is no need to free sess->PreauhHashValue at session setup phase. It can be freed together with session at connection termination phase.
In the Linux kernel, the following vulnerability has been resolved:
smb: server: let senddone handle a completion without IBSENDSIGNALED
With smbdirectsendbatch processing we likely have requests without IBSENDSIGNALED, which will be destroyed in the final request that has IBSENDSIGNALED set.
If the connection is broken all requests are signaled even without explicit IBSENDSIGNALED.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix signededness bug in smbdirectpreparenegotiation()
smbdirectpreparenegotiation() casts an unsigned u32 value from sp->maxrecvsize and req->preferredsendsize to a signed int before computing mint(int, ...). A maliciously provided preferredsendsize of 0x80000000 will return as smaller than maxrecvsize, and then be used to set the maximum allowed alowed receive size for the next message.
By sending a second message with a large value (>1420 bytes) the attacker can then achieve a heap buffer overflow.
This fix replaces mint(int, ...) with mint(u32)
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ioam: fix heap buffer overflow in ioam6filltracedata()
On the receive path, ioam6filltracedata() uses trace->nodelen to decide how much data to write for each node. It trusts this field as-is from the incoming packet, with no consistency check against trace->type (the 24-bit field that tells which data items are present). A crafted packet can set nodelen=0 while setting type bits 0-21, causing the function to write ~100 bytes past the allocated region (into skbsharedinfo), which corrupts adjacent heap memory and leads to a kernel panic.
Add a shared helper ioam6tracecomputenodelen() in ioam6.c to derive the expected nodelen from the type field, and use it:
- in ioam6iptunnel.c (send path, existing validation) to replace the open-coded computation; - in exthdrs.c (receive path, ipv6hopioam) to drop packets whose nodelen is inconsistent with the type field, before any data is written.
Per RFC 9197, bits 12-21 are each short (4-octet) fields, so they are included in IOAM6MASKSHORTFIELDS (changed from 0xff100000 to 0xff1ffc00).
In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: ioam6: prevent schema length wraparound in trace fill
ioam6filltracedata() stores the schema contribution to the trace length in a u8. With bit 22 enabled and the largest schema payload, sclen becomes 1 + 1020 / 4, wraps from 256 to 0, and bypasses the remaining-space check. ioam6filltracedata() then positions the write cursor without reserving the schema area but still copies the 4-byte schema header and the full schema payload, overrunning the trace buffer.
Keep sclen in an unsigned int so the remaining-space check and the write cursor calculation both see the full schema length.
In the Linux kernel, the following vulnerability has been resolved:
smb: server: fix use-after-free in smb2open()
The opinfo pointer obtained via rcudereference(fp->fopinfo) is dereferenced after rcureadunlock(), creating a use-after-free window.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix FSCTL permission bypass by adding a permission check for FSCTLSETSPARSE
FSCTLSETSPARSE in fsctlsetsparse() modifies the file's sparse attribute and saves it through xattr without any permission checks.
This exposes two issues:
1) A client on a read-only share can change the sparse attribute on files it opened, even though the share is read-only. Other FSCTL write operations already check testtreeconnflag(work->tcon, KSMBDTREECONNFLAGWRITABLE), but FSCTLSETSPARSE does not.
2) Even on writable shares, clients without FILEWRITEDATA or FILEWRITEATTRIBUTES access should not modify the sparse attribute. Similar handle-level checks exist in other functions but are missing here.
Add both share-level writable check and per-handle access check. Use goto out on error to avoid leaking file references.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free from async crypto on Qualcomm crypto engine
ksmbdcryptmessage() sets a NULL completion callback on AEAD requests and does not handle the -EINPROGRESS return code from async hardware crypto engines like the Qualcomm Crypto Engine (QCE). When QCE returns -EINPROGRESS, ksmbd treats it as an error and immediately frees the request while the hardware DMA operation is still in flight. The DMA completion callback then dereferences freed memory, causing a NULL pointer crash:
pc : qceskcipherdone+0x24/0x174 lr : vchancomplete+0x230/0x27c ... el1h64irq+0x68/0x6c ksmbdfreeworkstruct+0x20/0x118 [ksmbd] ksmbdexitfilecache+0x694/0xa4c [ksmbd]
Use the standard cryptowaitreq() pattern with cryptoreqdone() as the completion callback, matching the approach used by the SMB client in fs/smb/client/smb2ops.c. This properly handles both synchronous engines (immediate return) and async engines (-EINPROGRESS followed by callback notification).
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: use opener credentials for ADS I/O
Alternate data streams are stored as xattrs. Unlike regular file I/O, their read and write paths therefore call VFS xattr helpers which recheck inode permissions and LSM policy using the current task credentials.
Run ADS I/O with the credentials captured when the SMB handle was opened.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: serialize QUERYDIRECTORY requests per file
smb2querydir() stores a pointer to its stack-allocated private data in the ksmbdfile readdirdata. Concurrent QUERYDIRECTORY requests using the same file handle can overwrite this pointer while an iteratedir() callback is still using it, resulting in a stack use-after-free.
Add a per-file mutex and hold it while accessing the shared directory enumeration state. The lock covers scan restart, dot entry state, readdirdata setup and iteration, and response construction. This prevents another request from replacing readdirdata.private before the current request has finished using it and also serializes the shared file position.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add permission checks for FSCTLDUPLICATEEXTENTSTOFILE
The FSCTLDUPLICATEEXTENTSTOFILE arm of smb2ioctl() overwrites the destination file's data via vfsclonefilerange() with neither the share-level KSMBDTREECONNFLAGWRITABLE check nor a per-handle fp->daccess check that the other write-bearing arms carry. A client can overwrite destination data on a read-only share, or from a handle opened with only FILEWRITEATTRIBUTES (which still yields an FMODEWRITE filp). FILEWRITEATTRIBUTES-only destination handle overwrote the file's data via the clone. Add both checks, matching the FSCTLSETSPARSE permission fix; require FILEWRITEDATA since this writes data.
An issue was discovered in the Linux kernel before 6.3.4. fs/ksmbd/connection.c in ksmbd has an off-by-one error in memory allocation (because of ksmbdsmb2checkmessage) that may lead to out-of-bounds access.
An issue was discovered in the Linux kernel before 6.3.8. fs/smb/server/smb2pdu.c in ksmbd has an integer underflow and out-of-bounds read in deassemblenegcontexts.
A flaw was found in the Linux kernel's ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2TREEDISCONNECT commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.
In the Linux kernel, the following vulnerability has been resolved:
mptcp: plug races between subflow fail and subflow creation
We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger.
The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock.
The socket fallback makes such flag true, and also receiving or sending an MPFAIL option.
The field 'allowinfinitefallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: smbdirect: validate dataoffset and datalength field of smbdirectdatatransfer
If dataoffset and datalength of smbdirectdatatransfer struct are invalid, out of bounds issue could happen. This patch validate dataoffset and datalength field in recvdone.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate session id and tree id in compound request
smb2getmsg() in smb2getksmbdtcon() and smb2checkusersession() will always return the first request smb2 header in a compound request. if SMB2TREECONNECTHE is the first command in compound request, will return 0, i.e. The tree id check is skipped. This patch use ksmbdreqbufnext() to get current command in compound.
In the Linux kernel, the following vulnerability has been resolved:
isofs: Fix out of bound access for corrupted isofs image
When isofs image is suitably corrupted isofsreadinode() can read data beyond the end of buffer. Sanity-check the directory entry length before using it.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: not allow guest user on multichannel
This patch return STATUSNOTSUPPORTED if binding session is guest.