drm/radeon: delete radeonfenceprocess in issignaled, no deadlock

dlm: prevent NPD when writing a positive value to eventdone

dm-raid: really frozen syncthread during suspend

A flaw named "EntryBleed" was found in the Linux Kernel Page Table Isolation (KPTI). This issue could allow a local attacker to leak KASLR base via prefetch side-channels based on TLB timing for Intel systems.

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

timers: Fix NULL function pointer race in timershutdownsync()

There is a race condition between timershutdownsync() and timer expiration that can lead to hitting a WARNON in expiretimers().

The issue occurs when timershutdownsync() clears the timer function to NULL while the timer is still running on another CPU. The race scenario looks like this:

CPU0 CPU1 <SOFTIRQ> locktimerbase() expiretimers() base->runningtimer = timer; unlocktimerbase() [calltimerfn enter] modtimer() ... timershutdownsync() locktimerbase() // For now, will not detach the timer but only clear its function to NULL if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimerbase() [calltimerfn exit] locktimerbase() base->runningtimer = NULL; unlocktimerbase() ... // Now timer is pending while its function set to NULL. // next timer trigger <SOFTIRQ> expiretimers() WARNONONCE(!fn) // hit ... locktimerbase() // Now timer will detach if (base->runningtimer != timer) ret = detachifpending(timer, base, true); if (shutdown) timer->function = NULL; unlocktimerbase()

The problem is that timershutdownsync() clears the timer function regardless of whether the timer is currently running. This can leave a pending timer with a NULL function pointer, which triggers the WARNONONCE(!fn) check in expiretimers().

Fix this by only clearing the timer function when actually detaching the timer. If the timer is running, leave the function pointer intact, which is safe because the timer will be properly detached when it finishes running.

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

ksm: use range-walk function to jump over holes in scangetnextrmapitem

Currently, scangetnextrmapitem() walks every page address in a VMA to locate mergeable pages. This becomes highly inefficient when scanning large virtual memory areas that contain mostly unmapped regions, causing ksmd to use large amount of cpu without deduplicating much pages.

This patch replaces the per-address lookup with a range walk using walkpagerange(). The range walker allows KSM to skip over entire unmapped holes in a VMA, avoiding unnecessary lookups. This problem was previously discussed in [1].

Consider the following test program which creates a 32 TiB mapping in the virtual address space but only populates a single page:

#include <unistd.h> #include <stdio.h> #include <sys/mman.h>

/ 32 TiB / const sizet size = 32ul 1024 1024 1024 1024;

int main() { char area = mmap(NULL, size, PROTREAD | PROTWRITE, MAPNORESERVE | MAPPRIVATE | MAPANON, -1, 0);

if (area == MAPFAILED) { perror("mmap() failed\n"); return -1; }

/ Populate a single page such that we get an anonvma. / area = 0;

/ Enable KSM. / madvise(area, size, MADVMERGEABLE); pause(); return 0; }

$ ./ksm-sparse & $ echo 1 > /sys/kernel/mm/ksm/run

Without this patch ksmd uses 100% of the cpu for a long time (more then 1 hour in my test machine) scanning all the 32 TiB virtual address space that contain only one mapped page. This makes ksmd essentially deadlocked not able to deduplicate anything of value. With this patch ksmd walks only the one mapped page and skips the rest of the 32 TiB virtual address space, making the scan fast using little cpu.

bpf: Do not let BPF test infra emit invalid GSO types to stack

bpf: Fix invalid prog->stats access when updateeffectiveprogs fails

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

scsi: smartpqi: Fix device resources accessed after device removal

Correct possible race conditions during device removal.

Previously, a scheduled work item to reset a LUN could still execute after the device was removed, leading to use-after-free and other resource access issues.

This race condition occurs because the abort handler may schedule a LUN reset concurrently with device removal via sdevdestroy(), leading to use-after-free and improper access to freed resources.

- Check in the device reset handler if the device is still present in the controller's SCSI device list before running; if not, the reset is skipped.

- Cancel any pending TMF work that has not started in sdevdestroy().

- Ensure device freeing in sdevdestroy() is done while holding the LUN reset mutex to avoid races with ongoing resets.

