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

module: decompress: check return value of moduleextendmaxpages()

moduleextendmaxpages() calls kvrealloc() internally and returns -ENOMEM on allocation failure. The return value is never checked.

If the initial allocation fails, info->pages remains NULL and info->maxpages remains 0. Subsequent calls to modulegetnextpage() will attempt to dynamically grow the array by calling moduleextendmaxpages(info, 0) since info->usedpages is 0. This results in kvrealloc(NULL, 0) returning ZEROSIZEPTR, which is treated as a success, leading to a dereference of ZEROSIZEPTR and a kernel oops.

Fix: add the missing error check after moduleextendmaxpages() and return immediately on failure. This matches the pattern used by every other kvrealloc() caller in the module loading path.

[Sami: Corrected the analysis in the commit message.]

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

mm: pageext: add count limit to pageextiternext to prevent invalid PFN access

The pageext iteration API does not validate if the PFN still belongs to a valid section while advancing the iterator. When dynamically adding memory in the hotplug path, it can lead to a NULL pointer dereference during pageextlookup at the boundary of the last valid section when iterator count equals pgcount.

The foreachpageext() macro calls pageextiternext() as its loop increment. foreachpageext() does a "pageext = pageextiternext(&iter)" at the end. This causes pageextiternext() to increment iter->index past pgcount and call pageextlookup(startpfn + pgcount). During memory hotplug (online), the PFN at startpfn + pgcount may belong to a section that has not yet been initialized, causing pageextlookup() to trigger a NULL pointer dereference.

[ 14.555124][ T846] Call trace: [ 14.555125][ T846] lookuppageext+0x6c/0x108 (P) [ 14.555127][ T846] pageextlookup+0x30/0x3c [ 14.555129][ T846] resetpageowner+0x11c/0x260 [ 14.571201][ T846] freepagesok+0x5e8/0x8e0 [ 14.571204][ T846] freepagescore+0x78/0xf0 [ 14.571206][ T846] genericonlinepage+0x14/0x24 [ 14.597782][ T846] onlinepages+0x178/0x30c [ 14.597784][ T846] memoryblockchangestate+0x284/0x32c [ 14.597787][ T846] memorysubsysonline+0x4c/0x64 [ 14.597789][ T846] deviceonline+0x88/0xb0 [ 14.597791][ T846] onlinememoryblock+0x30/0x40 [ 14.597793][ T846] walkmemoryblocks+0xac/0xe8 [ 14.597794][ T846] addmemoryresource+0x280/0x298 [ 14.656161][ T846] addmemory+0x60/0x98

Move the iteration boundary enforcement inside the iterator functions, so callers cannot inadvertently access beyond the requested range.

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: Break the loop on failure in iommufdfaultfopsread()

On a copytouser() failure inside the inner listforeachentry, only the inner loop breaks; the outer while re-fetches the just-restored fault group and retries the failing copytouser() forever, spinning the reader at 100% CPU with fault->mutex held.

Check rc after the inner loop and break the outer while as well.

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

iommufd: Set veventqdepth upper bound

iommufdveventqalloc() accepts any !0 veventqdepth from userspace, with an upper bound at U32MAX.

This leaves a vulnerability where userspace can allocate excessively large queues to exhaust kernel memory reserves.

Cap the veventqdepth (maximum number of entries) to 1 << 19, matching the maximum number of entries in the SMMUv3 EVTQ (the largest use case today).

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: arm64: nv: Avoid dereferencing NULL VNCR pseudo-TLB

VNCR TLB invalidation occurs from MMU notifiers or TLBI instructions, and either can race against a vcpu not being onlined yet (no pseudo-TLB allocated). Similarly, the TLB might be invalid, and the invalidation should be skipped in this case.

Both kvminvalidatevncripa() and kvminvalidatevncrva() are expected to perform the same checks, except that the latter doesn't check for the allocation and blindly dereferences the pointer.

Solve this by introducing a new iterator built on top of the usual kvmforeachvcpu() that checks for both of the above conditions, and convert the two users to it.

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

KVM: arm64: Don't leak PFN when kvmtranslatevncr() races MMU notifier

In the case that kvmtranslatevncr() races with an MMU notifier the early return does not release a reference on the faulted in PFN. Add the necessary call to kvmreleasefaultinpage() for the unused PFN.

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: avoid 32-bit prune notification count wrap

FUSENOTIFYPRUNE validates the nodeid payload length with:

size - sizeof(outarg) != outarg.count sizeof(u64)

On 32-bit kernels, sizet is also 32 bits, so the daemon-controlled count multiplication can wrap. A prune notification with count 0x20000000 and no nodeid payload passes the check, enters the copy loop, and asks the device copy path to read nodeids that are not present in the userspace write buffer. In QEMU this reaches the fusecopyfill() BUGON(!err) path.

Validate the payload length with arraysize() instead. That accepts exactly the same valid messages, but avoids wrapping arithmetic before the copy loop consumes the count.

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: fix EFAULT clobber in fuseuringcommit

copyfromuser() returns the number of bytes not copied as an unsigned residual on failure (1..sizeof(struct fuseoutheader)). fuseuringcommit stores that residual in ssizet err, sets req->out.h.error to -EFAULT, then jumps to out: with err still holding the positive residual.

