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

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

mptcp: fix slab-use-after-free in inetlookupestablished

The ehash table lookups are lockless and rely on SLABTYPESAFEBYRCU to guarantee socket memory stability during RCU read-side critical sections. Both tcpprot and tcpv6prot have their slab caches created with this flag via protoregister().

However, MPTCP's mptcpsubflowinit() copies tcpv6prot into tcpv6protoverride during inetinit() (fsinitcall, level 5), before inet6init() (moduleinit/deviceinitcall, level 6) has called protoregister(&tcpv6prot). At that point, tcpv6prot.slab is still NULL, so tcpv6protoverride.slab remains NULL permanently.

This causes MPTCP v6 subflow child sockets to be allocated via kmalloc (falling into kmalloc-4k) instead of the TCPv6 slab cache. The kmalloc-4k cache lacks SLABTYPESAFEBYRCU, so when these sockets are freed without SOCKRCUFREE (which is cleared for child sockets by design), the memory can be immediately reused. Concurrent ehash lookups under rcureadlock can then access freed memory, triggering a slab-use-after-free in inetlookupestablished.

Fix this by splitting the IPv6-specific initialization out of mptcpsubflowinit() into a new mptcpsubflowv6init(), called from mptcpprotov6init() before protocol registration. This ensures tcpv6protoverride.slab correctly inherits the SLABTYPESAFEBYRCU slab cache.

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

net: mvpp2: guard flow control update with globaltxfc in buffer switching

mvpp2bmswitchbuffers() unconditionally calls mvpp2bmpoolupdateprivfc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2cm3read()/mvpp2cm3write(), which dereference priv->cm3base without any NULL check.

When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c ("dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree")), priv->cm3base remains NULL and priv->globaltxfc is false. Any operation that triggers mvpp2bmswitchbuffers(), for example an MTU change that crosses the jumbo frame threshold, will crash:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2cm3read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2bmpoolupdatefc+0x40/0x12c mvpp2bmpoolupdateprivfc+0x94/0xd8 mvpp2bmswitchbuffers.isra.0+0x80/0x1c0 mvpp2changemtu+0x140/0x380 devsetmtu+0x1c/0x38 devsetmtuext+0x78/0x118 devsetmtu+0x48/0xa8 devifsioc+0x21c/0x43c devioctl+0x2d8/0x42c sockioctl+0x314/0x378

Every other flow control call site in the driver already guards hardware access with either priv->globaltxfc or port->txfc. mvpp2bmswitchbuffers() is the only place that omits this check.

Add the missing priv->globaltxfc guard to both the disable and re-enable calls in mvpp2bmswitchbuffers(), consistent with the rest of the driver.

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

iouring/io-wq: check IOWQBITEXIT inside work run loop

Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr file. Since this file type doesn't support ->readiter(), looprwiter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path:

INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 taskflags:0x400548 flags:0x00080000 Call Trace: <TASK> contextswitch kernel/sched/core.c:5256 [inline] schedule+0x1139/0x6150 kernel/sched/core.c:6863 scheduleloop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 scheduletimeout+0x257/0x290 kernel/time/sleeptimeout.c:75 dowaitforcommon kernel/sched/completion.c:100 [inline] waitforcommon+0x2fc/0x4e0 kernel/sched/completion.c:121 iowqexitworkers iouring/io-wq.c:1328 [inline] iowqputandexit+0x271/0x8a0 iouring/io-wq.c:1356 iouringcleantctx+0x10d/0x190 iouring/tctx.c:203 iouringcancelgeneric+0x69c/0x9a0 iouring/cancel.c:651 iouringfilescancel include/linux/iouring.h:19 [inline] doexit+0x2ce/0x2bd0 kernel/exit.c:911 dogroupexit+0xd3/0x2a0 kernel/exit.c:1112 getsignal+0x2671/0x26d0 kernel/signal.c:3034 archdosignalorrestart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 exittousermodeloop kernel/entry/common.c:41 [inline] exittousermodeloop+0x8c/0x540 kernel/entry/common.c:75 exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x4ee/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIGRAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98

There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IOWQBITEXIT inside the ioworkerhandlework() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.

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