bpf: Check skb->transportheader is set in bpfskbcheckmtu

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

ext4: refresh inline data size before write operations

The cached ei->iinlinesize can become stale between the initial size check and when ext4updateinlinedata()/ext4createinlinedata() use it. Although ext4getmaxinlinesize() reads the correct value at the time of the check, concurrent xattr operations can modify iinlinesize before ext4writelockxattr() is acquired.

This causes ext4updateinlinedata() and ext4createinlinedata() to work with stale capacity values, leading to a BUGON() crash in ext4writeinlinedata():

kernel BUG at fs/ext4/inline.c:1331! BUGON(pos + len > EXT4I(inode)->iinlinesize);

The race window: 1. ext4getmaxinlinesize() reads iinlinesize = 60 (correct) 2. Size check passes for 50-byte write 3. [Another thread adds xattr, iinlinesize changes to 40] 4. ext4writelockxattr() acquires lock 5. ext4updateinlinedata() uses stale iinlinesize = 60 6. Attempts to write 50 bytes but only 40 bytes actually available 7. BUGON() triggers

Fix this by recalculating iinlinesize via ext4findinlinedatanolock() immediately after acquiring xattrsem. This ensures ext4updateinlinedata() and ext4createinlinedata() work with current values that are protected from concurrent modifications.

This is similar to commit a54c4613dac1 ("ext4: fix race writing to an inlinedata file while its xattrs are changing") which fixed iinlineoff staleness. This patch addresses the related iinlinesize staleness issue.

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

netfilter: ctnetlink: remove refcounting in expectation dumpers

Same pattern as previous patch: do not keep the expectation object alive via refcount, only store a cookie value and then use that as the skip hint for dump resumption.

AFAICS this has the same issue as the one resolved in the conntrack dumper, when we do if (!refcountincnotzero(&exp->use))

to increment the refcount, there is a chance that exp == last, which causes a double-increment of the refcount and subsequent memory leak.

bpf: Forget ranges when refining tnum after JSET

bpf: Reject narrower access to pointer ctx fields

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

net: phy: allow MDIO bus PM ops to start/stop state machine for phylink-controlled PHY

DSA has 2 kinds of drivers:

1. Those who call dsaswitchsuspend() and dsaswitchresume() from their device PM ops: qca8k-8xxx, bcmsf2, microchip ksz 2. Those who don't: all others. The above methods should be optional.

For type 1, dsaswitchsuspend() calls dsausersuspend() -> phylinkstop(), and dsaswitchresume() calls dsauserresume() -> phylinkstart(). These seem good candidates for setting macmanagedpm = true because that is essentially its definition [1], but that does not seem to be the biggest problem for now, and is not what this change focuses on.

Talking strictly about the 2nd category of DSA drivers here (which do not have MAC managed PM, meaning that for their attached PHYs, mdiobusphysuspend() and mdiobusphyresume() should run in full), I have noticed that the following warning from mdiobusphyresume() is triggered:

WARNON(phydev->state != PHYHALTED && phydev->state != PHYREADY && phydev->state != PHYUP);

because the PHY state machine is running.

It's running as a result of a previous dsauseropen() -> ... -> phylinkstart() -> phystart() having been initiated by the user.

The previous mdiobusphysuspend() was supposed to have called phystopmachine(), but it didn't. So this is why the PHY is in state PHYNOLINK by the time mdiobusphyresume() runs.

mdiobusphysuspend() did not call phystopmachine() because for phylink, the phydev->adjustlink function pointer is NULL. This seems a technicality introduced by commit fddd91016d16 ("phylib: fix PAL state machine restart on resume"). That commit was written before phylink existed, and was intended to avoid crashing with consumer drivers which don't use the PHY state machine - phylink always does, when using a PHY. But phylink itself has historically not been developed with suspend/resume in mind, and apparently not tested too much in that scenario, allowing this bug to exist unnoticed for so long. Plus, prior to the WARNON(), it would have likely been invisible.

This issue is not in fact restricted to type 2 DSA drivers (according to the above ad-hoc classification), but can be extrapolated to any MAC driver with phylink and MDIO-bus-managed PHY PM ops. DSA is just where the issue was reported. Assuming macmanagedpm is set correctly, a quick search indicates the following other drivers might be affected:

