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:
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:
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 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.
A flaw in netfilter could allow a network-connected attacker to infer openvpn connection endpoint information for further use in traditional network attacks.
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.
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.
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:
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.
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
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().
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.
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:
ksmbd: not allow guest user on multichannel
This patch return STATUSNOTSUPPORTED if binding session is guest.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate request buffer size in smb2allocaterspbuf()
The response buffer should be allocated in smb2allocaterspbuf before validating request. But the fields in payload as well as smb2 header is used in smb2allocaterspbuf(). This patch add simple buffer size validation to avoid potencial out-of-bounds in request buffer.
In the Linux kernel, the following vulnerability has been resolved:
vdpa/mlx5: add validation for VIRTIONETCTRLMQVQPAIRSSET command
When control vq receives a VIRTIONETCTRLMQVQPAIRSSET command request from the driver, presently there is no validation against the number of queue pairs to configure, or even if multiqueue had been negotiated or not is unverified. This may lead to kernel panic due to uninitialized resource for the queues were there any bogus request sent down by untrusted driver. Tie up the loose ends there.
In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: fix use-after-free in hsci
KASAN found that addr was dereferenced after br2deveventwork was freed.
================================================================== BUG: KASAN: use-after-free in qethl2br2devworker+0x5ba/0x6b0 Read of size 1 at addr 00000000fdcea440 by task kworker/u760:4/540 CPU: 17 PID: 540 Comm: kworker/u760:4 Tainted: G E 6.1.0-20221128.rc7.git1.5aa3bed4ce83.300.fc36.s390x+kasan #1 Hardware name: IBM 8561 T01 703 (LPAR) Workqueue: 0.0.8000event qethl2br2devworker Call Trace: [<000000016944d4ce>] dumpstacklvl+0xc6/0xf8 [<000000016942cd9c>] printaddressdescription.constprop.0+0x34/0x2a0 [<000000016942d118>] printreport+0x110/0x1f8 [<0000000167a7bd04>] kasanreport+0xfc/0x128 [<000000016938d79a>] qethl2br2devworker+0x5ba/0x6b0 [<00000001673edd1e>] processonework+0x76e/0x1128 [<00000001673ee85c>] workerthread+0x184/0x1098 [<000000016740718a>] kthread+0x26a/0x310 [<00000001672c606a>] retfromfork+0x8a/0xe8 [<00000001694711da>] retfromfork+0xa/0x40 Allocated by task 108338: kasansavestack+0x40/0x68 kasansettrack+0x36/0x48 kasankmalloc+0xa0/0xc0 qethl2switchdevevent+0x25a/0x738 atomicnotifiercallchain+0x9c/0xf8 brswitchdevfdbnotify+0xf4/0x110 fdbnotify+0x122/0x180 fdbaddentry.constprop.0.isra.0+0x312/0x558 brfdbadd+0x59e/0x858 rtnlfdbadd+0x58a/0x928 rtnetlinkrcvmsg+0x5f8/0x8d8 netlinkrcvskb+0x1f2/0x408 netlinkunicast+0x570/0x790 netlinksendmsg+0x752/0xbe0 socksendmsg+0xca/0x110 syssendmsg+0x510/0x6a8 syssendmsg+0x12a/0x180 syssendmsg+0xe6/0x168 dosyssocketcall+0x3c8/0x468 dosyscall+0x22c/0x328 dosyscall+0x94/0xf0 systemcall+0x82/0xb0 Freed by task 540: kasansavestack+0x40/0x68 kasansettrack+0x36/0x48 kasansavefreeinfo+0x4c/0x68 kasanslabfree+0x14e/0x1a8 kasanslabfree+0x24/0x30 kmemcachefree+0x168/0x338 qethl2br2devworker+0x154/0x6b0 processonework+0x76e/0x1128 workerthread+0x184/0x1098 kthread+0x26a/0x310 retfromfork+0x8a/0xe8 retfromfork+0xa/0x40 Last potentially related work creation: kasansavestack+0x40/0x68 kasanrecordauxstack+0xbe/0xd0 insertwork+0x56/0x2e8 queuework+0x4ce/0xd10 queueworkon+0xf4/0x100 qethl2switchdevevent+0x520/0x738 atomicnotifiercallchain+0x9c/0xf8 brswitchdevfdbnotify+0xf4/0x110 fdbnotify+0x122/0x180 fdbaddentry.constprop.0.isra.0+0x312/0x558 brfdbadd+0x59e/0x858 rtnlfdbadd+0x58a/0x928 rtnetlinkrcvmsg+0x5f8/0x8d8 netlinkrcvskb+0x1f2/0x408 netlinkunicast+0x570/0x790 netlinksendmsg+0x752/0xbe0 socksendmsg+0xca/0x110 syssendmsg+0x510/0x6a8 syssendmsg+0x12a/0x180 syssendmsg+0xe6/0x168 dosyssocketcall+0x3c8/0x468 dosyscall+0x22c/0x328 dosyscall+0x94/0xf0 systemcall+0x82/0xb0 Second to last potentially related work creation: kasansavestack+0x40/0x68 kasanrecordauxstack+0xbe/0xd0 kvfreecallrcu+0xb2/0x760 kernfsunlinkopenfile+0x348/0x430 kernfsfoprelease+0xc2/0x320 fput+0x1ae/0x768 taskworkrun+0x1bc/0x298 exittousermodeprepare+0x1a0/0x1a8 dosyscall+0x94/0xf0 systemcall+0x82/0xb0 The buggy address belongs to the object at 00000000fdcea400 which belongs to the cache kmalloc-96 of size 96 The buggy address is located 64 bytes inside of 96-byte region [00000000fdcea400, 00000000fdcea460) The buggy address belongs to the physical page: page:000000005a9c26e8 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0xfdcea flags: 0x3ffff00000000200(slab|node=0|zone=1|lastcpupid=0x1ffff) raw: 3ffff00000000200 0000000000000000 0000000100000122 000000008008cc00 raw: 0000000000000000 0020004100000000 ffffffff00000001 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: 00000000fdcea300: fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc fc 00000000fdcea380: fb fb fb fb fb fb f ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Implement ref count for SRB
The timeout handler and the done function are racing. When qla2x00asynciocbtimeout() starts to run it can be preempted by the normal response path (via the firmware?). qla24xxasyncgpscspdone() releases the SRB unconditionally. When scheduling back to qla2x00asynciocbtimeout() qla24xxasyncabortcmd() will access an freed sp->qpair pointer:
qla2xxx [0000:83:00.0]-2871:0: Async-gpsc timeout - hdl=63d portid=234500 50:06:0e:80:08:77:b6:21. qla2xxx [0000:83:00.0]-2853:0: Async done-gpsc res 0, WWPN 50:06:0e:80:08:77:b6:21 qla2xxx [0000:83:00.0]-2854:0: Async-gpsc OUT WWPN 20:45:00:27:f8:75:33:00 speeds=2c00 speed=0400. qla2xxx [0000:83:00.0]-28d8:0: qla24xxhandlegpscevent 50:06:0e:80:08:77:b6:21 DS 7 LS 6 rc 0 login 1|1 rscn 1|0 lid 5 BUG: unable to handle kernel NULL pointer dereference at 0000000000000004 IP: qla24xxasyncabortcmd+0x1b/0x1c0 [qla2xxx]
Obvious solution to this is to introduce a reference counter. One reference is taken for the normal code path (the 'good' case) and one for the timeout path. As we always race between the normal good case and the timeout/abort handler we need to serialize it. Also we cannot assume any order between the handlers. Since this is slow path we can use proper synchronization via locks.
When we are able to cancel a timer (deltimer returns 1) we know there can't be any error handling in progress because the timeout handler hasn't expired yet, thus we can safely decrement the refcounter by one.
If we are not able to cancel the timer, we know an abort handler is running. We have to make sure we call sp->done() in the abort handlers before calling krefput().
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: IOMMU incorrectly marks MMIO range in DDW
Power Hypervisor can possibily allocate MMIO window intersecting with Dynamic DMA Window (DDW) range, which is over 32-bit addressing.
These MMIO pages needs to be marked as reserved so that IOMMU doesn't map DMA buffers in this range.
The current code is not marking these pages correctly which is resulting in LPAR to OOPS while booting. The stack is at below
BUG: Unable to handle kernel data access on read at 0xc00800005cd40000 Faulting instruction address: 0xc00000000005cdac Oops: Kernel access of bad area, sig: 11 [#1] LE PAGESIZE=64K MMU=Hash SMP NRCPUS=2048 NUMA pSeries Modules linked in: afpacket rfkill ibmveth(X) lpfc(+) nvmetfc nvmet nvmekeyring crct10difvpmsum nvmefc nvmefabrics nvmecore be2net(+) nvmeauth rtcgeneric nfsd authrpcgss nfsacl lockd grace sunrpc fuse configfs iptables xtables xfs libcrc32c dmservicetime ibmvfc(X) scsitransportfc vmxcrypto gf128mul crc32cvpmsum dmmirror dmregionhash dmlog dmmultipath dmmod sdmod scsidhemc scsidhrdac scsidhalua t10pi crc64rocksoftgeneric crc64rocksoft sg crc64 scsimod Supported: Yes, External CPU: 8 PID: 241 Comm: kworker/8:1 Kdump: loaded Not tainted 6.4.0-150600.23.14-default #1 SLE15-SP6 b44ee71c81261b9e4bab5e0cde1f2ed891d5359b Hardware name: IBM,9080-M9S POWER9 (raw) 0x4e2103 0xf000005 of:IBM,FW950.B0 (VH950149) hv:phyp pSeries Workqueue: events workforcpufn NIP: c00000000005cdac LR: c00000000005e830 CTR: 0000000000000000 REGS: c00001400c9ff770 TRAP: 0300 Not tainted (6.4.0-150600.23.14-default) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24228448 XER: 00000001 CFAR: c00000000005cdd4 DAR: c00800005cd40000 DSISR: 40000000 IRQMASK: 0 GPR00: c00000000005e830 c00001400c9ffa10 c000000001987d00 c00001400c4fe800 GPR04: 0000080000000000 0000000000000001 0000000004000000 0000000000800000 GPR08: 0000000004000000 0000000000000001 c00800005cd40000 ffffffffffffffff GPR12: 0000000084228882 c00000000a4c4f00 0000000000000010 0000080000000000 GPR16: c00001400c4fe800 0000000004000000 0800000000000000 c00000006088b800 GPR20: c00001401a7be980 c00001400eff3800 c000000002a2da68 000000000000002b GPR24: c0000000026793a8 c000000002679368 000000000000002a c0000000026793c8 GPR28: 000008007effffff 0000080000000000 0000000000800000 c00001400c4fe800 NIP [c00000000005cdac] iommutablereservepages+0xac/0x100 LR [c00000000005e830] iommuinittable+0x80/0x1e0 Call Trace: [c00001400c9ffa10] [c00000000005e810] iommuinittable+0x60/0x1e0 (unreliable) [c00001400c9ffa90] [c00000000010356c] iommubypasssupportedpSeriesLP+0x9cc/0xe40 [c00001400c9ffc30] [c00000000005c300] dmaiommudmasupported+0xf0/0x230 [c00001400c9ffcb0] [c00000000024b0c4] dmasupported+0x44/0x90 [c00001400c9ffcd0] [c00000000024b14c] dmasetmask+0x3c/0x80 [c00001400c9ffd00] [c0080000555b715c] beprobe+0xc4/0xb90 [be2net] [c00001400c9ffdc0] [c000000000986f3c] localpciprobe+0x6c/0x110 [c00001400c9ffe40] [c000000000188f28] workforcpufn+0x38/0x60 [c00001400c9ffe70] [c00000000018e454] processonework+0x314/0x620 [c00001400c9fff10] [c00000000018f280] workerthread+0x2b0/0x620 [c00001400c9fff90] [c00000000019bb18] kthread+0x148/0x150 [c00001400c9fffe0] [c00000000000ded8] startkernelthread+0x14/0x18
There are 2 issues in the code
1. The index is "int" while the address is "unsigned long". This results in negative value when setting the bitmap.
2. The DMA offset is page shifted but the MMIO range is used as-is (64-bit address). MMIO address needs to be page shifted as well.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix out-of-bounds in parsesecdesc()
If osidoffset, gsidoffset and dacloffset could be greater than smbntsd struct size. If it is smaller, It could cause slab-out-of-bounds. And when validating sid, It need to check it included subauth array size.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: add bounds check for durable handle context
Add missing bounds check for durable handle context.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix use-after-free in session logoff
The sess->user object can currently be in use by another thread, for example if another connection has sent a session setup request to bind to the session being free'd. The handler for that connection could be in the smb2sesssetup function which makes use of sess->user.
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.
bpf: Fix stack-out-of-bounds write in devmap
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:
drm/msm: Fix iommumapsgtable() return value check and avoid WARN
Commit "iommu: return full error code from iommumapsgatomic" changed iommumapsgtable() to return an ssizet and negative values in error cases, rather than a sizet and a zero.
Store the return value in the appropriate type and in case of error, return it rather than WARNing.
Patchwork: https://patchwork.freedesktop.org/patch/719685/
An issue was discovered in the Linux kernel before 6.3.10. fs/smb/server/smb2misc.c in ksmbd does not validate the relationship between the command payload size and the RFC1002 length specification, leading to an out-of-bounds read.
An issue was discovered in the Linux kernel before 6.3.9. ksmbd does not validate the SMB request protocol ID, leading to an out-of-bounds read.
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.