err = copyfromuser(&req->out.h, &ent->headers->inout, sizeof(req->out.h)); if (err) { req->out.h.error = -EFAULT; goto out; / err is the positive residual / } ... out: fuseuringreqend(ent, req, err);

fuseuringreqend() then runs

if (error) req->out.h.error = error;

which overwrites the just-assigned -EFAULT with the positive residual. FUSE callers such as fusesimplerequest() test err < 0 to detect failure, so the positive value is interpreted as success and the caller proceeds with an uninitialised or partial req->out.args.

Fix by assigning err = -EFAULT in the failure branch before jumping to out, so fuseuringreqend() receives a negative errno and sets req->out.h.error to -EFAULT.

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:

fuse-uring: remove request-less entries from entwreqqueue to fix NULL deref

If a copy into the userspace ring buffer fails, a request will be terminated and fuseuringreqend() will set ent->fusereq to NULL but it will leave the entry on entwreqqueue in FRRSFUSEREQ state. This can lead to a NULL deref if the request expiration logic scans entwreqqueue in the window before the entry is moved off it.

Fix this by taking the entry off entwreqqueue and changing its state from FRRSFUSEREQ to FRRSINVALID before terminating the request.

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

xfs: don't wrap around quota ids in dqiterate

LOLLM noticed that qid is an unsigned 32-bit variable. If it happens to be set to XFSDQIDMAX due to a filesystem that actually has a dquot for IDMAX, then this addition will truncate to zero and the iteration starts over. Fix this by casting to u64.

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:

MIPS: DEC: Prevent initial console buffer from landing in XKPHYS

In 64-bit configurations calling the initial console output handler from a kernel thread other than the initial one will result in a situation where the stack has been placed in the XKPHYS 64-bit memory segment and consequently so has been the buffer allocated there that is used as the argument corresponding to the %s' output conversion specifier for the firmware's printf() entry point.

This 64-bit address will then be truncated by 32-bit firmware, resulting in an attempt to access the wrong memory location, which in turn will cause all kinds of unpredictable behaviour, such as a kernel crash:

Console: colour dummy device 160x64 Calibrating delay loop... 49.36 BogoMIPS (lpj=192512) pidmax: default: 32768 minimum: 301 CPU 0 Unable to handle kernel paging request at virtual address 000000000203bd00, epc == ffffffffbfc08364, ra == ffffffffbfc08800 Oops[#1]: CPU: 0 PID: 0 Comm: swapper Not tainted 5.18.0-rc2-00254-gfb649bda6f56-dirty #121 $ 0 : 0000000000000000 0000000000000001 0000000000000023 ffffffff80684ba0 $ 4 : 000000000203bd00 ffffffffbfc0f3b4 ffffffffffffffff 0000000000000073 $ 8 : 0a303d7469000000 0000000000000000 0000000000000073 ffffffffbfc0f473 $12 : 0000000000000002 0000000000000000 ffffffff80684c1c 0000000000000000 $16 : 0000000000000000 ffffffff80596dc9 0000000000000000 ffffffffbfc09240 $20 : ffffffff80684c40 ffffffffbfc0f400 000000000000002d 000000000000002b $24 : ffffffffffffffbf 000000000203bd00 $28 : ffffffff805f0000 ffffffff80684b58 0000000000000030 ffffffffbfc08800 Hi : 0000000000000000 Lo : 0000000000000aa8 epc : ffffffffbfc08364 0xffffffffbfc08364 ra : ffffffffbfc08800 0xffffffffbfc08800 Status: 140120e2 KX SX UX KERNEL EXL Cause : 00000008 (ExcCode 02) BadVA : 000000000203bd00 PrId : 00000430 (R4000SC) Modules linked in: Process swapper (pid: 0, threadinfo=(ptrval), task=(ptrval), tls=0000000000000000) Stack : 0000000000000000 0000000000000000 0000000000000000 0000004d0000004d 80684cc0806a2a40 80596dc80000004d 8061000000000000 bfc0850c80684c38 0000000000000000 000000000203bd00 0000000000000000 0000000000000000 0000000000000000 00000000bfc0f3b4 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000000000000000 0000002500000000 0000000000000000 0000000000000000 802c1a7400000000 0203bd0080596dc8 0203bd4d69000000 6c61632000000018 5f746567646e6172 6c616320625f6d6f 5f736e5f6d6f7266 206361323778302b 303d74696e726320 806a0a38806b0000 806a0a38806b0000 00000000806b0000 80683c58806b0000 ... Call Trace:

Code: a082ffff 03e00008 00601021 <80820000> 00001821 10400005 24840001 80820000 24630001

---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Fatal exception in interrupt

KN04 V2.1k (PC: 0xa0026768, SP: 0x806848e8) >>

In this case the pointer in $4 was truncated from 0x980000000203bd00 to 0x000000000203bd00.

This may happen when no final console driver has been enabled in the configuration and consequently the initial console continues being used late into bootstrap or with an upcoming change that will switch the zs driver to use a platform device, which in turn will make the console handover happen only after other kernel threads have already been started.

Fix the issue by making the buffer static and initdata, and therefore placed in the CKSEG0 32-bit compatibility segment, observing that the console output handler is called with the console lock held, implying no need for this code to be reentrant. Add an assertion to verify the buffer actually has been placed in a compatibility segment.

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

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:

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.