$ grep -Zlr PHYLINKNETDEV drivers/ | xargs -0 grep -L macmanagedpm drivers/net/ethernet/atheros/ag71xx.c drivers/net/ethernet/microchip/sparx5/sparx5main.c drivers/net/ethernet/microchip/lan966x/lan966xmain.c drivers/net/ethernet/freescale/dpaa2/dpaa2-mac.c drivers/net/ethernet/freescale/fsenet/fsenet-main.c drivers/net/ethernet/freescale/dpaa/dpaaeth.c drivers/net/ethernet/freescale/uccgeth.c drivers/net/ethernet/freescale/enetc/enetcpfcommon.c drivers/net/ethernet/marvell/mvpp2/mvpp2main.c drivers/net/ethernet/marvell/mvneta.c drivers/net/ethernet/marvell/prestera/presteramain.c drivers/net/ethernet/mediatek/mtkethsoc.c drivers/net/ethernet/altera/alteratsemain.c drivers/net/ethernet/wangxun/txgbe/txgbephy.c drivers/net/ethernet/meta/fbnic/fbnicphylink.c drivers/net/ethernet/tehuti/tn40phy.c drivers/net/ethernet/mscc/ocelotnet.c

Make the existing conditions dependent on the PHY device having a phydev->phylinkchange() implementation equal to the default phylinkchange() provided by phylib. Otherwise, we implicitly know that the phydev has the phylink-provided phylinkphychange() callback, and when phylink is used, the PHY state machine always needs to be stopped/ started on the suspend/resume path. The code is structured as such that if phydev->phylinkchange() is absent, it is a matter of time until the kernel will crash - no need to further complicate the test.

Thus, for the situation where the PM is not managed b ---truncated---

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

net: Remove RTNL dance for SIOCBRADDIF and SIOCBRDELIF.

SIOCBRDELIF is passed to devioctl() first and later forwarded to brioctlcall(), which causes unnecessary RTNL dance and the splat below [0] under RTNL pressure.

Let's say Thread A is trying to detach a device from a bridge and Thread B is trying to remove the bridge.

In devioctl(), Thread A bumps the bridge device's refcnt by netdevhold() and releases RTNL because the following brioctlcall() also re-acquires RTNL.

In the race window, Thread B could acquire RTNL and try to remove the bridge device. Then, rtnlunlock() by Thread B will release RTNL and wait for netdevput() by Thread A.

Thread A, however, must hold RTNL after the unlock in devifsioc(), which may take long under RTNL pressure, resulting in the splat by Thread B.

Thread A (SIOCBRDELIF) Thread B (SIOCBRDELBR) ---------------------- ---------------------- sockioctl sockioctl - sockdoioctl - brioctlcall - devioctl - brioctlstub |- rtnllock | |- devifsioc ' ' |- dev = devgetbyname(...) |- netdevhold(dev, ...) . / |- rtnlunlock ------. | | |- brioctlcall ---> |- rtnllock Race | | - brioctlstub |- brdelbridge Window | | | |- dev = devgetbyname(...) | | | May take long | - brdevdelete(dev, ...) | | | under RTNL pressure | - unregisternetdevicequeue(dev, ...) | | | | - rtnlunlock \ | |- rtnllock <-' - netdevruntodo | |- ... - netdevruntodo | - rtnlunlock |- rtnlunlock | |- netdevwaitallrefsany |- netdevput(dev, ...) <----------------' Wait refcnt decrement and log splat below

To avoid blocking SIOCBRDELBR unnecessarily, let's not call devioctl() for SIOCBRADDIF and SIOCBRDELIF.

In the devioctl() path, we do the following:

1. Copy struct ifreq by getuserifreq in sockdoioctl() 2. Check CAPNETADMIN in devioctl() 3. Call devload() in devioctl() 4. Fetch the master dev from ifr.ifrname in devifsioc()

3. can be done by requestmodule() in brioctlcall(), so we move 1., 2., and 4. to brioctlstub().

Note that 2. is also checked later in adddelif(), but it's better performed before RTNL.

