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

eventpoll: don't decrement ep refcount while still holding the ep mutex

Jann Horn points out that epoll is decrementing the ep refcount and then doing a

mutexunlock(&ep->mtx);

afterwards. That's very wrong, because it can lead to a use-after-free.

That pattern is actually fine for the very last reference, because the code in question will delay the actual call to "epfree(ep)" until after it has unlocked the mutex.

But it's wrong for the much subtler "next to last" case when somebody else may also be dropping their reference and free the ep while we're still using the mutex.

Note that this is true even if that other user is also using the same ep mutex: mutexes, unlike spinlocks, can not be used for object ownership, even if they guarantee mutual exclusion.

A mutex "unlock" operation is not atomic, and as one user is still accessing the mutex as part of unlocking it, another user can come in and get the now released mutex and free the data structure while the first user is still cleaning up.

See our mutex documentation in Documentation/locking/mutex-design.rst, in particular the section [1] about semantics:

"mutexunlock() may access the mutex structure even after it has internally released the lock already - so it's not safe for another context to acquire the mutex and assume that the mutexunlock() context is not using the structure anymore"

So if we drop our ep ref before the mutex unlock, but we weren't the last one, we may then unlock the mutex, another user comes in, drops their reference and releases the 'ep' as it now has no users - all while the mutexunlock() is still accessing it.

Fix this by simply moving the ep refcount dropping to outside the mutex: the refcount itself is atomic, and doesn't need mutex protection (that's the whole point of refcounts: unlike mutexes, they are inherently about object lifetimes).

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

net/smc: check smcdv2extoffset when receiving proposal msg

When receiving proposal msg in server, the field smcdv2extoffset in proposal msg is from the remote client and can not be fully trusted. Once the value of smcdv2extoffset exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the value of smcdv2extoffset before using it.

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

net/smc: check v2extoffset/eidcnt/ismgidcnt when receiving proposal msg

When receiving proposal msg in server, the fields v2extoffset/ eidcnt/ismgidcnt in proposal msg are from the remote client and can not be fully trusted. Especially the field v2extoffset, once exceed the max value, there has the chance to access wrong address, and crash may happen.

This patch checks the fields v2extoffset/eidcnt/ismgidcnt before using them.

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

scsi: hisisas: Grab sasdev lock when traversing the members of sasdev.list

When freeing slots in function slotcompletev3hw(), it is possible that sasdev.list is being traversed elsewhere, and it may trigger a NULL pointer exception, such as follows:

==>cq thread ==>scsieh6

==>scsierrorhandler() ==>sasehhandlesaserrors() ==>sasscsifindtask() ==>llddaborttask() ==>slotcompletev3hw() ==>hisisasaborttask() ==>hisisasslottaskfree() ==>deregdevicev3hw() ==>listdelinit() ==>listforeachentrysafe()

