In the Linux kernel, the following vulnerability has been resolved:
mpls: fix NULL deref in mplsvalidfibdumpreq() on CONFIGINET=n
On CONFIGINET=n builds, mplsvalidfibdumpreq() walks the parsed attribute table itself instead of calling ipvalidfibdumpreq(). The RTAOIF arm passes tb[RTAOIF] to nlagetu32() without checking it is present, so an RTMGETROUTE dump for AFMPLS with strict checking and no RTAOIF hits a NULL dereference.
RTMGETROUTE is RTNLKINDGET, which rtnetlinkrcvmsg() permits without CAPNETADMIN, so an unprivileged user can trigger it.
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:mplsvalidfibdumpreq (net/mpls/afmpls.c:2189) Call Trace: mplsdumproutes (net/mpls/afmpls.c:2236) netlinkdump (net/netlink/afnetlink.c:2331) netlinkdumpstart (net/netlink/afnetlink.c:2446) rtnetlinkrcvmsg (net/core/rtnetlink.c:7033) netlinkrcvskb (net/netlink/afnetlink.c:2556) netlinkunicast (net/netlink/afnetlink.c:1345) netlinksendmsg (net/netlink/afnetlink.c:1900) socksendmsg (net/socket.c:790) syssendmsg (net/socket.c:2684) syssendmsg (net/socket.c:2738) syssendmsg (net/socket.c:2770) dosyscall64 (arch/x86/entry/syscall64.c:94) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:121)
Skip unset attributes, as ipvalidfibdumpreq() does.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: ndisc: fix NULL deref in acceptuntrackedna()
acceptuntrackedna() re-fetches the inet6dev with in6devget(dev) and dereferences idev->cnf.acceptuntrackedna without a NULL check, even though its only caller ndiscrecvna() already fetched and NULL-checked idev for the same device.
Both reads of dev->ip6ptr run in the same RCU read-side critical section, but a concurrent addrconfifdown() can clear dev->ip6ptr between them: lowering the MTU below IPV6MINMTU calls addrconfifdown() without the synchronizenet() that orders the unregister path, so the re-fetch returns NULL and oopses:
BUG: KASAN: null-ptr-deref in ndiscrecvna (net/ipv6/ndisc.c:974) Read of size 4 at addr 0000000000000364 Call Trace: <IRQ> ndiscrecvna (net/ipv6/ndisc.c:974) icmpv6rcv (net/ipv6/icmp.c:1193) ip6protocoldeliverrcu (net/ipv6/ip6input.c:479) ip6inputfinish (net/ipv6/ip6input.c:534) ip6input (net/ipv6/ip6input.c:545) ip6mcinput (net/ipv6/ip6input.c:635) ipv6rcv (net/ipv6/ip6input.c:351) </IRQ>
It is reachable by an unprivileged user via a network namespace.
Pass the caller's already validated idev instead of re-fetching it; the idev stays alive for the whole RCU critical section, so it is safe even after dev->ip6ptr has been cleared.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: clsapi: Handle TCACTCONSUMED in tcfqeventhandle
tcfclassify() can return TCACTCONSUMED while the skb is held by the defragmentation engine (e.g. actct on out-of-order fragments). When that happens the skb is no longer owned by the caller and must not be touched again.
tcfqeventhandle() did not handle TCACTCONSUMED: it fell through the switch and returned the skb to the caller as if classification had passed. The only qdisc that wires up qevents today is RED, via three call sites (qemark on REDPROBMARK/HARDMARK, qeearlydrop on congestiondrop) redenqueue() was continuing to operate on an skb it no longer owns in this case -- enqueueing it, dropping it, or updating statistics. Resulting in a UAF.
tc qdisc add dev eth0 root handle 1: red ... qevent earlydrop block 10 tc filter add block 10 ... action ct
(with ct defrag enabled and traffic that produces out-of-order fragments, e.g. a fragmented UDP stream)
Handle TCACTCONSUMED in tcfqeventhandle() the same way the ingress and egress fast paths do: treat it as stolen and return NULL without touching the skb. Unlike the TCACTSTOLEN case, the skb must not be dropped/freed here, as it is no longer owned by us.
In the Linux kernel, the following vulnerability has been resolved:
iio: event: Fix event FIFO reset race
iioeventgetfd() creates the event file descriptor with anoninodegetfd(), which allocates a new fd, creates the anonymous file and installs it in the process fd table before returning to the caller.
The IIO code resets the event FIFO after anoninodegetfd() has returned, but before IIOGETEVENTFDIOCTL has copied the fd number to userspace. But since fd tables are shared between threads, another thread can guess the newly allocated fd number and issue a read() on it as soon as the fd has been installed.
This means the kfifotouser() in iioeventchrdevread() can run in parallel with the kfiforesetout() in iioeventgetfd().
The kfifo documentation says that kfiforesetout() is only safe when it is called from the reader thread and there is only one concurrent reader. Otherwise it is dangerous and must be handled in the same way as kfiforeset().
If that happens, kfifotouser() can advance the FIFO out index based on state from before the reset, after the reset has already moved the out index to the current in index. That can leave the FIFO with an out index past the in index. A later read() can then see an underflowed FIFO length and copy more data than the event FIFO buffer contains. This can result in an out-of-bounds read and leak adjacent kernel memory to userspace.
Move the FIFO reset before anoninodegetfd(). At that point the event fd is marked busy, but the new fd has not been installed yet, so userspace cannot access it while the FIFO is reset.
In the Linux kernel, the following vulnerability has been resolved:
smb: client: mask server-provided mode to 07777 in modefromsid
When modefromsid is active, parsedacl() applies the server-provided subauth[2] value from the NFS mode SID to cfmode without masking to 07777. Apply the correct masking, same as in the read path.
In the Linux kernel, the following vulnerability has been resolved:
PCI: altera: Fix resource leaks on probe failure
The chained IRQ handler is set during probe, but is only removed during the driver remove(). If pcihostprobe() fails, the handler and INTx IRQ domain remain set even though the devm-managed host bridge storage containing struct alterapcie will be released, leaving the handler with a stale data pointer.
Interrupts are also enabled before pcihostprobe() is called. If probe fails after that point, the controller interrupt source should be disabled before the chained handler and INTx domain are removed.
So set the chained handler only after the INTx domain has been created. Disable controller interrupts during IRQ teardown, and tear the IRQ setup down if pcihostprobe() fails.
[mani: commit log]
In the Linux kernel, the following vulnerability has been resolved:
iouring/io-wq: re-check IOWQBITEXIT for each linked work item
commit 10dc95939817 ("iouring/io-wq: check IOWQBITEXIT inside work run loop") fixed the obvious case where ioworkerhandlework() took one exit-bit snapshot before draining pending work, but the fix stops one level too early.
ioworkerhandlework() now re-checks IOWQBITEXIT in its outer work run loop, yet it still snapshots that bit once before processing a whole dependent linked-work chain. If iowqexitstart() sets IOWQBITEXIT after the first linked item has started, the remaining linked items can still reuse stale dokill = false, skip IOWQWORKCANCEL, and continue running after exit has begun.
Move the check further inside, so it covers linked items too. Note: this is a syzbot special as it loves setting up tons of slow linked work on weird devices like msr that take forever to read, and immediately close the ring. Exit then takes a long time.
Bluetooth: btmtksdio: fix infinite loop in btmtksdiotxrxwork()
HID: appleir: fix UAF on pending keyuptimer in remove()
In the Linux kernel, the following vulnerability has been resolved:
net: usb: kalmia: bound RX frame length in kalmiarxfixup()
kalmiarxfixup() computes usbpacketlength = skb->len - (2 KALMIAHEADERLENGTH) as a u16, guarded only by a pre-loop check that skb->len is at least KALMIAHEADERLENGTH, which is 6. A device can deliver a short bulk-IN frame with skb->len in the 6 to 11 range, or leave a short trailing remainder on a later loop iteration. Either case underflows usbpacketlength to about 65530.
That bypasses the usbpacketlength < etherpacketlength truncation path. The device-supplied etherpacketlength, a le16 up to 65535 read from headerstart[2], then drives a memcmp() and the following skbtrim() and skbpull() past the end of the rx buffer. The rx buffer is hardmtu 10, which is 14000 bytes. That is an out of bounds read.
Require both the start and end framing headers to be present before subtracting them, on every loop iteration.
In the Linux kernel, the following vulnerability has been resolved:
usb: free iso schedules on failed submit
EHCI and FOTG210 isochronous submits build an ehciisosched before linking the URB to the endpoint queue, and keep the staged schedule in urb->hcpriv until isostreamschedule() and the link helpers consume it. If the controller is no longer accessible, or usbhcdlinkurbtoep() fails, submit jumps to donenotlinked before that handoff happens and leaks the staged schedule still attached to urb->hcpriv.
Free the staged schedule from donenotlinked when submit fails before the URB is linked and clear urb->hcpriv after the free.
The bug was first flagged by an experimental analysis tool we are developing for kernel memory-management bugs while analyzing v6.13-rc1. The tool is still under development and is not yet publicly available. Manual inspection confirms that the bug is still present in v7.1.1.
An x8664 allyesconfig build showed no new warnings. As we do not have an EHCI host controller with a USB isochronous device to test with, no runtime testing was able to be performed.
In the Linux kernel, the following vulnerability has been resolved:
USB: ulpi: fix memory leak on registration failure
The allocated device name is never freed on early ULPI device registration failures.
Fix this by initialising the device structure earlier and releasing the initial reference whenever registration fails.
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Move vevent memory allocation outside spinlock
The veventq memory allocation happens inside the spinlock. Given its depth is decided by the user space, this leaves a vulnerability, where userspace can allocate large queues to exhaust atomic memory reserves.
Move the allocation outside the spinlock and use GFPNOWAIT, which can fail fast under memory pressure without dipping into the GFPATOMIC reserves or direct-reclaiming from the threaded IRQ handler. On allocation failure, queue the losteventsheader (so userspace learns of the drop) and return -ENOMEM so the caller learns of the kernel-side memory pressure.
This is intentionally distinct from the queue-overflow path, which also queues the losteventsheader but returns 0: a full queue is an expected userspace-pacing condition rather than a kernel error.
A subsequent change will cap the upper bound of the veventqdepth.
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Set upper bounds on cache invalidation entrynum and entrylen
iommufdhwptinvalidate() takes a user-controlled entrynum and entrylen, each bounded only by U32MAX. An entrylen beyond the kernel's struct size makes the copy helper verify the extra bytes are zero, scanning that excess in one uninterruptible pass; a multi-gigabyte value over zeroed user memory trips the soft-lockup watchdog.
A large entrynum is the other half, driving the backend invalidation loop with no reschedule. The VT-d nested handler, for one, copies each entry and flushes caches per iteration, pinning the CPU on a non-preemptible kernel.
Cap both in the ioctl. entrylen is held under PAGESIZE, above any request struct, and entrynum under 1 << 19, the order of a hardware invalidation queue and well beyond any real batch, bounding the per-call loop length.
In the Linux kernel, the following vulnerability has been resolved:
KVM: SEV: Pin source page for write when adding CPUID data for SNP guest
When populating a guestmemfd instance with the initial CPUID data for an SNP guest, acquire a writable pin on the source page as KVM will write back the "correct" CPUID information if the userspace provided data is rejected by trusted firmware. Because KVM writes to the source page using a kernel mapping, pinning for read could result in KVM clobbering read-only memory.
Note, well-behaved VMMs are unlikely to be affected, as CPUID information is almost always dynamically generated by userspace, i.e. it's unlikely for the CPUID information to be backed by a read-only mapping.
[sean: rewrite shortlog and changelog, tag for stable@]
In the Linux kernel, the following vulnerability has been resolved:
i2c: imx-lpi2c: mark I2C adapter when hardware is powered down
On some i.MX platforms, certain I2C client drivers keep a periodic workqueue which continues to trigger I2C transfers.
During system suspend/resume, there exists a time window between: - suspendnoirq and the system entering suspend - the system starting to resume and resumenoirq
In this window, the I2C controller resources such as clock and pinctrl may already be disabled or not yet restored.
If a workqueue triggers an I2C transfer in this period, the driver attempts to access I2C registers while the hardware resources are unavailable, which may lead to system hang.
Mark the I2C adapter as suspended during noirq suspend and block new transfers until resume, ensuring that I2C transfers are only issued when hardware resources are available.
In the Linux kernel, the following vulnerability has been resolved:
Input: elani2c - prevent division by zero and arithmetic underflow
The Elan I2C touchpad driver queries the device for its physical dimensions and trace counts to calculate the device resolution and width. However, if the device firmware or device tree provides invalid zero values for xtraces or ytraces, it results in a fatal division-by-zero exception leading to a kernel panic during device probe.
Add checks to ensure these parameters are non-zero before performing the division. If invalid trace values are detected, fall back to a safe default of 1.
Additionally, prevent an arithmetic underflow in the touch reporting logic. Previously, if the calculated or fallback width was smaller than ETPFWIDTHREDUCE (90), the subtraction would underflow, resulting in a massive unsigned integer being reported to userspace. Clamp the adjusted width to a minimum of 0 to safely handle small physical dimensions and fallback scenarios.
Completing the probe with safe fallback values ensures the sysfs nodes are created, keeping the firmware update path intact so a recovery firmware can be flashed to the device.
In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: fix moving cancelled entry to entinuserspace list
fuseuringcancel() moves entries that are available (these have no reqs attached) to the entinuserspace list. entlistrequestexpired() checks the first entry on entinuserspace and dereferences ent->fusereq unconditionally, which will crash on a cancelled entry that was moved to this list.
Fix this by freeing the entry and dropping queuerefs directly in fuseuringcancel(). This is safe because cancel is the cancel handler itself - after iouringcmddone(), no more cancels will be dispatched for this command, and teardown serializes with cancel via queue->lock.
Since cancel now decrements queuerefs, fuseuringabort() must no longer gate fuseuringabortendrequests() on queuerefs > 0, as cancelled entries may have already dropped queuerefs while requests are still queued. Remove the gate so abort always flushes requests and stops queues.
In the Linux kernel, the following vulnerability has been resolved:
fuse-uring: end fusereq on io-uring cancel task work
When iouring delivers task work with tw.cancel set (PFEXITING, PFKTHREAD fallback, or percpurefisdying on the ring context), fuseuringsendintask() takes the cancel branch, assigns -ECANCELED, and falls through to fuseuringsend(). That path only flips the entry to FRRSUSERSPACE and completes the iouring cmd; it never discharges the ring entry's owning reference to the fusereq that fuseuringaddreqtoringent() handed it at dispatch time.
fuseuringsendintask() tw.cancel == true err = -ECANCELED fuseuringsend(ent, cmd, err, issueflags) ent->state = FRRSUSERSPACE listmove(&ent->list, &queue->entinuserspace) ent->cmd = NULL iouringcmddone(-ECANCELED) / ent->fusereq still set, req still hashed /
The fusereq stays linked on fpq->processing[hash] and fuserequestend() is never invoked. The originating syscall thread blocks in D-state in requestwaitanswer() until fuseabortconn() runs, which can be the entire connection lifetime. For FRBACKGROUND requests fc->numbackground is never decremented either, so repeated cancels inflate the counter until maxbackground is hit and all later background ops stall. tw.cancel does not imply a connection abort (e.g. a single iouring worker thread exits while the fuse connection stays up), so this cannot be left for fuseabortconn() to clean up.
Ending the req but still routing the entry through fuseuringsend() is not enough: that leaves a req-less entry on entinuserspace, and entlistrequestexpired() dereferences ent->fusereq unconditionally on the head of that list, which would then NULL-deref.
Fix the cancel branch to release the entry directly. Remove it from the queue, complete the iouring cmd, end the fusereq, free the entry, and drop its queuerefs (waking the teardown waiter if it was the last).
In the Linux kernel, the following vulnerability has been resolved:
NTB: epf: Avoid pciiounmap() with offset when PEERSPAD and CONFIG share BAR
When BARPEERSPAD and BARCONFIG share one PCI BAR, the module teardown path ends up calling pciiounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following:
Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pciiounmap+0x2c/0x40 ntbepfpciremove+0x44/0x80 [ntbhwepf] pcideviceremove+0x48/0xf8 deviceremove+0x50/0x88 devicereleasedriverinternal+0x1c8/0x228 driverdetach+0x50/0xb0 busremovedriver+0x74/0x100 driverunregister+0x34/0x68 pciunregisterdriver+0x34/0xa0 ntbepfpcidriverexit+0x14/0xfe0 [ntbhwepf] [...]
Fix it by unmapping only when PEERSPAD and CONFIG use difference bars.
In the Linux kernel, the following vulnerability has been resolved:
kernel/fork: clear PFBLOCKTS in copyprocess()
PFBLOCKTS is only set in blktimegetns() when current->plug is non-NULL, and blkfinishplug() clears it via blkflushplug() before NULLing the plug pointer. copyprocess() breaks the invariant by inheriting PFBLOCKTS from the parent while resetting the child's plug to NULL.
Clear PFBLOCKTS alongside that assignment so callers can rely on "PFBLOCKTS set implies current->plug != NULL" and dereference current->plug unguarded.
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Report dying CPU to RCU in stopthiscpu()
This is a port of MIPS commit 9f3f3bdc6d9dac1 ("MIPS: smp: report dying CPU to RCU in stopthiscpu()"). smpsendstop() parks all secondary CPUs in stopthiscpu(). And the function marks the CPU offline for the scheduler via setcpuonline(false) but never informs RCU, so RCU keeps expecting a quiescent state from CPUs that are now spinning forever with interrupts disabled.
As long as nothing waits for an RCU grace period after smpsendstop() this is harmless, which is why it went unnoticed. However, since commit 91840be8f710370 ("irqwork: Fix use-after-free in irqworksingle() on PREEMPTRT"), irqworksync() calls synchronizercu() on architectures without an irqwork self-IPI, i.e. where archirqworkhasinterrupt() returns false. Any irqworksync() issued in the reboot/shutdown/halt path after smpsendstop() then blocks on a grace period that can never complete, hanging the reboot:
WARNING: CPU: 0 PID: 15 at kernel/irqwork.c:144 irqworkqueueon ... rcu: INFO: rcusched detected stalls on CPUs/tasks: rcu: Offline CPU 1 blocking current GP. rcu: Offline CPU 2 blocking current GP. rcu: Offline CPU 3 blocking current GP.
This issue needs some hacks to reproduce, and it was not noticed on LoongArch because archirqworkhasinterrupt() usually returns true.
Call rcutreereportcpudead() once interrupts are disabled, mirroring the generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs and grace periods can still complete. LoongArch shuts down all CPUs here without going through the CPU-hotplug mechanism, so this report is not otherwise issued.
In the Linux kernel, the following vulnerability has been resolved:
MIPS: smp: report dying CPU to RCU in stopthiscpu()
smpsendstop() parks all secondary CPUs in stopthiscpu(). The function marks the CPU offline for the scheduler via setcpuonline(false) but never informs RCU, so RCU keeps expecting a quiescent state from CPUs that are now spinning forever with interrupts disabled.
As long as nothing waits for an RCU grace period after smpsendstop() this is harmless, which is why it went unnoticed. Since commit 91840be8f710 ("irqwork: Fix use-after-free in irqworksingle() on PREEMPTRT") however, irqworksync() calls synchronizercu() on architectures without an irqwork self-IPI, i.e. where archirqworkhasinterrupt() returns false. That is the asm-generic default used by MIPS. Any irqworksync() issued in the reboot/shutdown path after smpsendstop() then blocks on a grace period that can never complete, hanging the reboot:
WARNING: CPU: 0 PID: 15 at kernel/irqwork.c:144 irqworkqueueon ... rcu: INFO: rcusched detected stalls on CPUs/tasks: rcu: Offline CPU 1 blocking current GP. rcu: Offline CPU 2 blocking current GP. rcu: Offline CPU 3 blocking current GP.
This issue was noticed on several Realtek MIPS switch SoCs (MIPS interAptiv) and came up during kernel bump downstream in OpenWrt from 6.18.33 to 6.18.34, after the backport of the patch to the 6.18 stable branch. The patch also has been backported all the way back to 6.1.
Call rcutreereportcpudead() once interrupts are disabled, mirroring the generic CPU-hotplug offline path, so RCU stops waiting on the parked CPUs and grace periods can still complete. MIPS shuts down all CPUs here without going through the CPU-hotplug mechanism, so this report is not otherwise issued. Reporting a dying CPU to RCU outside the regular hotplug offline path is not unprecedented: arm64 does the same in cpudieearly(). There it is an exception for a CPU that was coming online and is aborting bringup, rather than the default shutdown action as on MIPS.
drivers/base/memory: set mem->altmap after successful device registration
In the Linux kernel, the following vulnerability has been resolved:
gpio: shared: fix deadlock on shared proxy's parent removal
Commit 710abda58055 ("gpio: shared: call gpiochip::ofxlate() if set") used the mutex embedded in struct gpiosharedentry to protect the offset field which now can be modified after assignment. The critical section however is too wide and introduced a potential deadlock on the removal of the shared GPIO proxy's parent.
Make the critical section shorter - only protect the offset when it's being read.
While at it: mention the fact that the entry lock is now also used to protect against concurrent access to the offset field in the structure's documentation.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dsi: don't dump registers past the mapped region
On DSI 6G platforms the IO address space is internally adjusted by iooffset. Later this adjusted address might be used for memory dumping. However the size that is used for memory dumping isn't adjusted to account for the iooffset, leading to the potential access to the unmapped region. Lower ctrlsize by the iooffset value to prevent access past the mapped area.
msmdispsnapshotaddblock+0x1d4/0x3c8 [msm] (P) msmdsihostsnapshot+0x4c/0x78 [msm] msmdsisnapshot+0x28/0x50 [msm] msmdispsnapshotcapturestate+0x74/0x140 [msm] msmdispsnapshotstatesync+0x60/0x90 [msm] msmdispsnapshotwork+0x30/0x90 [msm] kthreadworkerfn+0xdc/0x460 kthread+0x120/0x140
Patchwork: https://patchwork.freedesktop.org/patch/721747/
In the Linux kernel, the following vulnerability has been resolved:
net: team: fix NULL pointer dereference in teamxmit during mode change
teamchangemode() clears team->ops with memset() before restoring safe dummy handlers via teamadjustops(). A concurrent teamxmit() running under RCU on another CPU can read team->ops.transmit during this window and call a NULL function pointer, crashing the kernel.
The race requires a mode change (CAPNETADMIN) concurrent with transmit on the team device.
BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: 0010 [#1] SMP KASAN NOPTI RIP: 0010:0x0 Call Trace: teamxmit (drivers/net/team/teamcore.c:1853) devhardstartxmit (net/core/dev.c:3904) devqueuexmit (net/core/dev.c:4871) packetsendmsg (net/packet/afpacket.c:3109) syssendto (net/socket.c:2265)
The original code assumed that no ports means no traffic, so mode changes could freely memset()/memcpy() the ops. AFPACKET with forced carrier breaks that assumption.
Prevent the race instead of making it safe: replace memset()/memcpy() with per-field updates that never touch transmit or receive. Those two handlers are managed solely by teamadjustops(), which already installs dummies when txenportcount == 0 (always true during mode change since no ports are present). WRITEONCE/READONCE prevent store/load tearing on the handler pointers.
synchronizenet() before exitop() drains in-flight readers that may still reference old mode state from before port removal switched the handlers to dummies.
In the Linux kernel, the following vulnerability has been resolved:
xfs: fail recovery on a committed log item with no regions
If the first op of a transaction is a bare transaction header (len == sizeof(struct xfstransheader)), xlogrecoveraddtotrans() adds an item but no region, leaving it on ritemq with ricnt == 0 and ribuf == NULL.
The header can be split across op records, so later ops may still add regions; the item is only invalid if the transaction commits with none. The runtime commit path never emits such a transaction, so this only happens on a crafted log. It came from an AI-assisted code audit of the recovery parser.
xlogrecoverreordertrans() calls ITEMTYPE() on the item, which reads (unsigned short )item->ribuf[0].iovbase and faults on the NULL ribuf. Reject it there, before the commit handlers that also read ribuf[0].
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:xlogrecoverreordertrans (fs/xfs/xfslogrecover.c:1836) xlogrecovercommittrans (fs/xfs/xfslogrecover.c:2043) xlogrecoverprocessdata (fs/xfs/xfslogrecover.c:2501) xlogdorecoverypass (fs/xfs/xfslogrecover.c:3244) xlogrecover (fs/xfs/xfslogrecover.c:3493) xfslogmount (fs/xfs/xfslog.c:618) xfsmountfs (fs/xfs/xfsmount.c:1034) xfsfsfillsuper (fs/xfs/xfssuper.c:1938) vfsgettree (fs/super.c:1695) pathmount (fs/namespace.c:4161) x64sysmount (fs/namespace.c:4367)
In the Linux kernel, the following vulnerability has been resolved:
net/smc: reject CHID-0 ACCEPT that matches an empty ismdev slot
On the SMC-D client, slot 0 of ini->ismdev[]/ini->ismchid[] is reserved for an SMC-Dv1 device. smcfindismv2deviceclnt() populates V2 entries starting at index 1, so when no V1 device is selected slot 0 is left in its kzalloc()'ed state with ismdev[0] == NULL and ismchid[0] == 0.
smcv2determineacceptedchid() then matches the peer's CHID against the array starting from index 0 using the CHID alone. A malicious peer replying to a SMC-Dv2-only proposal with d1.chid == 0 matches the empty slot, ini->ismselected becomes 0, and the subsequent ismdev[0]->lgrlock dereference in smcconncreate() faults at offsetof(struct smcddev, lgrlock) == 0x68:
BUG: KASAN: null-ptr-deref in rawspinlockbh+0x79/0xe0 Write of size 4 at addr 0000000000000068 by task exploit/144 Call Trace: rawspinlockbh smcconncreate (net/smc/smccore.c:1997) smcconnect (net/smc/afsmc.c:1447) smcconnect (net/smc/afsmc.c:1720) sysconnect x64sysconnect dosyscall64
Require ismdev[i] to be non-NULL before accepting a CHID match.
In the Linux kernel, the following vulnerability has been resolved:
spi: ep93xx: fix error pointer deref after DMA setup failure
The driver falls back to PIO mode if DMA setup fails during probe.
Make sure to the clear the DMA channel pointers on setup failure to avoid dereferencing an error pointer on later probe errors or driver unbind.
This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.