SIOCBRADDIF and SIOCBRDELIF have been processed in devioctl() since the pre-git era, and there seems to be no specific reason to process them there.

[0]: unregisternetdevice: waiting for wpan3 to become free. Usage count = 2 reftracker: wpan3@ffff8880662d8608 has 1/1 users at netdevtrackeralloc include/linux/netdevice.h:4282 [inline] netdevhold include/linux/netdevice.h:4311 [inline] devifsioc+0xc6a/0x1160 net/core/devioctl.c:624 devioctl+0x255/0x10c0 net/core/devioctl.c:826 sockdoioctl+0x1ca/0x260 net/socket.c:1213 sockioctl+0x23a/0x6c0 net/socket.c:1318 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl fs/ioctl.c:892 [inline] x64sysioctl+0x1a4/0x210 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcb/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f

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

mm: clear uffd-wp PTE/PMD state on mremap()

When mremap()ing a memory region previously registered with userfaultfd as write-protected but without UFFDFEATUREEVENTREMAP, an inconsistency in flag clearing leads to a mismatch between the vma flags (which have uffd-wp cleared) and the pte/pmd flags (which do not have uffd-wp cleared). This mismatch causes a subsequent mprotect(PROTWRITE) to trigger a warning in pagetablecheckpteflags() due to setting the pte to writable while uffd-wp is still set.

Fix this by always explicitly clearing the uffd-wp pte/pmd flags on any such mremap() so that the values are consistent with the existing clearing of VMUFFDWP. Be careful to clear the logical flag regardless of its physical form; a PTE bit, a swap PTE bit, or a PTE marker. Cover PTE, huge PMD and hugetlb paths.

bonding: check xdp prog when set bond mode

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

nfsd: don't ignore the return code of svcprocregister()

Currently, nfsdprocstatinit() ignores the return value of svcprocregister(). If the procfile creation fails, then the kernel will WARN when it tries to remove the entry later.

Fix nfsdprocstatinit() to return the same type of pointer as svcprocregister(), and fix up nfsdnetinit() to check that and fail the nfsdnet construction if it occurs.

svcprocregister() can fail if the dentry can't be allocated, or if an identical dentry already exists. The second case is pretty unlikely in the nfsdnet construction codepath, so if this happens, return -ENOMEM.

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

RDMA/mlx5: Fix a race for an ODP MR which leads to CQE with error

This patch addresses a race condition for an ODP MR that can result in a CQE with an error on the UMR QP.

During the mlx5ibderegmr() flow, the following sequence of calls occurs:

mlx5revokemr() mlx5rumrrevokemr() mlx5rumrpostsendwait()

At this point, the lkey is freed from the hardware's perspective.

However, concurrently, mlx5ibinvalidaterange() might be triggered by another task attempting to invalidate a range for the same freed lkey.

This task will: - Acquire the umemodp->umemmutex lock. - Call mlx5rumrupdatexlt() on the UMR QP. - Since the lkey has already been freed, this can lead to a CQE error, causing the UMR QP to enter an error state [1].

To resolve this race condition, the umemodp->umemmutex lock is now also acquired as part of the mlx5revokemr() scope. Upon successful revoke, we set umemodp->private which points to that MR to NULL, preventing any further invalidation attempts on its lkey.

[1] From dmesg:

infiniband rocep8s0f0: dumpcqe:277:(pid 0): WC error: 6, Message: memory bind operation error cqedump: 00000000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000010: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 cqedump: 00000030: 00 00 00 00 08 00 78 06 25 00 11 b9 00 0e dd d2

