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

nvme-fc: release admin tagset if init fails

nvmefabrics creates an NVMe/FC controller in following path:

nvmfdevwrite() -> nvmfcreatectrl() -> nvmefccreatectrl() -> nvmefcinitctrl()

nvmefcinitctrl() allocates the admin blk-mq resources right after nvmeaddctrl() succeeds. If any of the subsequent steps fail (changing the controller state, scheduling connect work, etc.), we jump to the failctrl path, which tears down the controller references but never frees the admin queue/tag set. The leaked blk-mq allocations match the kmemleak report seen during blktests nvme/fc.

Check ctrl->ctrl.admintagset in the failctrl path and call nvmeremoveadmintagset() when it is set so that all admin queue allocations are reclaimed whenever controller setup aborts.

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

net: liquidio: Fix off-by-one error in VF setupnicdevices() cleanup

In setupnicdevices(), the initialization loop jumps to the label setupnicdevfree on failure. The current cleanup loop while(i--) skip the failing index i, causing a memory leak.

Fix this by changing the loop to iterate from the current index i down to 0.

Compile tested only. Issue found using code review.

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

net: add proper RCU protection to /proc/net/ptype

Yin Fengwei reported an RCU stall in ptypeseqshow() and provided a patch.

Real issue is that ptypeseqnext() and ptypeseqshow() violate RCU rules.

ptypeseqshow() runs under rcureadlock(), and reads pt->dev to get device name without any barrier.

At the same time, concurrent writers can remove a packettype structure (which is correctly freed after an RCU grace period) and clear pt->dev without an RCU grace period.

Define ptypeiterstate to carry a dev pointer along seqnetprivate:

