In the Linux kernel, the following vulnerability has been resolved:
gpio: rockchip: teardown bugs and resource leaks
Address several teardown issues and resource leaks in the driver's remove path and error handling:
1. Debounce clock reference leak: The debounce clock (bank->dbclk) is obtained using ofclkget() which increments the clock's reference count, but clkput() is never called. Register a devm action to cleanly release it on unbind. Note that ofclkget(..., 1) remains necessary over devmclkget() because the DT binding does not define clock-names, precluding name-based lookup.
2. Unregistered chained IRQ handler: The chained IRQ handler is not disconnected in remove(). If a stray interrupt fires after the driver is removed, the kernel attempts to execute a stale handler, leading to a panic. Fix this by clearing the handler in remove().
3. IRQ domain leak: The linear IRQ domain and its generic chips are allocated manually during probe but never removed. Remove the IRQ domain during driver teardown to free the associated generic chips and mappings.
[Bartosz: don't emit an error message on devres allocation failure]
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:
net: ethtool: phy: avoid NULL deref when PHY driver is unbound
phydev->drv can become NULL while the phydevice is still attached to its netdevice, namely after the PHY driver is unbound via sysfs:
echo <mdioid> > /sys/bus/mdiobus/drivers/<phydrv>/unbind
phyremove() clears phydev->drv but doesn't call phydetach(), so the phydevice stays in the link topology xarray and ethnlreqgetphydev() still hands it back. ETHTOOLMSGPHYGET then oopses on:
repdata->drvname = kstrdup(phydev->drv->name, GFPKERNEL);
drvname is already treated as optional by phyreplysize(), phyfillreply() and phycleanupdata(), so just skip the allocation when there is no driver bound.
In the Linux kernel, the following vulnerability has been resolved:
ACPI: driver: Check ACPICOMPANION() against NULL during probe
Since every platform driver can be forced to match a device that doesn't match its list of device IDs because of devicematchdriveroverride(), platform drivers that rely on the existence of a device's ACPI companion object should verify its presence.
Accordingly, add requisite ACPICOMPANION() or ACPIHANDLE() checks against NULL to 13 platform drivers handling core ACPI devices.
Also change the value returned by the ACPI thermal zone driver when the device's ACPI companion is not present to -ENODEV for consistency with the other drivers.
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:
powerpc/time: Remove redundant preemptdisable|enable() calls from archirqworkraise()
A kernel panic is observed when handling machine check exceptions from real mode.
BUG: Unable to handle kernel data access on read at 0xc00000006be21300 Oops: Kernel access of bad area, sig: 11 [#1] MSR: 8000000000001003 <SF,ME,RI,LE> CR: 88222248 XER: 00000005 CFAR: c00000000003ffc4 DAR: c00000006be21300 DSISR: 40000000 IRQMASK: 0 NIP [c000000000029e40] archirqworkraise+0x10/0x70 LR [c00000000003ffc8] machinecheckqueueevent+0xa8/0x150 Call Trace: [c0000000179d3c70] [c00000000003ff64] machinecheckqueueevent+0x44/0x150 [c0000000179d3d30] [c0000000000084e0] machinecheckearlycommon+0x1f0/0x2c0
The crash occurs because archirqworkraise() calls preemptdisable() from machine check exception (MCE) handlers running in real mode. In this context, accessing the preemptcount can fault, leading to the panic.
The preemptdisable()/preemptenable() pair in archirqworkraise() was originally added by commit 0fe1ac48bef0 ("powerpc/perfevent: Fix oops due to perfeventdopending call") to avoid races while raising irq work from exception context.
Later, commit 471ba0e686cb ("irqwork: Do not raise an IPI when queueing work on the local CPU") added preemption protection in irqworkqueue() path, while commit 20b876918c06 ("irqwork: Use per cpu atomics instead of regular atomics") added equivalent protection in irqworkqueueon() before reaching archirqworkraise():
irqworkqueue() / irqworkqueueon() -> preemptdisable() -> irqworkqueuelocal() -> irqworkraise() -> archirqworkraise()
As a result, callers other than mceirqworkraise() already execute with preemption disabled, making the additional preemptdisable()/preemptenable() pair in archirqworkraise() redundant.
The archirqworkraise() function executes in NMI context when called from MCE handler. Hence we will not be preempted or scheduled out since we are in NMI context with MSR[EE]=0. Therefore, it is safe to remove the preemptdisable()/preemptenable() calls from here.
Remove it to avoid accessing preemptcount from real mode context.
[Maddy: Fixed the commit title]
In the Linux kernel, the following vulnerability has been resolved:
hwmon: (lm90) Add lock protection to lm90alert
Sashiko reports:
lm90alert() executes in the smbus alert context and calls lm90updateconfreg() to disable the hardware alert line, without acquiring hwmonlock.
Concurrently, sysfs write operations (such as lm90writeconvrate) hold the hwmonlock, temporarily modify data->config, and then restore it.
If an alert interrupt occurs concurrently with a sysfs write, the sysfs path will overwrite the alert handler's modifications to data->config and the hardware register.
This unintentionally re-enables the hardware alert line while the alarm is still active, causing an interrupt storm.
Add the missing lock to lm90alert() to solve the problem.
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.