WARNING: CPU: 15 PID: 1506 at drivers/infiniband/hw/mlx5/umr.c:394 mlx5rumrpostsendwait+0x15a/0x2b0 [mlx5ib] Modules linked in: ip6tablemangle ip6tablenatip6tablefilter ip6tables iptablemangle xtconntrack xtMASQUERADE nfconntracknetlink nfnetlink xtaddrtype iptablenat nfnat brnetfilter rpcsecgsskrb5 authrpcgss oidregistry overlay rpcrdma rdmaucm ibiser libiscsi scsitransportiscsi rdmacm iwcm ibumad ibipoib ibcm mlx5ib ibuverbs ibcore fuse mlx5core CPU: 15 UID: 0 PID: 1506 Comm: ibvrcpingpong Not tainted 6.12.0-rc7+ #1626 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:mlx5rumrpostsendwait+0x15a/0x2b0 [mlx5ib] [..] Call Trace: <TASK> mlx5rumrupdatexlt+0x23c/0x3e0 [mlx5ib] mlx5ibinvalidaterange+0x2e1/0x330 [mlx5ib] mmunotifierinvalidaterangestart+0x1e1/0x240 zappagerangesingle+0xf1/0x1a0 madvisevmabehavior+0x677/0x6e0 domadvise+0x1a2/0x4b0 x64sysmadvise+0x25/0x30 dosyscall64+0x6b/0x140 entrySYSCALL64afterhwframe+0x76/0x7e

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

nbd: defer config unlock in nbdgenlconnect

There is one use-after-free warning when running NBDCMDCONNECT and NBDCLEARSOCK:

nbdgenlconnect nbdallocandinitconfig // configrefs=1 nbdstartdevice // configrefs=2 set NBDRTHASCONFIGREF open nbd // configrefs=3 recvwork done // configrefs=2 NBDCLEARSOCK // configrefs=1 close nbd // configrefs=0 refcountinc -> uaf

------------[ cut here ]------------ refcountt: addition on 0; use-after-free. WARNING: CPU: 24 PID: 1014 at lib/refcount.c:25 refcountwarnsaturate+0x12e/0x290 nbdgenlconnect+0x16d0/0x1ab0 genlfamilyrcvmsgdoit+0x1f3/0x310 genlrcvmsg+0x44a/0x790

The issue can be easily reproduced by adding a small delay before refcountinc(&nbd->configrefs) in nbdgenlconnect():

mutexunlock(&nbd->configlock); if (!ret) { setbit(NBDRTHASCONFIGREF, &config->runtimeflags); + printk("before sleep\n"); + mdelay(5 1000); + printk("after sleep\n"); refcountinc(&nbd->configrefs); nbdconnectreply(info, nbd->index); }

drm, fbcon, vgaswitcheroo: Avoid race condition in fbcon setup

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

usbnet: Fix using smpprocessorid() in preemptible code warnings

Syzbot reported the following warning:

BUG: using smpprocessorid() in preemptible [00000000] code: dhcpcd/2879 caller is usbnetskbreturn+0x74/0x490 drivers/net/usb/usbnet.c:331 CPU: 1 UID: 0 PID: 2879 Comm: dhcpcd Not tainted 6.15.0-rc4-syzkaller-00098-g615dca38c2ea #0 PREEMPT(voluntary) Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x16c/0x1f0 lib/dumpstack.c:120 checkpreemptiondisabled+0xd0/0xe0 lib/smpprocessorid.c:49 usbnetskbreturn+0x74/0x490 drivers/net/usb/usbnet.c:331 usbnetresumerx+0x4b/0x170 drivers/net/usb/usbnet.c:708 usbnetchangemtu+0x1be/0x220 drivers/net/usb/usbnet.c:417 devsetmtu net/core/dev.c:9443 [inline] netifsetmtuext+0x369/0x5c0 net/core/dev.c:9496 netifsetmtu+0xb0/0x160 net/core/dev.c:9520 devsetmtu+0xae/0x170 net/core/devapi.c:247 devifsioc+0xa31/0x18d0 net/core/devioctl.c:572 devioctl+0x223/0x10e0 net/core/devioctl.c:821 sockdoioctl+0x19d/0x280 net/socket.c:1204 sockioctl+0x42f/0x6a0 net/socket.c:1311 vfsioctl fs/ioctl.c:51 [inline] dosysioctl fs/ioctl.c:906 [inline] sesysioctl fs/ioctl.c:892 [inline] x64sysioctl+0x190/0x200 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/syscall64.c:63 [inline] dosyscall64+0xcd/0x260 arch/x86/entry/syscall64.c:94 entrySYSCALL64afterhwframe+0x77/0x7f

For historical and portability reasons, the netifrx() is usually run in the softirq or interrupt context, this commit therefore add localbhdisable/enable() protection in the usbnetresumerx().

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

scsi: sg: Do not sleep in atomic context

