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

net: ieee802154: do not leave a dangling sk pointer in ieee802154create()

sockinitdata() attaches the allocated sk object to the provided sock object. If ieee802154create() fails later, the allocated sk object is freed, but the dangling pointer remains in the provided sock object, which may allow use-after-free.

Clear the sk pointer in the sock object on error.

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:

crypto: ccp - copy IV using skcipher ivsize

AFALG rfc3686-ctr-aes-ccp requests pass an 8-byte IV to the driver.

ccpaescomplete() restores AESBLOCKSIZE bytes into the caller's IV buffer while RFC3686 skciphers expose an 8-byte IV, so the restore overruns the provided buffer.

Use cryptoskcipherivsize() to copy only the algorithm's IV length.

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

pdscore: fix debugfslookup dentry leak and error handling

debugfslookup() returns a dentry with an elevated reference count that must be released with dput(). The current code discards the returned dentry without calling dput(), causing a reference leak on every firmware reset recovery.

Additionally, when CONFIGDEBUGFS is disabled, debugfslookup() returns ERRPTR(-ENODEV), not NULL. The current check passes for error pointers and would call dput() on an invalid pointer, causing a crash.

drivers/base/memory: set mem->altmap after successful device registration

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

dma-mapping: move dmamapresource() sanity check into debug code

dmamapresource() uses pfnvalid() to ensure the range is not RAM. However, pfnvalid() only checks for availability of the memory map for a PFN but it does not ensure that the PFN is actually backed by RAM. On ARM64 with SPARSEMEM (128MB section granularity), MMIO addresses that share a section with RAM will falsely trigger the WARNONONCE and cause dmamapresource() to return DMAMAPPINGERROR.

This causes a WARNING on Raspberry Pi 4 during spibcm2835 probe because the SPI FIFO register (0xfe204004) falls in the same sparsemem section as the end of RAM (0xf8000000-0xfbffffff), both in section 31 (0xf8000000-0xffffffff).

Move the sanity check from dmamapresource() into debugdmamapphys() and replace the unreliable pfnvalid() with pfnvalid() && !PageReserved(), which correctly identifies actual usable RAM without false positives for MMIO regions that happen to have struct pages.

Since dmamapresource() is dmamapphys(DMAATTRMMIO), the check applies equally to both APIs. Any non-reserved page represents kernel memory to a sufficient degree that using DMAATTRMMIO on it is almost certainly wrong and risks breaking coherency on non-coherent platforms. ZONEDEVICE pages used for PCI P2P DMA (MEMORYDEVICEPCIP2PDMA) have PageReserved set, so they will not trigger a false positive.

The check no longer blocks the mapping and uses errprintk() to integrate with dma-debug filtering.

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

netfs: Fix zeropoint update where isize > remoteisize

Fix the update of the zero point[] by netfsreleasefolio() when there is uncommitted data in the pagecache beyond the folio being released but the on-server EOF is in this folio (ie. isize > remoteisize). The update needs to limit zeropoint to remoteisize, not isize as isize is a local phenomenon reflecting updates made locally to the pagecache, not stuff written to the server. remoteisize tracks the server's isize.

[] The zero point is the file position from which we can assume that the server will just return zeros, so we can avoid generating reads.

Note that netfsinvalidatefolio() probably doesn't need fixing as zeropoint should be updated by setattr after truncation or fallocate.

Found with:

fsx -q -N 1000000 -p 10000 -o 128000 -l 600000 \ /xfstest.test/junk --replay-ops=junk.fsxops

using the following as junk.fsxops:

truncate 0x0 0x1bbae 0x82864 write 0x3ef2e 0xf9c8 0x1bbae write 0x67e05 0xcb5a 0x4e8f6 mapread 0x57781 0x85b6 0x7495f copyrange 0x5d3d 0x10329 0x54fac 0x7495f write 0x64710 0x1c2b 0x7495f mapread 0x64000 0x1000 0x7495f

on cifs with the default cache option.

It shows read-gaps on folio 0x64 failing with a short read (ie. it hits EOF) if the FMODEREAD check is commented out in netfsperformwrite():

if (//(file->fmode & FMODEREAD) || netfsiscacheenabled(ctx)) {

and no fscache. This was initially found with the generic/522 xfstest.

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: 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:

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:

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:

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:

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:

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.

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:

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:

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:

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:

media: vidtv: fix NULL pointer dereference in vidtvmuxpushsi

syzbot reported a general protection fault in vidtvpsitspsiwriteinto [1].

vidtvmuxgetpidctx() can return NULL, but vidtvmuxpushsi() does not check for this before dereferencing the returned pointer to access the continuity counter. This leads to a general protection fault when accessing a near-NULL address.

The root cause is that vidtvmuxpidctxinit() does not check the return value of vidtvmuxcreatepidctxonce() for PMT section PIDs. If the allocation fails, the PID context is never created, but init returns success. The subsequent vidtvmuxpushsi() call then gets NULL from vidtvmuxgetpidctx() and crashes.

Fix both the root cause (add error check in vidtvmuxpidctxinit for PMT PIDs) and add defensive NULL checks in vidtvmuxpushsi for all vidtvmuxgetpidctx() calls.

[1] Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN PTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] Workqueue: events vidtvmuxtick RIP: 0010:vidtvpsitspsiwriteinto+0x54a/0xbc0 drivers/media/test-drivers/vidtv/vidtvpsi.c:197 Call Trace: <TASK> vidtvpsitableheaderwriteinto drivers/media/test-drivers/vidtv/vidtvpsi.c:799 [inline] vidtvpsipmtwriteinto+0x3b2/0xa70 drivers/media/test-drivers/vidtv/vidtvpsi.c:1231 vidtvmuxpushsi+0x932/0xe80 drivers/media/test-drivers/vidtv/vidtvmux.c:196 vidtvmuxtick+0xe9b/0x1480 drivers/media/test-drivers/vidtv/vidtvmux.c:408

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

crypto: seqiv - Do not use req->iv after cryptoaeadencrypt

As soon as cryptoaeadencrypt is called, the underlying request may be freed by an asynchronous completion. Thus dereferencing req->iv after it returns is invalid.

Instead of checking req->iv against info, create a new variable unalignedinfo and use it for that purpose instead.

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

arm64: errata: Add Cortex-A520 speculative unprivileged load workaround

Implement the workaround for ARM Cortex-A520 erratum 2966298. On an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged load via a cache side channel. The issue only exists for loads within a translation regime with the same translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0.

The workaround is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to any address is sufficient.

The workaround isn't necessary if page table isolation (KPTI) is enabled, but for simplicity it will be. Page table isolation should normally be disabled for Cortex-A520 as it supports the CSV3 feature and the E0PD feature (used when KASLR is enabled).