struct ptypeiterstate { struct seqnetprivate p; struct netdevice dev; // added in this patch };

We need to record the device pointer in ptypegetidx() and ptypeseqnext() so that ptypeseqshow() is safe against concurrent pt->dev changes.

We also need to add full RCU protection in ptypeseqnext(). (Missing READONCE() when reading list.next values)

Many thanks to Dong Chenchen for providing a repro.

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

net: gro: fix outer network offset

The udp GRO complete stage assumes that all the packets inserted the RX have the encapsulation flag zeroed. Such assumption is not true, as a few H/W NICs can set such flag when H/W offloading the checksum for an UDP encapsulated traffic, the tun driver can inject GSO packets with UDP encapsulation and the problematic layout can also be created via a veth based setup.

Due to the above, in the problematic scenarios, udp4grocomplete() uses the wrong network offset (inner instead of outer) to compute the outer UDP header pseudo checksum, leading to csum validation errors later on in packet processing.

Address the issue always clearing the encapsulation flag at GRO completion time. Such flag will be set again as needed for encapsulated packets by udpgrocomplete().

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

fs/xattr: missing fdput() in fremovexattr error path

In the Linux kernel, the fremovexattr() syscall calls fdget() to acquire a file reference but returns early without calling fdput() when strncpyfromuser() fails on the name argument. In multi-threaded processes where fdget() takes the slow path, this permanently leaks one file reference per call, pinning the struct file and associated kernel objects in memory. An unprivileged local user can exploit this to cause kernel memory exhaustion. The issue was inadvertently fixed by commit a71874379ec8 ("xattr: switch to CLASS(fd)").

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

romfs: check sbsetblocksize() return value

romfsfillsuper() ignores the return value of sbsetblocksize(), which can fail if the requested block size is incompatible with the block device's configuration.

This can be triggered by setting a loop device's block size larger than PAGESIZE using ioctl(LOOPSETBLOCKSIZE, 32768), then mounting a romfs filesystem on that device.

When sbsetblocksize(sb, ROMBSIZE) is called with ROMBSIZE=4096 but the device has logicalblocksize=32768, bdevvalidateblocksize() fails because the requested size is smaller than the device's logical block size. sbsetblocksize() returns 0 (failure), but romfs ignores this and continues mounting.

The superblock's block size remains at the device's logical block size (32768). Later, when sbbread() attempts I/O with this oversized block size, it triggers a kernel BUG in foliosetbh():

kernel BUG at fs/buffer.c:1582! BUGON(size > PAGESIZE);

Fix by checking the return value of sbsetblocksize() and failing the mount with -EINVAL if it returns 0.

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

ksmbd: fix infinite loop caused by nextsmb2rcvhdroff reset in error paths

The problem occurs when a signed request fails smb2 signature verification check. In processrequest(), if checksignreq() returns an error, setsmb2rspstatus(work, STATUSACCESSDENIED) is called. setsmb2rspstatus() set work->nextsmb2rcvhdroff as zero. By resetting nextsmb2rcvhdroff to zero, the pointer to the next command in the chain is lost. Consequently, ischainedsmb2message() continues to point to the same request header instead of advancing. If the header's NextCommand field is non-zero, the function returns true, causing handleksmbdwork() to repeatedly process the same failed request in an infinite loop. This results in the kernel log being flooded with "bad smb2 signature" messages and high CPU usage.

This patch fixes the issue by changing the return value from SERVERHANDLERCONTINUE to SERVERHANDLERABORT. This ensures that the processing loop terminates immediately rather than attempting to continue from an invalidated offset.

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

x86/vmware: Fix hypercall clobbers

Fedora QA reported the following panic:

BUG: unable to handle page fault for address: 0000000040003e54 #PF: supervisor write access in kernel mode #PF: errorcode(0x0002) - not-present page Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20251119-3.fc43 11/19/2025 RIP: 0010:vmwarehypercall4.constprop.0+0x52/0x90 .. Call Trace: vmmousereportevents+0x13e/0x1b0 psmousehandlebyte+0x15/0x60 ps2interrupt+0x8a/0xd0 ...

because the QEMU VMware mouse emulation is buggy, and clears the top 32 bits of %rdi that the kernel kept a pointer in.

The QEMU vmmouse driver saves and restores the register state in a "uint32t data[6];" and as a result restores the state with the high bits all cleared.

RDI originally contained the value of a valid kernel stack address (0xff5eeb3240003e54). After the vmware hypercall it now contains 0x40003e54, and we get a page fault as a result when it is dereferenced.

The proper fix would be in QEMU, but this works around the issue in the kernel to keep old setups working, when old kernels had not happened to keep any state in %rdi over the hypercall.

In theory this same issue exists for all the hypercalls in the vmmouse driver; in practice it has only been seen with vmwarehypercall3() and vmwarehypercall4(). For now, just mark RDI/RSI as clobbered for those two calls. This should have a minimal effect on code generation overall as it should be rare for the compiler to want to make RDI/RSI live across hypercalls.

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

net: usb: r8152: fix resume reset deadlock

rtl8152 can trigger device reset during reset which potentially can result in a deadlock:

DPM device timeout after 10 seconds; 15 seconds until panic Call Trace: <TASK> schedule+0x483/0x1370 schedulepreemptdisabled+0x15/0x30 mutexlockcommon+0x1fd/0x470 rtl8152setmacaddress+0x80/0x1f0 devsetmacaddress+0x7f/0x150 rtl8152postreset+0x72/0x150 usbresetdevice+0x1d0/0x220 rtl8152resume+0x99/0xc0 usbresumeinterface+0x3e/0xc0 usbresumeboth+0x104/0x150 usbresume+0x22/0x110

The problem is that rtl8152 resume calls reset under tp->control mutex while reset basically re-enters rtl8152 and attempts to acquire the same tp->control lock once again.

Reset INACCESSIBLE device outside of tp->control mutex scope to avoid recursive mutexlock() deadlock.

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

rocker: fix memory leak in rockerworldportpostfini()

In rockerworldportpreinit(), rockerport->wpriv is allocated with kzalloc(wops->portprivsize, GFPKERNEL). However, in rockerworldportpostfini(), the memory is only freed when wops->portpostfini callback is set:

if (!wops->portpostfini) return; wops->portpostfini(rockerport); kfree(rockerport->wpriv);

Since rockerofdpaops does not implement portpostfini callback (it is NULL), the wpriv memory allocated for each port is never freed when ports are removed. This leads to a memory leak of sizeof(struct ofdpaport) bytes per port on every device removal.

Fix this by always calling kfree(rockerport->wpriv) regardless of whether the portpostfini callback exists.

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

perf: sched: Fix perf crash with new isusertask() helper

In order to do a user space stacktrace the current task needs to be a user task that has executed in user space. It use to be possible to test if a task is a user task or not by simply checking the taskstruct mm field. If it was non NULL, it was a user task and if not it was a kernel task.

But things have changed over time, and some kernel tasks now have their own mm field.

An idea was made to instead test PFKTHREAD and two functions were used to wrap this check in case it became more complex to test if a task was a user task or not[1]. But this was rejected and the C code simply checked the PFKTHREAD directly.

It was later found that not all kernel threads set PFKTHREAD. The io-uring helpers instead set PFUSERWORKER and this needed to be added as well.

But checking the flags is still not enough. There's a very small window when a task exits that it frees its mm field and it is set back to NULL. If perf were to trigger at this moment, the flags test would say its a user space task but when perf would read the mm field it would crash with at NULL pointer dereference.

Now there are flags that can be used to test if a task is exiting, but they are set in areas that perf may still want to profile the user space task (to see where it exited). The only real test is to check both the flags and the mm field.

Instead of making this modification in every location, create a new isusertask() helper function that does all the tests needed to know if it is safe to read the user space memory or not.

[1] https://lore.kernel.org/all/20250425204120.639530125@goodmis.org/

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

btrfs: zlib: fix the folio leak on S390 hardware acceleration

[BUG] After commit aa60fe12b4f4 ("btrfs: zlib: refactor S390x HW acceleration buffer preparation"), we no longer release the folio of the page cache of folio returned by btrfscompressfilemapgetfolio() for S390 hardware acceleration path.

[CAUSE] Before that commit, we call kumaplocal() and folioput() after handling each folio.

Although the timing is not ideal (it release previous folio at the beginning of the loop, and rely on some extra cleanup out of the loop), it at least handles the folio release correctly.

Meanwhile the refactored code is easier to read, it lacks the call to release the filemap folio.

[FIX] Add the missing folioput() for copydataintobuffer().

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

btrfs: send: check for inline extents in rangeisholeinparent()

Before accessing the diskbytenr field of a file extent item we need to check if we are dealing with an inline extent. This is because for inline extents their data starts at the offset of the diskbytenr field. So accessing the diskbytenr means we are accessing inline data or in case the inline data is less than 8 bytes we can actually cause an invalid memory access if this inline extent item is the first item in the leaf or access metadata from other items.

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

bpf, testrun: Subtract size of xdpframe from allowed metadata size

The xdpframe structure takes up part of the XDP frame headroom, limiting the size of the metadata. However, in bpftestrun, we don't take this into account, which makes it possible for userspace to supply a metadata size that is too large (taking up the entire headroom).

If userspace supplies such a large metadata size in live packet mode, the xdpupdateframefrombuff() call in xdptestruninitpage() call will fail, after which packet transmission proceeds with an uninitialised frame structure, leading to the usual Bad Stuff.

The commit in the Fixes tag fixed a related bug where the second check in xdpupdateframefrombuff() could fail, but did not add any additional constraints on the metadata size. Complete the fix by adding an additional check on the metadata size. Reorder the checks slightly to make the logic clearer and add a comment.

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

of: unittest: Fix memory leak in unittestdataadd()

In unittestdataadd(), if ofresolvephandles() fails, the allocated unittestdata is not freed, leading to a memory leak.

Fix this by using scope-based cleanup helper free(kfree) for automatic resource cleanup. This ensures unittestdata is automatically freed when it goes out of scope in error paths.

For the success path, use retainandnullptr() to transfer ownership of the memory to the device tree and prevent double freeing.

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

wifi: ath10k: fix dmafreecoherent() pointer

dmaalloccoherent() allocates a DMA mapped buffer and stores the addresses in XXXunaligned fields. Those should be reused when freeing the buffer rather than the aligned addresses.

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

netdevsim: fix a race issue related to the operation on bpfboundprogs list

The netdevsim driver lacks a protection mechanism for operations on the bpfboundprogs list. When the nsimbpfcreateprog() performs listaddtail, it is possible that nsimbpfdestroyprog() is simultaneously performs listdel. Concurrent operations on the list may lead to list corruption and trigger a kernel crash as follows:

[ 417.290971] kernel BUG at lib/listdebug.c:62! [ 417.290983] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 417.290992] CPU: 10 PID: 168 Comm: kworker/10:1 Kdump: loaded Not tainted 6.19.0-rc5 #1 [ 417.291003] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [ 417.291007] Workqueue: events bpfprogfreedeferred [ 417.291021] RIP: 0010:listdelentryvalidorreport+0xa7/0xc0 [ 417.291034] Code: a8 ff 0f 0b 48 89 fe 48 89 ca 48 c7 c7 48 a1 eb ae e8 ed fb a8 ff 0f 0b 48 89 fe 48 89 c2 48 c7 c7 80 a1 eb ae e8 d9 fb a8 ff <0f> 0b 48 89 d1 48 c7 c7 d0 a1 eb ae 48 89 f2 48 89 c6 e8 c2 fb a8 [ 417.291040] RSP: 0018:ffffb16a40807df8 EFLAGS: 00010246 [ 417.291046] RAX: 000000000000006d RBX: ffff8e589866f500 RCX: 0000000000000000 [ 417.291051] RDX: 0000000000000000 RSI: ffff8e59f7b23180 RDI: ffff8e59f7b23180 [ 417.291055] RBP: ffffb16a412c9000 R08: 0000000000000000 R09: 0000000000000003 [ 417.291059] R10: ffffb16a40807c80 R11: ffffffffaf9edce8 R12: ffff8e594427ac20 [ 417.291063] R13: ffff8e59f7b44780 R14: ffff8e58800b7a05 R15: 0000000000000000 [ 417.291074] FS: 0000000000000000(0000) GS:ffff8e59f7b00000(0000) knlGS:0000000000000000 [ 417.291079] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 417.291083] CR2: 00007fc4083efe08 CR3: 00000001c3626006 CR4: 0000000000770ee0 [ 417.291088] PKRU: 55555554 [ 417.291091] Call Trace: [ 417.291096] <TASK> [ 417.291103] nsimbpfdestroyprog+0x31/0x80 [netdevsim] [ 417.291154] bpfprogoffloaddestroy+0x2a/0x80 [ 417.291163] bpfprogdevbounddestroy+0x6f/0xb0 [ 417.291171] bpfprogfreedeferred+0x18e/0x1a0 [ 417.291178] processonework+0x18a/0x3a0 [ 417.291188] workerthread+0x27b/0x3a0 [ 417.291197] ? pfxworkerthread+0x10/0x10 [ 417.291207] kthread+0xe5/0x120 [ 417.291214] ? pfxkthread+0x10/0x10 [ 417.291221] retfromfork+0x31/0x50 [ 417.291230] ? pfxkthread+0x10/0x10 [ 417.291236] retfromforkasm+0x1a/0x30 [ 417.291246] </TASK>