sgfinishremreq() calls blkrqunmapuser(). The latter function may sleep. Hence, call sgfinishremreq() with interrupts enabled instead of disabled.

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

net: openvswitch: remove never-working support for setting nsh fields

The validation of the set(nsh(...)) action is completely wrong. It runs through the nshkeyputfromnlattr() function that is the same function that validates NSH keys for the flow match and the pushnsh() action. However, the set(nsh(...)) has a very different memory layout. Nested attributes in there are doubled in size in case of the masked set(). That makes proper validation impossible.

There is also confusion in the code between the 'masked' flag, that says that the nested attributes are doubled in size containing both the value and the mask, and the 'ismask' that says that the value we're parsing is the mask. This is causing kernel crash on trying to write into mask part of the match with SWFLOWKEYPUT() during validation, while validatensh() doesn't allocate any memory for it:

BUG: kernel NULL pointer dereference, address: 0000000000000018 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 1c2383067 P4D 1c2383067 PUD 20b703067 PMD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 8 UID: 0 Kdump: loaded Not tainted 6.17.0-rc4+ #107 PREEMPT(voluntary) RIP: 0010:nshkeyputfromnlattr+0x19d/0x610 [openvswitch] Call Trace: <TASK> validatensh+0x60/0x90 [openvswitch] validateset.constprop.0+0x270/0x3c0 [openvswitch] ovsnlacopyactions+0x477/0x860 [openvswitch] ovsnlacopyactions+0x8d/0x100 [openvswitch] ovspacketcmdexecute+0x1cc/0x310 [openvswitch] genlfamilyrcvmsgdoit+0xdb/0x130 genlfamilyrcvmsg+0x14b/0x220 genlrcvmsg+0x47/0xa0 netlinkrcvskb+0x53/0x100 genlrcv+0x24/0x40 netlinkunicast+0x280/0x3b0 netlinksendmsg+0x1f7/0x430 syssendmsg+0x36b/0x3a0 syssendmsg+0x87/0xd0 syssendmsg+0x6d/0xd0 dosyscall64+0x7b/0x2c0 entrySYSCALL64afterhwframe+0x76/0x7e

The third issue with this process is that while trying to convert the non-masked set into masked one, validateset() copies and doubles the size of the OVSKEYATTRNSH as if it didn't have any nested attributes. It should be copying each nested attribute and doubling them in size independently. And the process must be properly reversed during the conversion back from masked to a non-masked variant during the flow dump.

In the end, the only two outcomes of trying to use this action are either validation failure or a kernel crash. And if somehow someone manages to install a flow with such an action, it will most definitely not do what it is supposed to, since all the keys and the masks are mixed up.

Fixing all the issues is a complex task as it requires re-writing most of the validation code.

Given that and the fact that this functionality never worked since introduction, let's just remove it altogether. It's better to re-introduce it later with a proper implementation instead of trying to fix it in stable releases.

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

nbd: defer config put in recvwork

There is one uaf issue in recvwork when running NBDCLEARSOCK and NBDCMDRECONFIGURE: nbdgenlconnect // confref=2 (connect and recvwork A) nbdopen // confref=3 recvwork A done // confref=2 NBDCLEARSOCK // confref=1 nbdgenlreconfigure // confref=2 (trigger recvwork B) close nbd // confref=1 recvwork B configput // confref=0 atomicdec(&config->recvthreads); -> UAF

Or only running NBDCLEARSOCK: nbdgenlconnect // confref=2 nbdopen // confref=3 NBDCLEARSOCK // confref=2 close nbd nbdrelease configput // confref=1 recvwork configput // confref=0 atomicdec(&config->recvthreads); -> UAF

Commit 87aac3a80af5 ("nbd: call nbdconfigput() before notifying the waiter") moved nbdconfigput() to run before waking up the waiter in recvwork, in order to ensure that nbdstartdeviceioctl() would not be woken up while nbd->taskrecv was still uncleared.

However, in nbdstartdeviceioctl(), after being woken up it explicitly calls flushworkqueue() to make sure all current works are finished. Therefore, there is no need to move the config put ahead of the wakeup.