[ 7165.434918] sas: Enter sasscsirecoverhost busy: 32 failed: 32 [ 7165.434926] sas: trying to find task 0x00000000769b5ba5 [ 7165.434927] sas: sasscsifindtask: aborting task 0x00000000769b5ba5 [ 7165.434940] hisisasv3hw 0000:b4:02.0: slot complete: task(00000000769b5ba5) aborted [ 7165.434964] hisisasv3hw 0000:b4:02.0: slot complete: task(00000000c9f7aa07) ignored [ 7165.434965] hisisasv3hw 0000:b4:02.0: slot complete: task(00000000e2a1cf01) ignored [ 7165.434968] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 7165.434972] hisisasv3hw 0000:b4:02.0: slot complete: task(0000000022d52d93) ignored [ 7165.434975] hisisasv3hw 0000:b4:02.0: slot complete: task(0000000066a7516c) ignored [ 7165.434976] Mem abort info: [ 7165.434982] ESR = 0x96000004 [ 7165.434991] Exception class = DABT (current EL), IL = 32 bits [ 7165.434992] SET = 0, FnV = 0 [ 7165.434993] EA = 0, S1PTW = 0 [ 7165.434994] Data abort info: [ 7165.434994] ISV = 0, ISS = 0x00000004 [ 7165.434995] CM = 0, WnR = 0 [ 7165.434997] user pgtable: 4k pages, 48-bit VAs, pgdp = 00000000f29543f2 [ 7165.434998] [0000000000000000] pgd=0000000000000000 [ 7165.435003] Internal error: Oops: 96000004 [#1] SMP [ 7165.439863] Process scsieh6 (pid: 4109, stack limit = 0x00000000c43818d5) [ 7165.468862] pstate: 00c00009 (nzcv daif +PAN +UAO) [ 7165.473637] pc : deregdevicev3hw+0x68/0xa8 [hisisasv3hw] [ 7165.479443] lr : deregdevicev3hw+0x2c/0xa8 [hisisasv3hw] [ 7165.485247] sp : ffff00001d623bc0 [ 7165.488546] x29: ffff00001d623bc0 x28: ffffa027d03b9508 [ 7165.493835] x27: ffff80278ed50af0 x26: ffffa027dd31e0a8 [ 7165.499123] x25: ffffa027d9b27f88 x24: ffffa027d9b209f8 [ 7165.504411] x23: ffffa027c45b0d60 x22: ffff80278ec07c00 [ 7165.509700] x21: 0000000000000008 x20: ffffa027d9b209f8 [ 7165.514988] x19: ffffa027d9b27f88 x18: ffffffffffffffff [ 7165.520276] x17: 0000000000000000 x16: 0000000000000000 [ 7165.525564] x15: ffff0000091d9708 x14: ffff0000093b7dc8 [ 7165.530852] x13: ffff0000093b7a23 x12: 6e7265746e692067 [ 7165.536140] x11: 0000000000000000 x10: 0000000000000bb0 [ 7165.541429] x9 : ffff00001d6238f0 x8 : ffffa027d877af00 [ 7165.546718] x7 : ffffa027d6329600 x6 : ffff7e809f58ca00 [ 7165.552006] x5 : 0000000000001f8a x4 : 000000000000088e [ 7165.557295] x3 : ffffa027d9b27fa8 x2 : 0000000000000000 [ 7165.562583] x1 : 0000000000000000 x0 : 000000003000188e [ 7165.567872] Call trace: [ 7165.570309] deregdevicev3hw+0x68/0xa8 [hisisasv3hw] [ 7165.575775] hisisasaborttask+0x248/0x358 [hisisasmain] [ 7165.581415] sasehhandlesaserrors+0x258/0x8e0 [libsas] [ 7165.586876] sasscsirecoverhost+0x134/0x458 [libsas] [ 7165.592082] scsierrorhandler+0xb4/0x488 [ 7165.596163] kthread+0x134/0x138 [ 7165.599380] retfromfork+0x10/0x18 [ 7165.602940] Code: d5033e9f b9000040 aa0103e2 eb03003f (f9400021) [ 7165.609004] kernel fault(0x1) notification starting on CPU 75 [ 7165.700728] ---[ end trace fc042cbbea224efc ]--- [ 7165.705326] Kernel panic - not syncing: Fatal exception

To fix the issue, grab sasdev lock when traversing the members of sasdev.list in deregdevicev3hw() and hisisasreleasetasks() to avoid concurrency of adding and deleting member. When ---truncated---

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

btrfs: don't check PageError in extentwritepage

extentwritepage currenly sets PageError whenever any error happens, and the also checks for PageError to decide if to call error handling. This leads to very unclear responsibility for cleaning up on errors. In the VM and generic writeback helpers the basic idea is that once I/O is fired off all error handling responsibility is delegated to the end I/O handler. But if that end I/O handler sets the PageError bit, and the submitter checks it, the bit could in some cases leak into the submission context for fast enough I/O.

Fix this by simply not checking PageError and just using the local ret variable to check for submission errors. This also fundamentally solves the long problem documented in a comment in extentwritepage by never leaking the error bit into the submission context.

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

iomap: iomap: fix memory corruption when recording errors during writeback

Every now and then I see this crash on arm64:

Unable to handle kernel NULL pointer dereference at virtual address 00000000000000f8 Buffer I/O error on dev dm-0, logical block 8733687, async page read Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x06: level 2 translation fault Data abort info: ISV = 0, ISS = 0x00000006 CM = 0, WnR = 0 user pgtable: 64k pages, 42-bit VAs, pgdp=0000000139750000 [00000000000000f8] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000, pmd=0000000000000000 Internal error: Oops: 96000006 [#1] PREEMPT SMP Buffer I/O error on dev dm-0, logical block 8733688, async page read Dumping ftrace buffer: Buffer I/O error on dev dm-0, logical block 8733689, async page read (ftrace buffer empty) XFS (dm-0): log I/O error -5 Modules linked in: dmthinpool dmpersistentdata XFS (dm-0): Metadata I/O Error (0x1) detected at xfstransreadbufmap+0x1ec/0x590 [xfs] (fs/xfs/xfstransbuf.c:296). dmbioprison XFS (dm-0): Please unmount the filesystem and rectify the problem(s) XFS (dm-0): xfsimaplookup: xfsiallocreadagi() returned error -5, agno 0 dmbufio dmlogwrites xfs nftchainnat xtREDIRECT nfnat nfconntrack nfdefragipv6 nfdefragipv4 ip6tREJECT potentially unexpected fatal signal 6. nfrejectipv6 potentially unexpected fatal signal 6. iptREJECT nfrejectipv4 CPU: 1 PID: 122166 Comm: fsstress Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7 rpcsecgsskrb5 authrpcgss xttcpudp ipsethaship ipsethashnet xtset nftcompat ipsethashmac ipset nftables Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 pstate: 60001000 (nZCv daif -PAN -UAO -TCO -DIT +SSBS BTYPE=--) iptables pc : 000003fd6d7df200 xtables lr : 000003fd6d7df1ec overlay nfsv4 CPU: 0 PID: 54031 Comm: u4:3 Tainted: G W 6.0.0-rc5-djwa #rc5 3004c9f1de887ebae86015f2677638ce51ee7405 Hardware name: QEMU KVM Virtual Machine, BIOS 1.5.1 06/16/2021 Workqueue: writeback wbworkfn sp : 000003ffd9522fd0 (flush-253:0) pstate: 60401005 (nZCv daif +PAN -UAO -TCO -DIT +SSBS BTYPE=--) pc : errseqset+0x1c/0x100 x29: 000003ffd9522fd0 x28: 0000000000000023 x27: 000002acefeb6780 x26: 0000000000000005 x25: 0000000000000001 x24: 0000000000000000 x23: 00000000ffffffff x22: 0000000000000005 lr : filemapsetwberr+0x24/0xe0 x21: 0000000000000006 sp : fffffe000f80f760 x29: fffffe000f80f760 x28: 0000000000000003 x27: fffffe000f80f9f8 x26: 0000000002523000 x25: 00000000fffffffb x24: fffffe000f80f868 x23: fffffe000f80fbb0 x22: fffffc0180c26a78 x21: 0000000002530000 x20: 0000000000000000 x19: 0000000000000000 x18: 0000000000000000

x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000001 x13: 0000000000470af3 x12: fffffc0058f70000 x11: 0000000000000040 x10: 0000000000001b20 x9 : fffffe000836b288 x8 : fffffc00eb9fd480 x7 : 0000000000f83659 x6 : 0000000000000000 x5 : 0000000000000869 x4 : 0000000000000005 x3 : 00000000000000f8 x20: 000003fd6d740020 x19: 000000000001dd36 x18: 0000000000000001 x17: 000003fd6d78704c x16: 0000000000000001 x15: 000002acfac87668 x2 : 0000000000000ffa x1 : 00000000fffffffb x0 : 00000000000000f8 Call trace: errseqset+0x1c/0x100 filemapsetwberr+0x24/0xe0 iomapdowritepage+0x5e4/0xd5c writecachepages+0x208/0x674 iomapwritepages+0x34/0x60 xfsvmwritepages+0x8c/0xcc [xfs 7a861f39c43631f15d3a5884246ba5035d4ca78b] x14: 0000000000000000 x13: 2064656e72757465 x12: 0000000000002180 x11: 000003fd6d8a82d0 x10: 0000000000000000 x9 : 000003fd6d8ae288 x8 : 0000000000000083 x7 : 00000000ffffffff x6 : 00000000ffffffee x5 : 00000000fbad2887 x4 : 000003fd6d9abb58 x3 : 000003fd6d740020 x2 : 0000000000000006 x1 : 000000000001dd36 x0 : 0000000000000000 CPU: ---truncated---

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

usb: storage: realtekcr: fix use-after-free on disconnect

realtekcrdestructor() calls timerdelete() before the chip containing the timer is freed. The timer callback may still be running and can rearm itself, resulting in a use-after-free.

Use timershutdownsync() to wait for the callback and prevent further rearming. Do this unconditionally because ssen may be changed after the timer is armed.

Move timersetup() into initrealtekcr() so the timer is initialized before any failure path can invoke the destructor.

Found by static analysis.

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

staging: rtl8723bs: fix OOB read in rtwrestructwmmie()

rtwrestructwmmie() scans inie for a WMM IE with:

while (i < inlen) { ... if (i + 5 < inlen && inie[i] == 0xDD && ...) { ... break; } i += (inie[i + 1] + 2); / to the next IE element / }

When the "i + 5 < inlen" match check fails simply because i is within 5 bytes of the end of the buffer (i.e. no WMM IE was found near the tail of inie), execution falls through to "i += (inie[i + 1] + 2)", which reads inie[i + 1]. If i == inlen - 1 at that point, this is a 1-byte out-of-bounds read of an attacker-influenced IE buffer built from association/scan data.

Commit a75281626fc8f ("staging: rtl8723bs: fix potential out-of-bounds read in rtwrestructwmmie") added the "i + 5 < inlen" guard to the match condition itself, but did not add an equivalent guard before the fallthrough advance, so the same class of OOB read remained reachable through the non-matching path.

Add an explicit bounds check before advancing to the next IE.

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

nvme: skip the zoned limits update if the zone info query failed

nvmequeryzoneinfo() returns either a negative errno or a positive NVMe status code, but nvmeupdatensinfoblock() only tests for the negative case:

ret = nvmequeryzoneinfo(ns, lbaf, &zi); if (ret < 0) goto out;

If the device fails the Identify Namespace (I/O Command Set specific) command, or the Identify Controller command issued by nvmesetmaxappend(), the positive status falls through and setup continues with the zero-initialized zone info. nvmeupdatezoneinfo() then marks the queue zoned with chunksectors and ns->head->zsze set to zero.

blkvalidatezonedlimits() does not check chunksectors, so the limits commit succeeds. blkrevalidatediskzones() does reject the zero zone size, but by then the limits are live and nothing rolls them back, so I/O keeps being submitted to a zoned queue with a zero zone size and diskzoneno() shifts by ilog2(0):

nvme0n1: Invalid non power of two zone size (0) UBSAN: shift-out-of-bounds in include/linux/blkdev.h:747:16 shift exponent -1 is negative diskzoneno include/linux/blkdev.h:747 [inline] biostraddleszones include/linux/blkdev.h:1058 [inline] blkzonewplughandlewrite block/blk-zoned.c:1423 [inline] blkzoneplugbio.cold+0x25/0x1c8 block/blk-zoned.c:1605 blkmqsubmitbio+0x18fb/0x2870 block/blk-mq.c:3196 submitbhwbc+0x575/0x740 fs/buffer.c:2824 blockwritefullfolio+0x728/0xdd0 fs/buffer.c:1933

Any device, firmware or NVMe-oF target that fails this one command reaches this.

Skip the zoned limits update in that case, and log which of the two things happened: during a revalidation the queue keeps the zone geometry it was last validated with, and on a first scan the namespace is registered without zoned limits, so that it is still available as a handle for admin commands. Neither of the paths in nvmequeryzoneinfo() that return a positive status logs anything, so the failure would otherwise be silent.

zi.zonesize is an exact indicator: every path that returns a positive status returns before it is assigned, and after that the only failure left is -ENODEV, which the caller already handles.

Found by FuzzNvme.

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

KVM: s390: Zero initialize data structures for injectpfaulttoken

kvminjectpfaulttoken() only sets .type and .u.ext.extparams2 of the on-stack struct kvms390irq but the full ext substructure is copied into the cpu local variable on inject. extparams and pad contain stale stack values.

Interrupt delivery only uses extparams2, so nothing leaks to the guest, but a host user can use the migration ioctls to get to the data.

Fix by zero-initializing the irq struct. Do the same for the inti data structure.

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

media: chips-media: wave5: Add timeout while stopstreaming

When stopstreaming is called, an infinite loop may occur in some cases. Add a bounded poll of the queue status: loop until the queues drain, sleeping briefly between polls, and bail out once VPUDECSTOPTIMEOUT elapses.

f2fs: fix dentry folio leak in findinlevel

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

mm/damon/core: avoid infinite kdamondmergeregions() internal loop

Patch series "mm/damon: unurgent fixes for infinite loop, NULL de-ref and races", v1.1.

Sashiko found a few issues in DAMON that could cause infinite loop, NULL dereference and monitoring results degradation. The first two sounds scary but the infinite loop happens only under unreasonable user setup. The NULL dereference is only in a unit test. Monitoring results degradation is trivial since it is only best-effort, and those happens from only unlikely races. Still those are bugs that better to fix if possible. Fix those.

This patch (of 6):

Due to online parameter update like events, the number of DAMON regions could be higher than the user-set upper limit. kdamondmergeregions() repeats merge regions until the number meets the limit, while doubling the merge threshold up to the theoretical maximum threshold. It is tried only up to the theoretical maximum threshold because even the aggressive merging can fail from reducing the number of regions under the user-defined upper limit. For example, there could be many user-defined non-contiguous regions that cannot be merged.

The threshold based loop break condition is evaluated by comparing the threshold for the next merging try against the theoretical maximum threshold. If maxthres is larger than UINTMAX / 2, doubling the threshold could make it overflow, and bypass the loop break condition. In the case, if the number of regions cannot be reduced under the upper limit like explained above, the loop will run infinitely.

Prevent the case by doing the break condition check before doubling the threshold. Also, prevent the threshold exceeding the maximum threshold, as it could overflow and apply the wrong merge threshold.

This issue is unlikely to occur in real world, since having the maxthres higher than UINTMAX / 2 require unrealistically large aggregation intervals compared to the sampling interval. Also, it requires an unrealistically large number of uncontiguous regions setup. Nonetheless, the consequence is bad and the fix is simple.

The issue was discovered [1] by Sashiko.

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

power: supply: qcombattmgr: fix use-after-free

qcombattmgrpdrnotify() queues enablework when the PMIC GLINK service comes up, and the worker recovers battmgr through containerof() to issue firmware requests. The PMIC GLINK client stays on the client list until its devres release action runs, so a PDR notification can keep queueing the work, and a pending or running worker can access battmgr after devres frees it.

Make enablework device-managed with devmworkautocancel(), registered before the PMIC GLINK client is allocated. The devres cleanup then releases the client first, so no further notification can queue the work, and cancels the work before battmgr is freed.

This issue was found by an in-house static analysis tool.

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

mmc: via-sdmmc: cancel card-detect work on remove

Disabling the device interrupt and freeing the IRQ prevents new card-detect work from being queued, but carddetwork already queued by the handler can still run after viasdremove() returns. viasdccarddetect() recovers the host through containerof() and dereferences its MMIO base; once remove() returns the host can be freed, so that work would touch freed memory.

Cancel carddetwork after freeing the IRQ and before cancelling finishbhwork, which the card-detect handler can also queue. carddetwork can re-enable the interrupt through viaresetpcictrl(); mask it again afterwards.

This issue was found by an in-house static analysis tool and confirmed by manual code review.

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

gtp: serialize PDP context updates

PDP contexts can be deleted through GTPCMDDELPDP or while the GTP network device is being unregistered. The latter is serialized by RTNL, but the generic-netlink delete path only holds RCU.

Running both paths concurrently can therefore make both paths delete the same PDP context. The issue was found through static analysis and reproduced on a KASAN-enabled kernel by a simple two-thread program racing GTPCMDDELPDP against RTMDELLINK:

Oops: general protection fault, probably for non-canonical address KASAN: maybe wild-memory-access in range [0xdead000000000120-0xdead000000000127] RIP: gtpgenldelpdp+0x1c1/0x420 [gtp] RBP: dead000000000122

The second deletion dereferenced the poisoned hlist pprev pointer.

Serialize gtppdpadd(), gtpgenldelpdp(), and gtpdellink() with a shared mutex. Keep the mutex held until the final use of a PDP context in the NEWPDP path, and keep the RCU read-side section around the complete PDP context use in the DELPDP path.

crypto: sun8i-ce - Remove cryptorng interface

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

KVM: x86/mmu: WARN and clear role.invalid when creating a child shadow page

Explicitly clear role.invalid when deriving a child shadow page's role from its parent to harden against bugs elsewhere in KVM, as violating KVM's invariant that invalid pages are NOT on the list of active MMU pages leads to use-after-free due to kvmmmupreparezappage() using listadd() instead of listmove() when processing an invalid shadow page, i.e. makes a bad situation far worse.

Yell loudly if the parent is invalid, as it means KVM has missed a validity check, i.e. KVM is attempting to map memory using an invalid/obsolete root, but continue on as the child is otherwise still a valid shadow page.

================================================================== BUG: KASAN: slab-use-after-free in kvmmmugetshadowpage+0x1817/0x1860 [kvm] Write of size 8 at addr ff11000153dd1368 by task repro/853

CPU: 1 UID: 1000 PID: 853 Comm: repro Not tainted 7.2.0-rc2-3aec122bdcaf-next-vm #5 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Call Trace: <TASK> dumpstacklvl+0x4b/0x70 printreport+0x153/0x49c kasanreport+0xbc/0xf0 kvmmmugetshadowpage+0x1817/0x1860 [kvm] mmuallocroot+0x141/0x320 [kvm] kvmmmuload+0x612/0x20f0 [kvm] kvmarchvcpuioctlrun+0x3dd5/0x6150 [kvm] kvmvcpuioctl+0x5e4/0x10d0 [kvm] x64sysioctl+0x131/0x1b0 dosyscall64+0x67/0x5f0 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>

Allocated by task 853: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 kasanslaballoc+0x5f/0x70 kmemcacheallocnoprof+0xfe/0x2e0 kvmmmutopupmemorycache+0x135/0x530 [kvm] paging64pagefault+0x318/0x1e30 [kvm] kvmmmudopagefault+0x21d/0x630 [kvm] kvmmmupagefault+0x18c/0x17b0 [kvm] kvmarchvcpuioctlrun+0x1f35/0x6150 [kvm] kvmvcpuioctl+0x5e4/0x10d0 [kvm] x64sysioctl+0x131/0x1b0 dosyscall64+0x67/0x5f0 entrySYSCALL64afterhwframe+0x4b/0x53

Freed by task 853: kasansavestack+0x20/0x40 kasansavetrack+0x14/0x30 kasansavefreeinfo+0x3b/0x60 kasanslabfree+0x43/0x70 kmemcachefree+0xe2/0x400 kvmmmucommitzappage.part.0+0x1e2/0x310 [kvm] kvmmmufreeroots+0x283/0x560 [kvm] kvmarchvcpuioctlrun+0x33c8/0x6150 [kvm] kvmvcpuioctl+0x5e4/0x10d0 [kvm] x64sysioctl+0x131/0x1b0 dosyscall64+0x67/0x5f0 entrySYSCALL64afterhwframe+0x4b/0x53

Bluetooth: mgmt: hold reference for hciconn in mgmtpendingcmds

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

net: dropmonitor: fix info leak in NETDMATTRPAYLOAD

netdmpacketreportfill() and netdmhwpacketreportfill() open code the NETDMATTRPAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skbcopybits().

skbput() reserves nlatotalsize(payloadlen), i.e. the header plus the NLAALIGN() padding, but only payloadlen bytes are copied in. When payloadlen is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message.

KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned:

BUG: KMSAN: kernel-infoleak in copytoiter copytoiter skbdatagramiter skbcopydatagramiter netlinkrecvmsg sockrecvmsg sysrecvfrom Uninit was created at: kmemcacheallocnodenoprof allocskb netdmpacketwork Bytes 173-175 of 176 are uninitialized

Use nlareserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction.

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

sctp: close UDP tunnel sockets during netns teardown

procsctpdoudpport() starts per-net SCTP UDP tunneling sockets when net.sctp.udpport is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed.

Close the UDP tunnel sockets from sctpctrlsockexit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed.

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

libceph: Reject monmaps advertising zero monitors

A message of type CEPHMSGMONMAP contains a monmap that is sent from a monitor to the client. This monmap contains information about the existing monitors in the cluster. Currently, a monmap indicating that there are zero monitors in the cluster is treated as valid. However, it is impossible to have zero monitors in the cluster and still receive a valid monmap from a monitor. Therefore, such a monmap must be corrupted and should be treated as invalid. Furthermore, a monmap with a monitor count of zero can subsequently crash the client when attempting to open a session with a monitor in opensession(). This happens because the "BUGON(monc->monmap->nummon < 1)" assertion in picknewmon() is triggered.

This patch extends a check in cephmonmapdecode() to also reject arriving monmaps with nummon == 0 rather than only with nummon > CEPHMAXMON.

[ idryomov: drop "log output for unusual values of nummon" part ]

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

A flaw was found within the parsing of extended attributes in the kernel ksmbd module. The issue results from the lack of proper validation of user-supplied data, which can result in a read past the end of an allocated buffer. An attacker can leverage this to disclose sensitive information on affected installations of Linux. Only systems with ksmbd enabled are vulnerable to this CVE.

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

net/smc: free stashed qentry before overwrite in REQADDLINK to ADDLINK transition

When smcllceventhandler() transitions the local LLC flow from SMCLLCFLOWREQADDLINK to SMCLLCFLOWADDLINK on arrival of an ADDLINK request, it calls smcllcflowqentryset() unconditionally:

if (lgr->llcflowlcl.type == SMCLLCFLOWREQADDLINK) { lgr->llcflowlcl.type = SMCLLCFLOWADDLINK; smcllcflowqentryset(&lgr->llcflowlcl, qentry); ... }

A CONFIRMLINK or ADDLINKCONT arriving while flow->type is SMCLLCFLOWREQADDLINK is stashed into flow->qentry via the SMCLLCCONFIRMLINK / SMCLLCADDLINKCONT handler (which stores into flow->qentry for any non-NONE flow type). When the subsequent ADDLINK arrives, the REQADDLINK branch overwrites flow->qentry with the new pointer without first freeing the stashed allocation, leaking one kmalloc object.

The stashed entry has no consumer: smcllcwait() is only called from llcaddlinkwork, which is not yet scheduled while the flow type remains REQADDLINK. No waiter is sleeping on llcmsgwaiter at this point. It is safe to unconditionally free any stashed qentry before the overwrite.

Call smcllcflowqentrydel() before smcllcflowqentryset() in the REQADDLINK branch. smcllcflowqentrydel() already checks flow->qentry before freeing, so the normal path where no entry is stashed is a no-op.

dmaengine: sun6i-dma: Fix reclaim descriptors while terminating DMA

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

nilfs2: prevent out-of-bounds read in super root block parsing

super-root inode metadata size is trusted before nilfsreadinodecommon().

Reject super-root inode sizes whose computed on-disk footprint exceeds the filesystem block size. This prevents malformed filesystem images from making nilfsreadinodecommon() read past the end of the super-root block.

[ryusuke: clarify the commit title]

drm/lima: call drmmminit() with a valid allocation range

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

mtd: rawnand: validate ONFI extended parameter page sections

nandflashdetectextparampage() allocates the length declared by the ONFI parameter page, then treats the data as a fixed header followed by variable-length sections. It reads that header and advances over sections without first proving that the fixed page and each current section fit in the allocation.

Reject pages shorter than the fixed header, track the remaining variable area while walking sections, and require the ECC section to contain every field read from struct onfiexteccinfo. Use device-scoped diagnostics that identify the malformed ONFI section.

f2fs: use the mount idmap for the owner check in f2fsxattradviseset()