Add a mutex lock, to prevent simultaneous addition and deletion operations on the list.

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

igc: Reduce TSN TX packet buffer from 7KB to 5KB per queue

The previous 7 KB per queue caused TX unit hangs under heavy timestamping load. Reducing to 5 KB avoids these hangs and matches the TSN recommendation in I225/I226 SW User Manual Section 7.5.4.

The 8 KB "freed" by this change is currently unused. This reduction is not expected to impact throughput, as the i226 is PCIe-limited for small TSN packets rather than TX-buffer-limited.

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

ice: add missing icedeinithw() in devlink reinit path

devlink-reload results in iceinithw failed error, and then removing the ice driver causes a NULL pointer dereference.

[ +0.102213] ice 0000:ca:00.0: iceinithw failed: -16 ... [ +0.000001] Call Trace: [ +0.000003] <TASK> [ +0.000006] iceunload+0x8f/0x100 [ice] [ +0.000081] iceremove+0xba/0x300 [ice]

Commit 1390b8b3d2be ("ice: remove duplicate call to icedeinithw() on error paths") removed icedeinithw() from icedeinitdev(). As a result icedevlinkreinitdown() no longer calls icedeinithw(), but icedevlinkreinitup() still calls iceinithw(). Since the control queues are not uninitialized, iceinithw() fails with -EBUSY.

