IBM WebSphere Application Server - Liberty 17.0.0.3 through 26.0.0.8 is affected by a denial of service caused by insecure deserialization. A low-privileged, administrative user could exploit this vulnerability to consume system resources when the restConnector-2.0 feature is enabled.

.NET Information Disclosure Vulnerability

.NET Security Feature Bypass Vulnerability

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

ipv4: fib: free fibalias with kfreercu() on insert error path

fibtableinsert() publishes newfa into the leaf's falist with fibinsertalias() before calling the fib entry notifiers. When a notifier fails, the error path removes newfa with fibremovealias() (hlistdelrcu) and frees it right away with kmemcachefree().

fibtablelookup() walks that list under rcureadlock() only, so a concurrent lookup that already reached newfa keeps reading it after the free:

BUG: KASAN: slab-use-after-free in fibtablelookup (net/ipv4/fibtrie.c:1601) Read of size 1 at addr ffff88810676d4eb by task exploit/297 Call Trace: fibtablelookup (net/ipv4/fibtrie.c:1601) iprouteoutputkeyhashrcu (net/ipv4/route.c:2814) iprouteoutputkeyhash (net/ipv4/route.c:2705) ip4datagramconnect (net/ipv4/datagram.c:49) udpconnect (net/ipv4/udp.c:2144) sysconnect (net/socket.c:2167) x64sysconnect (net/socket.c:2173) dosyscall64 entrySYSCALL64afterhwframe which belongs to the cache ipfibalias of size 56

Triggering the error path needs CAPNETADMIN and a registered fib notifier that can reject a route; a netdevsim device whose IPv4 FIB resource is exhausted is enough.

Free newfa with aliasfreememrcu(), as fibtabledelete() already does for a fibalias removed from the trie.

Bluetooth: qca: fix NVM tag length underflow in TLV parser

NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause the generation of error messages that contain sensitive information. A successful exploit of this vulnerability might lead to information disclosure.

NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause a race condition in the LoRA manager singleton initialization. A successful exploit of this vulnerability might lead to denial of service and data tampering.

NVIDIA Dynamo for Linux contains a vulnerability where an attacker could cause a race condition in the LoRA manager singleton initialization. A successful exploit of this vulnerability might lead to data tampering and denial of service.

crypto: asymmetrickeys - fix OOB read in pefiledigestpecontents

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

mm/slab: do not limit zeroing to origsize when only red zoning is enabled

When init (zeroing) on allocation is requested, for kmalloc() we generally have to zero the full object size even if a smaller size is requested, in order to provide krealloc()'s GFPZERO guarantees.

But if we track the requested size, krealloc() uses that information to do the right thing, so we can zero only the requested size. With red zoning also enabled, any extra size became part of the red zone, so it must not be zeroed and thus we must zero only the requested size.

However the current check is imprecise, and will trigger also when only SLABREDZONE is enabled without SLABSTOREUSER (which enables tracking the requested size). This means enabling red zoning alone can compromise krealloc()'s GFPZERO contract.

Fix this by using slubdebugorigsize() instead, which is the exact check for whether the requested size is tracked. We don't need to care if red zoning is also enabled or not. Also update and expand the comment accordingly.

ACPI: NFIT: core: Fix possible NULL pointer dereference

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

x86/bugs: Enable IBPB flush on BPF JIT allocation

Enable hardening against JIT spraying when Spectre-v2 mitigations are in use. Specifically, issue an IBPB flush on BPF JIT memory reuse. Skip enabling the IBPB flush if the BPF dispatcher is already using a retpoline sequence.

This hardening applies only when BPF-JIT is in use. Guard the enabling under CONFIGBPFJIT so that bugs.c still builds with CONFIGBPFJIT=n.

ALSA: caiaq: fix out-of-bounds read in the Traktor Kontrol S4 input parser

ALSA: gus: check sndctlnew1() return value

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

vfio: prevent infinite loop in vfiomiggetnextstate() on blocked arc

vfiomiggetnextstate() walks vfiofromfsmtable[] one step at a time, looping to skip optional states the device does not support until nextfsm is supported. A blocked transition is encoded as VFIODEVICESTATEERROR, which the trailing return reports as -EINVAL.