Move nbdconfigput() to the end of recvwork, so that the reference is held for the whole lifetime of the worker thread. This makes sure the config cannot be freed while recvwork is still running, even if clear + reconfigure interleave.

In addition, we don't need to worry about recvwork dropping the last nbdput (which causes deadlock):

path A (netlink with NBDCFLAGDESTROYONDISCONNECT): connect // nbdrefs=1 (trigger recvwork) open nbd // nbdrefs=2 NBDCLEARSOCK close nbd nbdrelease nbddisconnectandput flushworkqueue // recvwork done nbdconfigput nbdput // nbdrefs=1 nbdput // nbdrefs=0 queuework

path B (netlink without NBDCFLAGDESTROYONDISCONNECT): connect // nbdrefs=2 (trigger recvwork) open nbd // nbdrefs=3 NBDCLEARSOCK // confrefs=2 close nbd nbdrelease nbdconfigput // confrefs=1 nbdput // nbdrefs=2 recvwork done // confrefs=0, nbdrefs=1 rmmod // nbdrefs=0

Depends-on: e2daec488c57 ("nbd: Fix hungtask when nbdconfigput")

ima: Handle error code returned by imafilterrulematch()

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

smb: client: fix memory leak in cifsconstructtcon()

When having a multiuser mount with domain= specified and using cifscreds, cifssetcifscreds() will end up setting @ctx->domainname, so it needs to be freed before leaving cifsconstructtcon().

This fixes the following memory leak reported by kmemleak:

mount.cifs //srv/share /mnt -o domain=ZELDA,multiuser,... su - testuser cifscreds add -d ZELDA -u testuser ... ls /mnt/1 ... umount /mnt echo scan > /sys/kernel/debug/kmemleak cat /sys/kernel/debug/kmemleak unreferenced object 0xffff8881203c3f08 (size 8): comm "ls", pid 5060, jiffies 4307222943 hex dump (first 8 bytes): 5a 45 4c 44 41 00 cc cc ZELDA... backtrace (crc d109a8cf): kmallocnodetrackcallernoprof+0x572/0x710 kstrdup+0x3a/0x70 cifssbtlink+0x1209/0x1770 [cifs] cifsgetfattr+0xe1/0xf50 [cifs] cifsgetinodeinfo+0xb5/0x240 [cifs] cifsrevalidatedentryattr+0x2d1/0x470 [cifs] cifsgetattr+0x28e/0x450 [cifs] vfsgetattrnosec+0x126/0x180 vfsstatx+0xf6/0x220 dostatx+0xab/0x110 x64sysstatx+0xd5/0x130 dosyscall64+0xbb/0x380 entrySYSCALL64afterhwframe+0x77/0x7f

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

scsi: target: tcmloop: Fix segfault in tcmlooptpgaddressshow()

If the allocation of tlhba->sh fails in tcmloopdriverprobe() and we attempt to dereference it in tcmlooptpgaddressshow() we will get a segfault, see below for an example. So, check tlhba->sh before dereferencing it.

Unable to allocate struct scsihost BUG: kernel NULL pointer dereference, address: 0000000000000194 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 8356 Comm: tokio-runtime-w Not tainted 6.6.104.2-4.azl3 #1 Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine, BIOS Hyper-V UEFI Release v4.1 09/28/2024 RIP: 0010:tcmlooptpgaddressshow+0x2e/0x50 [tcmloop] ... Call Trace: <TASK> configfsreaditer+0x12d/0x1d0 [configfs] vfsread+0x1b5/0x300 ksysread+0x6f/0xf0 ...

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

Input: croseckeyb - fix an invalid memory access

If croseckeybregistermatrix() isn't called (due to buttonsswitchesonly) in croseckeybprobe(), ckdev->idev remains NULL. An invalid memory access is observed in croseckeybprocess() when receiving an ECMKBPEVENTKEYMATRIX event in croseckeybwork() in such case.

Unable to handle kernel read from unreadable memory at virtual address 0000000000000028 ... x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000 Call trace: inputevent croseckeybwork blockingnotifiercallchain ecirqthread

It's still unknown about why the kernel receives such malformed event, in any cases, the kernel shouldn't access ckdev->idev and friends if the driver doesn't intend to initialize them.