Add icedeinithw() to icedevlinkreinitdown() to correspond with iceinithw() in icedevlinkreinitup().

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

scsi: core: Wake up the error handler when final completions race against each other

The fragile ordering between marking commands completed or failed so that the error handler only wakes when the last running command completes or times out has race conditions. These race conditions can cause the SCSI layer to fail to wake the error handler, leaving I/O through the SCSI host stuck as the error state cannot advance.

First, there is an memory ordering issue within scsidechostbusy(). The write which clears SCMDSTATEINFLIGHT may be reordered with reads counting in scsihostbusy(). While the local CPU will see its own write, reordering can allow other CPUs in scsidechostbusy() or scsiehinchostfailed() to see a raised busy count, causing no CPU to see a host busy equal to the hostfailed count.

This race condition can be prevented with a memory barrier on the error path to force the write to be visible before counting host busy commands.

Second, there is a general ordering issue with scsiehinchostfailed(). By counting busy commands before incrementing hostfailed, it can race with a final command in scsidechostbusy(), such that scsidechostbusy() does not see hostfailed incremented but scsiehinchostfailed() counts busy commands before SCMDSTATEINFLIGHT is cleared by scsidechostbusy(), resulting in neither waking the error handler task.

This needs the call to scsihostbusy() to be moved after hostfailed is incremented to close the race condition.

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