The skip loop does not account for the ERROR sentinel. stateflagstable[ERROR] is ~0U and vfiofromfsmtable[ERROR][] is ERROR, so once nextfsm becomes ERROR the loop condition stays true and nextfsm never changes. The blocked arcs STOPCOPY -> PRECOPY and STOPCOPY -> PRECOPYP2P map to ERROR yet pass the support check on a precopy-capable device, causing the loop to spin forever while holding the driver state mutex. This can result in a soft lockup, and a panic with softlockuppanic set.

Terminate the skip loop on the ERROR sentinel so a blocked transition falls through to the existing return and reports -EINVAL.

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

usb: xhci: Fix sleep in atomic context in xhcifreestreams()

When a USB device with active stream endpoints is disconnected, xhcifreestreams() is called from the hubevent workqueue to free the stream resources. It calls xhcifreestreaminfo() while holding xhci->lock with irqs disabled.

xhcifreestreaminfo() invokes xhcifreestreamctx(), which calls dmafreecoherent() for large stream context arrays.

dmafreecoherent() can sleep (e.g. via vunmap), triggering a BUG when called from atomic context.

Call trace: dmafreeattrs+0x174/0x220 xhcifreestreaminfo+0xd0/0x11c xhcifreestreams+0x278/0x37c usbfreestreams+0x98/0xc0 usbunbindinterface+0x1b8/0x2f8 devicereleasedriverinternal+0x1d4/0x2cc devicereleasedriver+0x18/0x28 busremovedevice+0x160/0x1a4 devicedel+0x1ec/0x350 usbdisabledevice+0x98/0x214 usbdisconnect+0xf0/0x35c hubevent+0xab4/0x19ec processonework+0x278/0x63c

Fix this by saving the streaminfo pointers and clearing the ep references under the lock, then calling xhcifreestreaminfo() outside the lock where sleeping is allowed.

Bluetooth: MGMT: Fix UAF of hciconnparams in adddevicecomplete

gpio: eic-sprd: use rawspinlockt in the irq startup path

cpufreq: Fix hotplug-suspend race during reboot

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

posix-cpu-timers: Fix pid refcount leak in docpunanosleep() error path

In docpunanosleep(), posixcputimercreate() takes a pid reference via getpid() and stores it in timer.it.cpu.pid. If the subsequent posixcputimerset() call fails, the function returns immediately without calling posixcputimerdel() to release the pid reference, causing a leak.

Fix it by calling posixcputimerdel() before the unlock-and-return on the error path, consistent with the other exit paths in the same function.

bpf: Allow LPM map access from sleepable BPF programs

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

usb: cdnsp: fix stream context array leak in cdnspallocstreaminfo()

cdnspallocstreaminfo() allocates streaminfo->streamctxarray with cdnspallocstreamctx(). If a later stream ring allocation or stream mapping update fails, the error path frees the allocated stream rings and streamrings array, but leaves streamctxarray allocated.

Free the stream context array before falling through to the streamrings cleanup path.

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

usb: gadget: udc: Fix use-after-free in gadgetmatchdriver

The udc structure acts as the management structure for the gadget, but their lifecycles are decoupled. A race condition exists where usbdelgadget() frees the udc memory (e.g., via mode-switch work) while gadgetmatchdriver() concurrently accesses the freed udc memory (e.g., via configfs), causing a Use-After-Free (UAF) that triggers a NULL pointer dereference when the freed memory is zeroed:

[39430.908615][ T1171] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [39430.911397][ T1171] pc : pistrcmp+0x20/0x140 [39430.911441][ T1171] lr : gadgetmatchdriver+0x34/0x60 ... [39430.911890][ T1171] usbgadgetregisterdriverowner+0x50/0xf8 [39430.911910][ T1171] gadgetdevdescUDCstore+0xf4/0x140 [39430.931308][ T1171] configfswriteiter+0xec/0x134

[39430.957058][ T1171] Workqueue: eventsfreezable dwc3setmode [39430.957287][ T1171] dwc3gadgetexit+0x34/0x8c [39430.957304][ T1171] dwc3setmode+0xc0/0x664

Fix this by ensuring the udc structure remains allocated until the gadget is released. To achieve this, introduce a new usbgadgetrelease() routine to the core. When the gadget is added, usbaddgadget() stores the gadget's release routine in the udc structure and takes a reference to the udc. When the gadget is released, usbgadgetrelease() drops the reference to the udc and then calls the gadget's release routine.

block: skip syncblockdev() on surprise removal in bdevmarkdead()

crypto: drbg - Fix returning success on failure in CTRDRBG

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).