net: mscc: ocelot: Fix crash when adding interface under a lag

Commit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag") fixed a similar issue in the lan966x driver caused by a NULL pointer dereference. The ocelotsetaggrpgids() function in the ocelot driver has similar logic and is susceptible to the same crash.

This issue specifically affects the ocelotvsc7514.c frontend, which leaves unused ports as NULL pointers. The felixvsc9959.c frontend is unaffected as it uses the DSA framework which registers all ports.

Fix this by checking if the port pointer is valid before accessing it.

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

bpf: Fix incorrect pruning due to atomic fetch precision tracking

When backtrackinsn encounters a BPFSTX instruction with BPFATOMIC and BPFFETCH, the src register (or r0 for BPFCMPXCHG) also acts as a destination, thus receiving the old value from the memory location.

The current backtracking logic does not account for this. It treats atomic fetch operations the same as regular stores where the src register is only an input. This leads the backtrackinsn to fail to propagate precision to the stack location, which is then not marked as precise!

Later, the verifier's path pruning can incorrectly consider two states equivalent when they differ in terms of stack state. Meaning, two branches can be treated as equivalent and thus get pruned when they should not be seen as such.

Fix it as follows: Extend the BPFLDX handling in backtrackinsn to also cover atomic fetch operations via isatomicfetchinsn() helper. When the fetch dst register is being tracked for precision, clear it, and propagate precision over to the stack slot. For non-stack memory, the precision walk stops at the atomic instruction, same as regular BPFLDX. This covers all fetch variants.

Before:

0: (b7) r1 = 8 ; R1=8 1: (7b) (u64 )(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64fetchadd((u64 )(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 markprecise: frame0: lastidx 5 firstidx 0 subseqidx -1 markprecise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 markprecise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64fetchadd((u64 )(r10 -8), r2) markprecise: frame0: regs=r2 stack= before 2: (b7) r2 = 0 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit

After:

0: (b7) r1 = 8 ; R1=8 1: (7b) (u64 )(r10 -8) = r1 ; R1=8 R10=fp0 fp-8=8 2: (b7) r2 = 0 ; R2=0 3: (db) r2 = atomic64fetchadd((u64 )(r10 -8), r2) ; R2=8 R10=fp0 fp-8=mmmmmmmm 4: (bf) r3 = r10 ; R3=fp0 R10=fp0 5: (0f) r3 += r2 markprecise: frame0: lastidx 5 firstidx 0 subseqidx -1 markprecise: frame0: regs=r2 stack= before 4: (bf) r3 = r10 markprecise: frame0: regs=r2 stack= before 3: (db) r2 = atomic64fetchadd((u64 )(r10 -8), r2) markprecise: frame0: regs= stack=-8 before 2: (b7) r2 = 0 markprecise: frame0: regs= stack=-8 before 1: (7b) (u64 )(r10 -8) = r1 markprecise: frame0: regs=r1 stack= before 0: (b7) r1 = 8 6: R2=8 R3=fp8 6: (b7) r0 = 0 ; R0=0 7: (95) exit

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

perf/x86/intel/uncore: Fix die ID init and look up bugs

In snbeppci2phymapinit(), in the nrnodeids > 8 path, uncoredevicetodie() may return -1 when all CPUs associated with the UBOX device are offline.

Remove the WARNONONCE(dieid == -1) check for two reasons:

- The current code breaks out of the loop. This is incorrect because pcigetdevice() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.

- Returning -EINVAL is incorrect, since marking offline buses with dieid == -1 is expected and should not be treated as an error.

Separately, when NUMA is disabled on a NUMA-capable platform, pcibustonode() returns NUMANONODE, causing uncoredevicetodie() to return -1 for all PCI devices. As a result, sprupdatedevicelocation(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.

Fix this by using uncorepcibustodieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbeppci2phymapinit() to be added in spruncorepciinit().

Keep uncoredevicetodie() only for the nrnodeids > 8 case, where NUMA is expected to be enabled.

Bluetooth: MGMT: Fix UAF on mgmtremoveadvmonitorcomplete

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

net: tap: NULL pointer derefence in devparseheaderprotocol when skb->dev is null

Fixes a NULL pointer derefence bug triggered from tap driver. When tapgetuser calls virtionethdrtoskb the skb->dev is null (in tap.c skb->dev is set after the call to virtionethdrtoskb) virtionethdrtoskb calls devparseheaderprotocol which needs skb->dev field to be valid.

The line that trigers the bug is in devparseheaderprotocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->headerops || !dev->headerops->parseprotocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax

Setting skb->dev before the call in tap.c fixes the issue.

BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtionethdrtoskb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tapgetuser+0x3f1/0x540 [tap] tapsendmsg+0x56/0x362 [tap] ? gettxbufs+0xc2/0x1e0 [vhostnet] handletxcopy+0x114/0x670 [vhostnet] handletx+0xb0/0xe0 [vhostnet] handletxkick+0x15/0x20 [vhostnet] vhostworker+0x7b/0xc0 [vhost] ? vhostvringcallreset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x1f/0x30

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

NTB: epf: Avoid calling pciirqvector() from hardirq context

ntbepfvecisr() calls pciirqvector() in hardirq context to derive the vector number. pciirqvector() calls msigetvirq() that takes a mutex and can therefore trigger "scheduling while atomic" splats:

BUG: scheduling while atomic: kworker/u33:0/55/0x00010001 ... Call trace: ... schedule+0x38/0x110 schedulepreemptdisabled+0x28/0x50 mutexlock.constprop.0+0x848/0x908 mutexlockslowpath+0x18/0x30 mutexlock+0x4c/0x60 msidomaingetvirq+0xe8/0x138 pciirqvector+0x2c/0x60 ntbepfvecisr+0x28/0x120 [ntbhwepf] handleirqeventpercpu+0x70/0x3a8 handleirqevent+0x48/0x100 handleedgeirq+0x100/0x1c8 ...

Cache the Linux IRQ number for vector 0 when vectors are allocated and use it as a base in the ISR. Running the ISR in a threaded IRQ handler would also avoid the problem, but that would be unnecessary here.

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

usb: cdnsp: fix stream context array leak in cdnspallocstreaminfo()

cdnspallocstreaminfo() allocates streaminfo->streamctxarray with cdnspallocstreamctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and streamrings array, but leaves streamctxarray allocated.

Free the stream context array before falling through to the streamrings cleanup path.

An out-of-bounds (OOB) memory access flaw was found in fs/f2fs/node.c in the f2fs module in the Linux kernel in versions before 5.12.0-rc4. A bounds check failure allows a local attacker to gain access to out-of-bounds memory leading to a system crash or a leak of internal kernel information. The highest threat from this vulnerability is to system availability.

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

media: atomisp: Fix use after free in atomispalloccssstatbufs()

The "s3abuf" is freed along with all the other items on the "asd->s3astats" list. It leads to a double free and a use after free.

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

nvme: fix reconnection fail due to reserved tag allocation

The Linux kernel CVE team has assigned CVE-2024-27435 to this issue.

Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051710-CVE-2024-27435-c465@gregkh/T

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

mm: do file ownership checks with the proper mount idmap

Ever since idmapped mounts were introduced, inode ownership checks (for side-channel protection) in mincore() and madvise(MADVPAGEOUT) were done against the nopmntidmap, which completely ignores the file's mount's idmap. This results in odd edgecases like:

1) mount/bind-mount with an idmap userA:userB:1 2) userB runs an ownerorcapable() check on file that is owned by userA on-disk/in-memory, but owned by userB after idmap translation 3) ownerorcapable() mysteriously fails as the correct idmap wasn't supplied

In the case of mincore/madvise MADVPAGEOUT, this is usually benign, because filepermission(file, MAYWRITE) will probably succeed, as it uses the proper idmap internally, but it does not need to be the case on e.g a 0444 file where even the owner itself doesn't have permissions to write to it.

Since this is clearly not trivial to get right, introduce a fileownerorcapable() that can carry the correct semantics, and switch the various users in mm to it.

The issue was found by manual code inspection & an off-list discussion with Jan Kara.

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

mtd: require write permissions for locking and badblock ioctls

MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once.

MEMSETBADBLOCK modifies the bad block table.

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

KVM: x86/mmu: Ensure hugepage is in by slot before checking max mapping level

When recovering hugepages in the shadow MMU, verify that the base gfn of the shadow page is actually contained within the target memslot, before querying the max mapping level given the shadow page's gfn. Failure to pre-check the validity of the gfn can lead to an out-of-bounds access to the slot's lpageinfo (which typically manifests as a host #PF because the lpageinfo is vmalloc'd) if the guest creates a hugepage mapping (in its PTEs) that extends "below" the bounds of a memslot.

When faulting in memory for a guest, and the size of the guest mapping is greater than KVM's (current) max mapping, then KVM will create a "direct" shadow page (direct in that there are no gPTEs to shadow, and so the target gfn is a direct calculation given the base gfn of the shadow page). The hugepage recovery flow looks for such direct shadow pages, as forcing 4KiB mappings when dirty logging generates the guest > host mapping size case. When the 4KiB restriction is lifted, then KVM can replace the shadow page with a hugepage.

But if KVM originally used a smaller mapping than the guest because the range of memory covered by the guest hugepage exceeds the bounds of a memslot, then KVM will link a direct shadow page with a gfn that is outside the bounds of the memslot being used to fault in memory. The rmap entry added for the leaf mapping is correct and within bounds, but the gfn of the leaf SPTE's parent shadow page will be out of bounds.

BUG: unable to handle page fault for address: ffffc90000806ffc #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 1002a7067 PMD 10612f067 PTE 0 Oops: Oops: 0000 [#1] SMP CPU: 13 UID: 1000 PID: 757 Comm: mmustresstest Not tainted 7.1.0-rc1-48ce1e26eace-x86pirtoirrcomments-vm #341 PREEMPT Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 RIP: 0010:kvmmmumaxmappinglevel+0x79/0x2b0 [kvm] Call Trace: <TASK> kvmmmurecoverhugepages+0x21b/0x320 [kvm] kvmsetmemslot+0x1ee/0x590 [kvm] kvmsetmemoryregion.part.0+0x3a1/0x4d0 [kvm] kvmvmioctl+0x9bf/0x15d0 [kvm] x64sysioctl+0x8a/0xd0 dosyscall64+0xb7/0xbb0 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f21c0f1a9bf </TASK>

Don't bother pre-checking the bounds of the potential hugepage, i.e. don't check that e.g. sp->gfn + KVMPAGESPERHPAGE(sp->role.level + 1) is also within the memslot, as the checks performed by kvmmmumaxmappinglevel() are a superset of the basic bounds checks. I.e. pre-checking the full range would be a dubious micro-optimization.

A use-after-free flaw was found in hcisendacl in the bluetooth host controller interface (HCI) in Linux kernel, where a local attacker with an access rights could cause a denial of service problem on the system The issue results from the object hchan, freed in hcidisconnloglinkcompleteevt, yet still used in other places. The highest threat from this vulnerability is to data integrity, confidentiality and system availability.

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

scsi: ufs: core: Fix use-after free in init error and remove paths

devmblkcryptoprofileinit() registers a cleanup handler to run when the associated (platform-) device is being released. For UFS, the crypto private data and pointers are stored as part of the ufshba's data structure 'struct ufshba::cryptoprofile'. This structure is allocated as part of the underlying ufshcd and therefore Scsihost allocation.

During driver release or during error handling in ufshcdpltfrminit(), this structure is released as part of ufshcddeallochost() before the (platform-) device associated with the crypto call above is released. Once this device is released, the crypto cleanup code will run, using the just-released 'struct ufshba::cryptoprofile'. This causes a use-after-free situation:

Call trace: kfree+0x60/0x2d8 (P) kvfree+0x44/0x60 blkcryptoprofiledestroycallback+0x28/0x70 devmactionrelease+0x1c/0x30 releasenodes+0x6c/0x108 devresreleaseall+0x98/0x100 deviceunbindcleanup+0x20/0x70 reallyprobe+0x218/0x2d0

In other words, the initialisation code flow is:

platform-device probe ufshcdpltfrminit() ufshcdallochost() scsihostalloc() allocation of struct ufshba creation of scsi-host devices devmblkcryptoprofileinit() devm registration of cleanup handler using platform-device

and during error handling of ufshcdpltfrminit() or during driver removal:

ufshcddeallochost() scsihostput() putdevice(scsi-host) release of struct ufshba putdevice(platform-device) crypto cleanup handler

To fix this use-after free, change ufshcdallochost() to register a devres action to automatically cleanup the underlying SCSI device on ufshcd destruction, without requiring explicit calls to ufshcddeallochost(). This way:

the crypto profile and all other ufshba-owned resources are destroyed before SCSI (as they've been registered after) a memleak is plugged in tc-dwc-g210-pci.c remove() as a side-effect EXPORTSYMBOLGPL(ufshcddeallochost) can be removed fully as it's not needed anymore no future drivers using ufshcdallochost() could ever forget adding the cleanup

drm/vkms: Fix use after free and double free on init error

gpio: xilinx: Convert gpiolock to raw spinlock

bus: mhi: host: pcigeneric: Use pcitryresetfunction() to avoid deadlock

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

riscv: uprobes: Add missing fence.i after building the XOL buffer

The XOL (execute out-of-line) buffer is used to single-step the replaced instruction(s) for uprobes. The RISC-V port was missing a proper fence.i (i$ flushing) after constructing the XOL buffer, which can result in incorrect execution of stale/broken instructions.

This was found running the BPF selftests "testprogs: uprobeautoattach, attachprobe" on the Spacemit K1/X60, where the uprobes tests randomly blew up.

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

drm/amdkfd: Fix UBSAN shift-out-of-bounds warning

If getnumsdmaqueues or getnumxgmisdmaqueues is 0, we end up doing a shift operation where the number of bits shifted equals number of bits in the operand. This behaviour is undefined.

Set numsdmaqueues or numxgmisdmaqueues to ULLONGMAX, if the count is >= number of bits in the operand.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/1472

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

smb: client: validate dacloffset before building DACL pointers

parsesecdesc(), buildsecdesc(), and the chown path in idmodetocifsacl() all add the server-supplied dacloffset to pntsd before proving a DACL header fits inside the returned security descriptor.

On 32-bit builds a malicious server can return dacloffset near U32MAX, wrap the derived DACL pointer below endofacl, and then slip past the later pointer-based bounds checks. buildsecdesc() and idmodetocifsacl() can then dereference DACL fields from the wrapped pointer in the chmod/chown rewrite paths.

Validate dacloffset numerically before building any DACL pointer and reuse the same helper at the three DACL entry points.

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

smb: client: validate the whole DACL before rewriting it in cifsacl

buildsecdesc() and idmodetocifsacl() derive a DACL pointer from a server-supplied dacloffset and then use the incoming ACL to rebuild the chmod/chown security descriptor.

The original fix only checked that the struct smbacl header fits before reading daclptr->size or daclptr->numaces. That avoids the immediate header-field OOB read, but the rewrite helpers still walk ACEs based on pdacl->numaces with no structural validation of the incoming DACL body.

A malicious server can return a truncated DACL that still contains a header, claims one or more ACEs, and then drive replacesidsandcopyaces() or setchmoddacl() past the validated extent while they compare or copy attacker-controlled ACEs.

Factor the DACL structural checks into validatedacl(), extend them to validate each ACE against the DACL bounds, and use the shared validator before the chmod/chown rebuild paths. parsedacl() reuses the same validator so the read-side parser and write-side rewrite paths agree on what constitutes a well-formed incoming DACL.

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

media: uvcvideo: Fix crash during unbind if gpio unit is in use

We used the wrong device for the device managed functions. We used the usb device, when we should be using the interface device.

If we unbind the driver from the usb interface, the cleanup functions are never called. In our case, the IRQ is never disabled.

If an IRQ is triggered, it will try to access memory sections that are already free, causing an OOPS.

We cannot use the function devmrequestthreadedirq here. The devm clean functions may be called after the main structure is released by uvcdelete.

Luckily this bug has small impact, as it is only affected by devices with gpio units and the user has to unbind the device, a disconnect will not trigger this error.

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

net: do not leave a dangling sk pointer, when socket creation fails

It is possible to trigger a use-after-free by: attaching an fentry probe to sockrelease() and the probe calling the bpfgetsocketcookie() helper running traceroute -I 1.1.1.1 on a freshly booted VM

A KASAN enabled kernel will log something like below (decoded and stripped): ================================================================== BUG: KASAN: slab-use-after-free in sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) Read of size 8 at addr ffff888007110dd8 by task traceroute/299

CPU: 2 PID: 299 Comm: traceroute Tainted: G E 6.10.0-rc2+ #2 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 Call Trace: dumpstacklvl (lib/dumpstack.c:117 (discriminator 1)) printreport (mm/kasan/report.c:378 mm/kasan/report.c:488) ? sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasanreport (mm/kasan/report.c:603) ? sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) kasancheckrange (mm/kasan/generic.c:183 mm/kasan/generic.c:189) sockgencookie (./arch/x86/include/asm/atomic6464.h:15 ./include/linux/atomic/atomic-arch-fallback.h:2583 ./include/linux/atomic/atomic-instrumented.h:1611 net/core/sockdiag.c:29) bpfgetsocketptrcookie (./arch/x86/include/asm/preempt.h:94 ./include/linux/sockdiag.h:42 net/core/filter.c:5094 net/core/filter.c:5092) bpfprog875642cf11f1d139sockrelease+0x6e/0x8e bpftrampoline6442506592+0x47/0xaf sockrelease (net/socket.c:652) sockcreate (net/socket.c:1601) ... Allocated by task 299 on cpu 2 at 78.328492s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasanslaballoc (mm/kasan/common.c:312 mm/kasan/common.c:338) kmemcacheallocnoprof (mm/slub.c:3941 mm/slub.c:4000 mm/slub.c:4007) skprotalloc (net/core/sock.c:2075) skalloc (net/core/sock.c:2134) inetcreate (net/ipv4/afinet.c:327 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1572) syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Freed by task 299 on cpu 2 at 78.328502s: kasansavestack (mm/kasan/common.c:48) kasansavetrack (mm/kasan/common.c:68) kasansavefreeinfo (mm/kasan/generic.c:582) poisonslabobject (mm/kasan/common.c:242) kasanslabfree (mm/kasan/common.c:256) kmemcachefree (mm/slub.c:4437 mm/slub.c:4511) skdestruct (net/core/sock.c:2117 net/core/sock.c:2208) inetcreate (net/ipv4/afinet.c:397 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1572) syssocket (net/socket.c:1660 net/socket.c:1644 net/socket.c:1706) x64syssocket (net/socket.c:1718) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)

Fix this by clearing the struct socket reference in skcommonrelease() to cover all protocol families create functions, which may already attached the reference to the sk object with sockinitdata().

btrfs: zoned: fix use-after-free due to race with dev replace

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

net/mlx5: Discard command completions in internal error

Fix use after free when FW completion arrives while device is in internal error state. Avoid calling completion handler in this case, since the device will flush the command interface and trigger all completions manually.

Kernel log: ------------[ cut here ]------------ refcountt: underflow; use-after-free. ... RIP: 0010:refcountwarnsaturate+0xd8/0xe0 ... Call Trace: <IRQ> ? warn+0x79/0x120 ? refcountwarnsaturate+0xd8/0xe0 ? reportbug+0x17c/0x190 ? handlebug+0x3c/0x60 ? excinvalidop+0x14/0x70 ? asmexcinvalidop+0x16/0x20 ? refcountwarnsaturate+0xd8/0xe0 cmdentput+0x13b/0x160 [mlx5core] mlx5cmdcomphandler+0x5f9/0x670 [mlx5core] cmdcompnotifier+0x1f/0x30 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 mlx5eqasyncint+0xf6/0x290 [mlx5core] notifiercallchain+0x35/0xb0 atomicnotifiercallchain+0x16/0x20 irqinthandler+0x19/0x30 [mlx5core] handleirqeventpercpu+0x4b/0x160 handleirqevent+0x2e/0x80 handleedgeirq+0x98/0x230 commoninterrupt+0x3b/0xa0 commoninterrupt+0x7b/0xa0 </IRQ> <TASK> asmcommoninterrupt+0x22/0x40