ice: fix devlink reload call trace

Commit 4da71a77fc3b ("ice: read internal temperature sensor") introduced internal temperature sensor reading via HWMON. icehwmoninit() was added to iceinitfeature() and icehwmonexit() was added to iceremove(). As a result if devlink reload is used to reinit the device and then the driver is removed, a call trace can occur.

BUG: unable to handle page fault for address: ffffffffc0fd4b5d Call Trace: string+0x48/0xe0 vsnprintf+0x1f9/0x650 sprintf+0x62/0x80 nameshow+0x1f/0x30 devattrshow+0x19/0x60

The call trace repeats approximately every 10 minutes when system monitoring tools (e.g., sadc) attempt to read the orphaned hwmon sysfs attributes that reference freed module memory.

The sequence is: 1. Driver load, icehwmoninit() gets called from iceinitfeature() 2. Devlink reload down, flow does not call iceremove() 3. Devlink reload up, icehwmoninit() gets called from iceinitfeature() resulting in a second instance 4. Driver unload, icehwmonexit() called from iceremove() leaving the first hwmon instance orphaned with dangling pointer

Fix this by moving icehwmonexit() from iceremove() to icedeinitfeatures() to ensure proper cleanup symmetry with icehwmoninit().

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

leds: led-class: Only Add LED to ledslist when it is fully ready

Before this change the LED was added to ledslist before ledinitcore() gets called adding it the list before ledclassdev.setbrightnesswork gets initialized.

This leaves a window where ledtriggerregister() of a LED's default trigger will call ledtriggerset() which calls ledsetbrightness() which in turn will end up queueing the uninitialized ledclassdev.setbrightnesswork.

This race gets hit by the lenovo-thinkpad-t14s EC driver which registers 2 LEDs with a default trigger provided by sndctlled.ko in quick succession. The first ledclassdevregister() causes an async modprobe of sndctlled to run and that async modprobe manages to exactly hit the window where the second LED is on the ledslist without ledinitcore() being called for it, resulting in:

------------[ cut here ]------------ WARNING: CPU: 11 PID: 5608 at kernel/workqueue.c:4234 flushwork+0x344/0x390 Hardware name: LENOVO 21N2S01F0B/21N2S01F0B, BIOS N42ET93W (2.23 ) 09/01/2025 ... Call trace: flushwork+0x344/0x390 (P) flushwork+0x2c/0x50 ledtriggerset+0x1c8/0x340 ledtriggerregister+0x17c/0x1c0 ledtriggerregistersimple+0x84/0xe8 sndctlledinit+0x40/0xf88 [sndctlled] dooneinitcall+0x5c/0x318 doinitmodule+0x9c/0x2b8 loadmodule+0x7e0/0x998

Close the race window by moving the adding of the LED to ledslist to after the ledinitcore() call.

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

