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.

gpio: rockchip: teardown bugs and resource leaks

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

media: rc: igorplugusb: fix control request setup packet

Commit eac69475b01f ("media: rc: igorplugusb: heed coherency rules") changed the control request storage from an embedded struct to an allocated pointer so it can obey DMA coherency rules.

However, the driver still passes &ir->request to usbfillcontrolurb(). That points the URB setup packet at the pointer field itself rather than at the allocated struct usbctrlrequest.

USB core then interprets pointer bytes as the setup packet. This can produce an invalid bRequestType and trigger the control direction warning reported by syzbot:

usb 2-1: BOGUS control dir, pipe 80003580 doesn't match bRequestType 0

Pass ir->request itself as the setup packet.

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:

i2c: davinci: fix division by zero on missing clock-frequency

When the 'clock-frequency' property is missing from the device tree, the driver falls back to DAVINCII2CDEFAULTBUSFREQ. However, this macro was defined in kHz (100), whereas the device tree property is expected in Hz.

The probe function divided the fallback value by 1000, causing integer truncation that resulted in dev->busfreq = 0. This triggered a deterministic division-by-zero kernel panic when calculating clock dividers later in the probe sequence.

Fix this by redefining DAVINCII2CDEFAULTBUSFREQ in Hz (100000) to match the expected device tree property unit, allowing the existing division logic to work correctly for both cases.

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

tty: serial: pchuart: add check for dmaalloccoherent()

Add a check for dmaalloccoherent() failure to prevent a potential NULL pointer dereference in dmahandlerx(). Properly release DMA channels and the PCI device reference using a goto ladder if the allocation fails.

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

usb: gadget: uvc: hold opts->lock across XU walks in uvcfunctionbind

uvcfunctionbind() walks &opts->extensionunits twice without holding opts->lock:

- directly, for the iExtension string-descriptor fixup loop; - indirectly, four times via uvccopydescriptors() (once per speed), where the helper iterates uvc->desc.extensionunits (which aliases &opts->extensionunits) to size and emit XU descriptors.

The configfs side (uvcgextensionmake / uvcgextensiondrop, in drivers/usb/gadget/function/uvcconfigfs.c) takes opts->lock around its listaddtail / listdel operations. A privileged userspace process that holds the configfs subtree open and writes the gadget UDC name to bind the function while concurrently rmdir()'ing an extensions subdir can race uvcgextensiondrop() against the bind-time list walks and dereference a freed struct uvcgextension.

Hold opts->lock from the start of the XU string-descriptor fixup through the last uvccopydescriptors() call, releasing on the descriptor-error path via a new errorunlock label that drops the lock before falling through to the existing error label. This matches the locking discipline of the configfs callbacks and removes the only remaining unsynchronised reader of the XU list during bind.

Reachability: only privileged processes that can mount configfs and write to gadget UDC files can trigger the race, so this is a correctness fix rather than a security boundary.

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:

x86/mm: Disable broadcast TLB flush when PCID is disabled

Booting with "nopcid" clears X86FEATUREPCID and keeps CR4.PCIDE from being set to one. On AMD CPUs that support INVLPGB, broadcast TLB flushing remains enabled.

There are two checks that decide whether the global ASID code runs, mmglobalasid() and considerglobalasid(), that key off of the X86FEATUREINVLPGB feature. Once an mm becomes active on more than three CPUs, considerglobalasid() assigns it a global ASID, after which flushtlbmmrange() takes the broadcasttlbflush() path using a non-zero PCID. Issuing an INVLPGB with a non-zero PCID while CR4.PCIDE is not set results in a #GP:

Oops: general protection fault, kernel NULL pointer dereference 0x1: 0000 [#1] SMP NOPTI CPU: 158 UID: 0 PID: 3119 Comm: snap Not tainted 7.1.0-rc3 #1 PREEMPT(full) Hardware name: ... RIP: 0010:broadcasttlbflush Code: ... 89 da 48 83 c8 07 <0f> 01 fe eb 08 cc cc cc ... Call Trace: <TASK> flushtlbmmrange ptepclearflush wppagecopy ? rawspinunlock handlemmfault handlemmfault douseraddrfault excpagefault asmexcpagefault

All processors that support broadcast TLB invalidation also have PCID support, so it is only the "nopcid" scenario that is of concern. In this situation just disable the broadcast TLB support using the CPUID dependency support by making X86FEATUREINVLPGB dependent on X86FEATUREPCID.

[ bp: Massage commit message. ]

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

regulator: tps65219: fix irqdata.rdev not being assigned

Commit 64a6b577490c ("regulator: tps65219: Remove debugging helper function") removed the tps65219getrdevbyname() helper along with the irqdata.rdev assignment that depended on it. This left irqdata.rdev uninitialized for all IRQs, causing undefined behavior when regulatornotifiercallchain() is called from the IRQ handler:

Internal error: Oops: 0000000096000004 pc : regulatornotifiercallchain lr : tps65219regulatorirqhandler Call trace: regulatornotifiercallchain tps65219regulatorirqhandler handlenestedirq regmapirqthread irqthreadfn irqthread kthread retfromfork

Instead of restoring a dedicated lookup array, restructure the probe function to combine regulator registration with IRQ registration in the same loop. This way the rdev returned by devmregulatorregister() is naturally available for assigning to irqdata.rdev without any auxiliary data structure.

Non-regulator IRQs (SENSOR, TIMEOUT) that don't correspond to any registered regulator are registered with rdev=NULL, and the IRQ handler is protected with a NULL check to avoid crashing.

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

device property: set fwnode->secondary to NULL in fwnodeinit()

If a firmware node is allocated on the stack (for instance: temporary software node whose life-time we control) or on the heap - but using a non-zeroing allocation function - and initialized using fwnodeinit(), its secondary pointer will contain uninitalized memory which likely will be neither NULL nor ISERR() and so may end up being dereferenced (for example: in devtoswnode()). Set fwnode->secondary to NULL on initialization.

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

drm/msm/a6xx: Check kzalloc return in a8xxhfisendperftable

Check the return value of kzalloc() to prevent a NULL pointer dereference on allocation failure.

Patchwork: https://patchwork.freedesktop.org/patch/721342/

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

wifi: iwlwifi: mld: don't dereference a pointer before NULL checking it

In iwlmldremovelink, the link->fwid is saved at the beginning of the function so we have it after we freed the link.

But the link pointer can be NULL, and is not checked when the fwid is stored.

Fix it by simply freeing the link at the end of the function.

fFixes: 0e66a39f4f0e ("wifi: iwlwifi: fix potential use after free in iwlmldremovelink()")

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

srcu: Don't queue workqueue handlers to never-online CPUs

While an srcustruct structure is in the midst of switching from CPU-0 to all-CPUs state, it can attempt to invoke callbacks for CPUs that have never been online. Worse yet, it can attempt in invoke callbacks for CPUs that never will be online, even including imaginary CPUs not in cpupossiblemask. This can cause hangs on s390, which is not set up to deal with workqueue handlers being scheduled on such CPUs. This commit therefore causes Tree SRCU to refrain from queueing workqueue handlers on CPUs that have not yet (and might never) come online.

Because callbacks are not invoked on CPUs that have not been online, it is an error to invoke callsrcu(), synchronizesrcu(), or synchronizesrcuexpedited() on a CPU that is not yet fully online. However, it turns out to be less code to redirect the callbacks from too-early invocations of callsrcu() than to warn about such invocations. This commit therefore also redirects callbacks queued on not-yet-fully-online CPUs to the boot CPU.

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:

sysfs: don't remove existing directory on update failure

When sysfsupdategroup() is called for a named group and createfiles() fails (e.g. -ENOMEM), internalcreategroup() calls kernfsremove(kn) on the group directory. In the update path, kn was obtained via kernfsfindandget() and refers to a directory that already existed before this call. Removing it silently destroys a sysfs group that the caller did not create.

Only remove the directory if we created it ourselves. On update failure the directory remains as it is left empty by removefiles() inside createfiles(), but can be repopulated by a retry.

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

mm/damon/sysfs-schemes: call missing memcgroupiterbreak()

damonsysfsmemcgpathtoid() breaks memcgroupiter() loop without calling memcgroupiterbreak(). This leaks the cgroup reference. Fix the issue by calling memcgroupiterbreak() before the break.

The issue was discovered [1] by Sashiko.

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

drivers/base/memory: fix memory block reference leak in poison accounting

memblknrpoisoninc() and memblknrpoisonsub() look up a memory block via findmemoryblockbyid(), which acquires a reference to the memory block device.

Both helpers use the returned memory block without dropping that reference, leaking the device reference on each successful lookup. Drop the reference after updating nrhwpoison.

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

efi: Allocate runtime workqueue before ACPI init

Since commit

5894cf571e14 ("acpi/prmt: Use EFI runtime sandbox to invoke PRM handlers")

ACPI PRM calls are delegated to a workqueue which runs in a kernel thread, making it easier to detect and mitigate faulting memory accesses performed by the firmware.

Rafael reports that such PRM accesses may occur before efisubsysinit() executes, which is where the workqueue is allocated, leading to NULL pointer dereferences. Since acpiinit() [which triggers the early PRM accesses] executes as a subsysinitcall() as well, and has its own dependencies that may be sensitive to initcall ordering, deferring acpiinit() is not an option.

So instead, split off the workqueue allocation into its own postcore initcall, as this is the only missing piece to allow EFI runtime calls to be made. This ensures that EFI runtime call (including PRM calls) are accessible to all code running at subsysinitcall() level.

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

mm/memoryhotplug: fix memory block reference leak on remove

Patch series "mm: Fix memory block leaks and locking", v2.

This series fixes two memory block device reference leaks and one locking issue around the per-memoryblock hwpoison counter.

This patch (of 2):

removememoryblocksandaltmaps() looks up each memory block with findmemoryblock(), which acquires a reference to the memory block device.

That reference is never dropped on this path, resulting in a leaked device reference when removing memory blocks and their altmaps. Drop the reference after retrieving mem->altmap and clearing mem->altmap, before removing the memory block device.

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

net: wwan: iosm: fix potential memory leaks in ipcimeminit()

The memory allocated in ipcprotocolinit() is not freed on the error paths that follow in ipcimeminit(). Fix that by calling the corresponding release function ipcprotocoldeinit() in the error path.

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

phonet/pep: disable BH around forwarded skreceiveskb()

The networking receive path is usually run from softirq context, but protocols that take the socket lock may have packets stored in the backlog and processed later from process context. In that case releasesock() -> releasesock() drops the slock with spinunlockbh() and then calls sk->skbacklogrcv() with bottom halves enabled.

Typical skbacklogrcv handlers process the socket whose backlog is being drained, so the BH state at entry is irrelevant for the slocks they touch. pepdorcv() is different: when the inbound skb targets an existing PEP pipe, it forwards the skb to a different child socket via skreceiveskb(). That helper takes the child slock with bhlocksocknested(), which is just spinlocknested() and assumes BH is already off. The same child slock therefore ends up acquired with BH on (process path) and with BH off (softirq path):

process context softirq context --------------- --------------- releasesock(listener) netifreceiveskb() releasesock() phonetrcv() spinunlockbh() skreceiveskb(listener) [BH now ENABLED] [BH already disabled] skbacklogrcv: skbacklogrcv: pepdorcv() pepdorcv() skreceiveskb(child) skreceiveskb(child) bhlocksocknested(child) bhlocksocknested(child) => SOFTIRQ-ON-W => IN-SOFTIRQ-W

Lockdep flags this as inconsistent lock state, and it can become a real self-deadlock if a softirq on the same CPU tries to receive to the same child socket while its slock is held in the BH-enabled path:

WARNING: inconsistent lock state inconsistent {SOFTIRQ-ON-W} -> {IN-SOFTIRQ-W} usage. (slock-AFPHONET/1){+.?.}-{3:3}, at: skreceiveskb+0x1cf/0x900 skreceiveskb net/core/sock.c:563 skreceiveskb include/net/sock.h:2022 [inline] pepdorcv net/phonet/pep.c:675 skbacklogrcv include/net/sock.h:1190 releasesock net/core/sock.c:3216 releasesock net/core/sock.c:3815 pepsockaccept net/phonet/pep.c:879

Wrap the forwarded skreceiveskb() in localbhdisable() / localbhenable() so the child slock is always acquired with BH off. localbhdisable() nests safely on the softirq path.

Discovered via in-house syzkaller fuzzing; the same root cause also on the linux-6.1.y syzbot dashboard as extid 44f0626dd6284f02663c. Reproduced under KASAN + LOCKDEP + PROVELOCKING, reproducer: https://pastebin.com/A3t8xzCR

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

wifi: cfg80211: advance loop vars in cfg80211mergeprofile()

cfg80211mergeprofile() reassembles a Multi-BSSID non-transmitted BSS profile that has been split across multiple consecutive MBSSID elements. Its while-loop calls

cfg80211getprofilecontinuation(ie, ielen, mbssidelem, subelem)

but never advances mbssidelem or subelem inside the body. Each iteration therefore searches for a continuation that follows the same fixed pair; the helper returns the same nextmbssid; and the same nextsub bytes are memcpy()'d into mergedie at a growing offset until the buffer fills.

Advance both mbssidelem and subelem to the just-consumed continuation so the next call to cfg80211getprofilecontinuation() searches for a further continuation beyond it (or returns NULL when none exists).

A specially-crafted malicious beacon can take advantage of this bug to cause the kernel to spend an excessive amount of time in cfg80211mergeprofile (up to as much as 2ms per beacon received), which could theoretically be abused in some way.

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

tracing: Do not call map->ops->eltfree() if eltalloc() fails

In paths where tracingmapeltalloc() failed to allocate objects, the map->ops->eltalloc() call was never successful. In this case, map->ops->eltfree() should not be called.

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

i2c: tegra: fix pmruntime leak on mutexlock failure

If tegrai2cmutexlock() fails, the function returns without calling pmruntimeput(), leaking the runtime PM reference acquired by the preceding pmruntimegetsync(). This prevents the device from ever entering runtime suspend.

Add the missing pmruntimeput() before returning on lock failure.

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.

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

spi: qup: 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 (or attempting to release a channel a second time) on later probe errors or driver unbind.

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

spi: sprd: fix error pointer deref after DMA setup failure

The driver falls back to PIO mode if DMA setup fails during probe.

Make sure to check the dma.enabled flag before trying to release the DMA channels also on late probe errors to avoid dereferencing an error pointer (or attempting to release a channel a second time).

This issue was flagged by Sashiko when reviewing a devres allocation conversion patch.

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

firmware: armffa: Check for NULL FF-A ID table while driver registration

The bus match callback assumes that every FF-A driver provides an idtable and dereferences it unconditionally. Enforce that contract at registration time so a buggy client driver cannot crash the bus during match.