Where
AND
AND
-Infinity
0
Severity
9.3
Buffer Overflow
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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)

1 / 3
Source: MITRE
First published (updated )
Severity
9.2
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

ksmbd: Compare MACs in constant time

To prevent timing attacks, MAC comparisons need to be constant-time. Replace the memcmp() with the correct function, cryptomemneq().

1 / 4
Source: NVD
First published (updated )
Severity
9.2
Use After Free, Race Condition
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H

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

skbuff: Fix a race between coalescing and releasing SKBs

Commit 1effe8ca4e34 ("skbuff: fix coalescing for pagepool fragment recycling") allowed coalescing to proceed with non page pool page and page pool page when @from is cloned, i.e.

to->pprecycle --> false from->pprecycle --> true skbcloned(from) --> true

However, it actually requires skbcloned(@from) to hold true until coalescing finishes in this situation. If the other cloned SKB is released while the merging is in process, fromshinfo->nrfrags will be set to 0 toward the end of the function, causing the increment of frag page refcount to be unexpectedly skipped resulting in inconsistent reference counts. Later when SKB(@to) is released, it frees the page directly even though the page pool page is still in use, leading to use-after-free or double-free errors. So it should be prohibited.

The double-free error message below prompted us to investigate: BUG: Bad page state in process swapper/1 pfn:0e0d1 page:00000000c6548b28 refcount:-1 mapcount:0 mapping:0000000000000000 index:0x2 pfn:0xe0d1 flags: 0xfffffc0000000(node=0|zone=1|lastcpupid=0x1fffff) raw: 000fffffc0000000 0000000000000000 ffffffff00000101 0000000000000000 raw: 0000000000000002 0000000000000000 ffffffffffffffff 0000000000000000 page dumped because: nonzero refcount

CPU: 1 PID: 0 Comm: swapper/1 Tainted: G E 6.2.0+ Call Trace: <IRQ> dumpstacklvl+0x32/0x50 badpage+0x69/0xf0 freepcpprepare+0x260/0x2f0 freeunrefpage+0x20/0x1c0 skbreleasedata+0x10b/0x1a0 napiconsumeskb+0x56/0x150 netrxaction+0xf0/0x350 ? napischedule+0x79/0x90 dosoftirq+0xc8/0x2b1 irqexitrcu+0xb9/0xf0 commoninterrupt+0x82/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x22/0x40 RIP: 0010:defaultidle+0xb/0x20

1 / 2
Source: Red Hat
First published (updated )
Severity
9.8
Race Condition
AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H

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.

1 / 3
Source: NVD
First published (updated )
Severity
9.1
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

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.

1 / 2
Source: MITRE
First published (updated )
Severity
9.2
EPSS
0.02%
Use After Free
AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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

ksmbd: fix use-after-free in smb2leasebreaknoti()

Move tcptransport free to ksmbdconnfree. If ksmbd connection is referenced when ksmbd server thread terminates, It will not be freed, but conn->tcptransport is freed. smb2leasebreaknoti can be performed asynchronously when the connection is disconnected. smb2leasebreaknoti calls ksmbdconnwrite, which can cause use-after-free when conn->ksmbdtransport is already freed.

1 / 3
Source: NVD
First published (updated )
Severity
9.8
Use After Free
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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

1 / 2
Source: NVD
First published (updated )
Severity
9.8
Use After Free, Null Pointer Dereference, Race Condition
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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---

1 / 2
Source: NVD
First published (updated )
Severity
9.8
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 2
Source: NVD
First published (updated )
Severity
9.3
AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

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

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

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

1 / 5
Source: NVD
First published (updated )
Severity
9.8
EPSS
0.01%
Race Condition
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

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.

1 / 4
Source: MITRE
First published (updated )
Severity
9.1
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H

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.

1 / 4
Source: MITRE
First published (updated )
Severity
9.2
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

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.

1 / 2
First published (updated )
Severity
9.8
Use After Free
AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. fs/ksmbd/smb2pdu.c has a use-after-free and OOPS for SMB2TREEDISCONNECT.

1 / 2
First published (updated )
Severity
9.8
Infoleak
AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N

A flaw in netfilter could allow a network-connected attacker to infer openvpn connection endpoint information for further use in traditional network attacks.

1 / 2
First published (updated )

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203