uacce: fix isolate sysfs check condition

uacce supports the device isolation feature. If the driver implements the isolateerrthresholdread and isolateerrthresholdwrite callback functions, uacce will create sysfs files now. Users can read and configure the isolation policy through sysfs. Currently, sysfs files are created as long as either isolateerrthresholdread or isolateerrthresholdwrite callback functions are present.

However, accessing a non-existent callback function may cause the system to crash. Therefore, intercept the creation of sysfs if neither read nor write exists; create sysfs if either is supported, but intercept unsupported operations at the call site.

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

intelth: fix device leak on output open()

Make sure to drop the reference taken when looking up the th device during output device open() on errors and on close().

Note that a recent commit fixed the leak in a couple of open() error paths but not all of them, and the reference is still leaking on successful open().

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

slimbus: core: fix device reference leak on report present

Slimbus devices can be allocated dynamically upon reception of report-present messages.

Make sure to drop the reference taken when looking up already registered devices.

Note that this requires taking an extra reference in case the device has not yet been registered and has to be allocated.

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

scsi: xen: scsiback: Fix potential memory leak in scsibackremove()

Memory allocated for struct vscsiblkinfo in scsibackprobe() is not freed in scsibackremove() leading to potential memory leaks on remove, as well as in the scsibackprobe() error paths. Fix that by freeing it in scsibackremove().

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

can: mcbausb: mcbausbreadbulkcallback(): fix URB memory leak

Fix similar memory leak as in commit 7352e1d5932a ("can: gsusb: gsusbreceivebulkcallback(): fix URB memory leak").

In mcbausbprobe() -> mcbausbstart(), the URBs for USB-in transfers are allocated, added to the priv->rxsubmitted anchor and submitted. In the complete callback mcbausbreadbulkcallback(), the URBs are processed and resubmitted. In mcbausbclose() -> mcbaurbunlink() the URBs are freed by calling usbkillanchoredurbs(&priv->rxsubmitted).

However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in usbkillanchoredurbs().

Fix the memory leak by anchoring the URB in the mcbausbreadbulkcallback()to the priv->rxsubmitted anchor.

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

can: esdusb: esdusbreadbulkcallback(): fix URB memory leak

Fix similar memory leak as in commit 7352e1d5932a ("can: gsusb: gsusbreceivebulkcallback(): fix URB memory leak").

In esdusbopen(), the URBs for USB-in transfers are allocated, added to the dev->rxsubmitted anchor and submitted. In the complete callback esdusbreadbulkcallback(), the URBs are processed and resubmitted. In esdusbclose() the URBs are freed by calling usbkillanchoredurbs(&dev->rxsubmitted).

However, this does not take into account that the USB framework unanchors the URB before the complete function is called. This means that once an in-URB has been completed, it is no longer anchored and is ultimately not released in esdusbclose().

Fix the memory leak by anchoring the URB in the esdusbreadbulkcallback() to the dev->rxsubmitted anchor.

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

platform/x86: hp-bioscfg: Fix kernel panic in GETINSTANCEID macro

The GETINSTANCEID macro that caused a kernel panic when accessing sysfs attributes:

1. Off-by-one error: The loop condition used '<=' instead of '<', causing access beyond array bounds. Since array indices are 0-based and go from 0 to instancescount-1, the loop should use '<'.

2. Missing NULL check: The code dereferenced attrnamekobj->name without checking if attrnamekobj was NULL, causing a null pointer dereference in minlengthshow() and other attribute show functions.

The panic occurred when fwupd tried to read BIOS configuration attributes:

Oops: general protection fault [#1] SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:minlengthshow+0xcf/0x1d0 [hpbioscfg]

Add a NULL check for attrnamekobj before dereferencing and corrects the loop boundary to match the pattern used elsewhere in the driver.

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

dmaengine: athdmac: fix device leak on ofdmaxlate()

Make sure to drop the reference taken when looking up the DMA platform device during ofdmaxlate() when releasing channel resources.

Note that commit 3832b78b3ec2 ("dmaengine: athdmac: add missing putdevice() call in atdmaxlate()") fixed the leak in a couple of error paths but the reference is still leaking on successful allocation.