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

usb: yurex: fix race in probe

The bbu member of the descriptor must be set to the value standing for uninitialized values before the URB whose completion handler sets bbu is submitted. Otherwise there is a window during which probing can overwrite already retrieved data.

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

ice: ptp: don't WARN when controlling PF is unavailable

In VFIO passthrough setups, it is possible to pass through only a PF which doesn't own the source timer. In that case the PTP controlling PF (adapter->ctrlpf) is never initialized in the VM, so icegetctrlptp() returns NULL and triggers WARNON() in iceptpsetuppf().

Since this is an expected behavior in that configuration, replace WARNON() with an informational message and return -EOPNOTSUPP.

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

perf/x86/intel/uncore: Fix die ID init and look up bugs

In snbeppci2phymapinit(), in the nrnodeids > 8 path, uncoredevicetodie() may return -1 when all CPUs associated with the UBOX device are offline.

Remove the WARNONONCE(dieid == -1) check for two reasons:

- The current code breaks out of the loop. This is incorrect because pcigetdevice() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.

- Returning -EINVAL is incorrect, since marking offline buses with dieid == -1 is expected and should not be treated as an error.

Separately, when NUMA is disabled on a NUMA-capable platform, pcibustonode() returns NUMANONODE, causing uncoredevicetodie() to return -1 for all PCI devices. As a result, sprupdatedevicelocation(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.

Fix this by using uncorepcibustodieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbeppci2phymapinit() to be added in spruncorepciinit().

Keep uncoredevicetodie() only for the nrnodeids > 8 case, where NUMA is expected to be enabled.

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

usb: gadget: fsubset: Fix unbalanced refcnt in gethfree

gethalloc() increments the reference count, but gethfree() fails to decrement it. This prevents the configuration of attributes via configfs after unlinking the function.

Decrement the reference count in gethfree() to ensure proper cleanup.

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

usb: gadget: frndis: Protect RNDIS options with mutex

The class/subclass/protocol options are suspectible to race conditions as they can be accessed concurrently through configfs.

Use existing mutex to protect these options. This issue was identified during code inspection.

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

comedi: Reinit dev->spinlock between attachments to low-level drivers

struct comedidevice is the main controlling structure for a COMEDI device created by the COMEDI subsystem. It contains a member spinlock containing a spin-lock that is initialized by the COMEDI subsystem, but is reserved for use by a low-level driver attached to the COMEDI device (at least since commit 25436dc9d84f ("Staging: comedi: remove RT code")).

Some COMEDI devices (those created on initialization of the COMEDI subsystem when the "comedi.comedinumlegacyminors" parameter is non-zero) can be attached to different low-level drivers over their lifetime using the COMEDIDEVCONFIG ioctl command. This can result in inconsistent lock states being reported when there is a mismatch in the spin-lock locking levels used by each low-level driver to which the COMEDI device has been attached. Fix it by reinitializing dev->spinlock before calling the low-level driver's attach function pointer if CONFIGLOCKDEP is enabled.

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

drm/amd/display: Fix NULL pointer dereference in dcn401inithw()

dcn401inithw() assumes that updatebwboundingbox() is valid when entering the update path. However, the existing condition:

((!fams2enable && updatebwboundingbox) || freqchanged)

does not guarantee this, as the freqchanged branch can evaluate to true independently of the callback pointer.

This can result in calling updatebwboundingbox() when it is NULL.

Fix this by separating the update condition from the pointer checks and ensuring the callback, dc->clkmgr, and bwparams are validated before use.

Fixes the below: ../dc/hwss/dcn401/dcn401hwseq.c:367 dcn401inithw() error: we previously assumed 'dc->respool->funcs->updatebwboundingbox' could be null (see line 362)

(cherry picked from commit 86117c5ab42f21562fedb0a64bffea3ee5fcd477)

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

interconnect: qcom: sm8450: Fix NULL pointer dereference in icclinknodes()

The change to dynamic IDs for SM8450 platform interconnects left two links unconverted, fix it to avoid the NULL pointer dereference in runtime, when a pointer to a destination interconnect is not valid:

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 <...> Call trace: icclinknodes+0x3c/0x100 (P) qcomiccrpmhprobe+0x1b4/0x528 platformprobe+0x64/0xc0 reallyprobe+0xc4/0x2a8 driverprobedevice+0x80/0x140 driverprobedevice+0x48/0x170 deviceattachdriver+0xc0/0x148 busforeachdrv+0x88/0xf0 deviceattach+0xb0/0x1c0 deviceinitialprobe+0x58/0x68 busprobedevice+0x40/0xb8 deferredprobeworkfunc+0x90/0xd0 processonework+0x15c/0x3c0 workerthread+0x2e8/0x400 kthread+0x150/0x208 retfromfork+0x10/0x20 Code: 900310f4 911d6294 91008280 94176078 (f94002a0) ---[ end trace 0000000000000000 ]--- Kernel panic - not syncing: Oops: Fatal exception

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

bpf: reject direct access to nullable PTRTOBUF pointers

checkmemaccess() matches PTRTOBUF via basetype() which strips PTRMAYBENULL, allowing direct dereference without a null check.

Map iterator ctx->key and ctx->value are PTRTOBUF | PTRMAYBENULL. On stop callbacks these are NULL, causing a kernel NULL dereference.

Add a typemaybenull() guard to the PTRTOBUF branch, matching the existing PTRTOBTFID pattern.

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

x86/kexec: Disable KCOV instrumentation after loadsegments()

The loadsegments() function changes segment registers, invalidating GS base (which KCOV relies on for per-cpu data). When CONFIGKCOV is enabled, any subsequent instrumented C code call (e.g. nativegdtinvalidate()) begins crashing the kernel in an endless loop.

To reproduce the problem, it's sufficient to do kexec on a KCOV-instrumented kernel:

$ kexec -l /boot/otherKernel $ kexec -e

The real-world context for this problem is enabling crash dump collection in syzkaller. For this, the tool loads a panic kernel before fuzzing and then calls makedumpfile after the panic. This workflow requires both CONFIGKEXEC and CONFIGKCOV to be enabled simultaneously.

Adding safeguards directly to the KCOV fast-path (sanitizercovtracepc()) is also undesirable as it would introduce an extra performance overhead.

Disabling instrumentation for the individual functions would be too fragile, so disable KCOV instrumentation for the entire machinekexec64.c and physaddr.c. If coverage-guided fuzzing ever needs these components in the future, other approaches should be considered.

The problem is not relevant for 32 bit kernels as CONFIGKCOV is not supported there.

[ bp: Space out comment for better readability. ]

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

USB: dummy-hcd: Fix locking/synchronization error

Syzbot testing was able to provoke an addressing exception and crash in the usbgadgetudcreset() routine in drivers/usb/gadgets/udc/core.c, resulting from the fact that the routine was called with a second ("driver") argument of NULL. The bad caller was setlinkstate() in dummyhcd.c, and the problem arose because of a race between a USB reset and driver unbind.

These sorts of races were not supposed to be possible; commit 7dbd8f4cabd9 ("USB: dummy-hcd: Fix erroneous synchronization change"), along with a few followup commits, was written specifically to prevent them. As it turns out, there are (at least) two errors remaining in the code. Another patch will address the second error; this one is concerned with the first.

The error responsible for the syzbot crash occurred because the stopactivity() routine will sometimes drop and then re-acquire the dum->lock spinlock. A call to stopactivity() occurs in setlinkstate() when handling an emulated USB reset, after the test of dum->intsenabled and before the increment of dum->callbackusage. This allowed another thread (doing a driver unbind) to sneak in and grab the spinlock, and then clear dum->intsenabled and dum->driver. Normally this other thread would have to wait for dum->callbackusage to go down to 0 before it would clear dum->driver, but in this case it didn't have to wait since dum->callbackusage had not yet been incremented.

The fix is to increment dum->callbackusage before calling stopactivity() instead of after. Then the thread doing the unbind will not clear dum->driver until after the call to usbgadgetudcreset() safely returns and dum->callbackusage has been decremented again.

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

schedext: Fix SCXKICKWAIT deadlock by deferring wait to balance callback

SCXKICKWAIT busy-waits in kickcpusirqworkfn() using smpcondloadacquire() until the target CPU's kicksync advances. Because the irqwork runs in hardirq context, the waiting CPU cannot reschedule and its own kicksync never advances. If multiple CPUs form a wait cycle, all CPUs deadlock.

Replace the busy-wait in kickcpusirqworkfn() with reschedcurr() to force the CPU through dopicktaskscx(), which queues a balance callback to perform the wait. The balance callback drops the rq lock and enables IRQs following the schedcorebalance() pattern, so the CPU can process IPIs while waiting. The local CPU's kicksync is advanced on entry to dopicktaskscx() and continuously during the wait, ensuring any CPU that starts waiting for us sees the advancement and cannot form cyclic dependencies.

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

wifi: iwlwifi: mvm: don't send a 6E related command when not supported

MCCALLOWEDAPTYPECMD is related to 6E support. Do not send it if the device doesn't support 6E. Apparently, the firmware is mistakenly advertising support for this command even on AX201 which does not support 6E and then the firmware crashes.

drm/amd/display: Fix dsc eDP issue

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

spi: spidev: fix lock inversion between spilock and buflock

The spidev driver previously used two mutexes, spilock and buflock, but acquired them in different orders depending on the code path:

write()/read(): buflock -> spilock ioctl(): spilock -> buflock

This AB-BA locking pattern triggers lockdep warnings and can cause real deadlocks:

WARNING: possible circular locking dependency detected spidevioctl() -> mutexlock(&spidev->buflock) spidevsyncwrite() -> mutexlock(&spidev->spilock) DEADLOCK

The issue is reproducible with a simple userspace program that performs write() and SPIIOCWRMAXSPEEDHZ ioctl() calls from separate threads on the same spidev file descriptor.

Fix this by simplifying the locking model and removing the lock inversion entirely. spidevsync() no longer performs any locking, and all callers serialize access using spilock.

buflock is removed since its functionality is fully covered by spilock, eliminating the possibility of lock ordering issues.

This removes the lock inversion and prevents deadlocks without changing userspace ABI or behaviour.

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

drm/amdgpu: fix sync handling in amdgpudmabufmovenotify

Invalidating a dmabuf will impact other users of the shared BO. In the scenario where process A moves the BO, it needs to inform process B about the move and process B will need to update its page table.

The commit fixes a synchronisation bug caused by the use of the ticket: it made amdgpuvmhandlemoved behave as if updating the page table immediately was correct but in this case it's not.

An example is the following scenario, with 2 GPUs and glxgears running on GPU0 and Xorg running on GPU1, on a system where P2P PCI isn't supported:

glxgears: export linear buffer from GPU0 and import using GPU1 submit frame rendering to GPU0 submit tiled->linear blit Xorg: copy of linear buffer

The sequence of jobs would be: drmschedjobrun # GPU0, frame rendering drmschedjobqueue # GPU0, blit drmschedjobdone # GPU0, frame rendering drmschedjobrun # GPU0, blit move linear buffer for GPU1 access # amdgpudmabufmovenotify -> update pt # GPU0

It this point the blit job on GPU0 is still running and would likely produce a page fault.

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

most: core: fix leak on early registration failure

A recent commit fixed a resource leak on early registration failures but for some reason left out the first error path which still leaks the resources associated with the interface.

Fix up also the first error path so that the interface is always released on errors.

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

media: solo6x10: Check for out of bounds chipid

Clang with CONFIGUBSANSHIFT=y noticed a condition where a signed type (literal "1" is an "int") could end up being shifted beyond 32 bits, so instrumentation was added (and due to the double istw286x() call seen via inlining), Clang decides the second one must now be undefined behavior and elides the rest of the function[1]. This is a known problem with Clang (that is still being worked on), but we can avoid the entire problem by actually checking the existing max chip ID, and now there is no runtime instrumentation added at all since everything is known to be within bounds.

Additionally use an unsigned value for the shift to remove the instrumentation even without the explicit bounds checking.

[hverkuil: fix checkpatch warning for istw286x]

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

kexec: derive purgatory entry from symbol

kexecloadpurgatory() derives image->start by locating eentry inside an SHFEXECINSTR section. If the purgatory object contains multiple executable sections with overlapping shaddr, the entrypoint check can match more than once and trigger a WARN.

Derive the entry section from the purgatorystart symbol when present and compute image->start from its final placement. Keep the existing eentry fallback for purgatories that do not expose the symbol.

WARNING: kernel/kexecfile.c:1009 at kexecloadpurgatory+0x395/0x3c0, CPU#10: kexec/1784 Call Trace: <TASK> bzImage64load+0x133/0xa00 dosyskexecfileload+0x2b3/0x5c0 dosyscall64+0x81/0x610 entrySYSCALL64afterhwframe+0x76/0x7e

[me@linux.beauty: move helper to avoid forward declaration, per Baoquan]

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

ext4: move ext4percpuparaminit() before ext4mbinit()

When running kvm-xfstests -c ext4/1k -C 1 generic/383 with the DOUBLECHECK macro defined, the following panic is triggered:

================================================================== EXT4-fs error (device vdc): ext4validateblockbitmap:423: comm mount: bg 0: bad block bitmap checksum BUG: unable to handle page fault for address: ff110000fa2cc000 PGD 3e01067 P4D 3e02067 PUD 0 Oops: Oops: 0000 [#1] SMP NOPTI CPU: 0 UID: 0 PID: 2386 Comm: mount Tainted: G W 6.18.0-gba65a4e7120a-dirty #1152 PREEMPT(none) RIP: 0010:percpucounteraddbatch+0x13/0xa0 Call Trace: <TASK> ext4markgroupbitmapcorrupted+0xcb/0xe0 ext4validateblockbitmap+0x2a1/0x2f0 ext4readblockbitmap+0x33/0x50 mbgroupbbbitmapalloc+0x33/0x80 ext4mbaddgroupinfo+0x190/0x250 ext4mbinitbackend+0x87/0x290 ext4mbinit+0x456/0x640 ext4fillsuper+0x1072/0x1680 ext4fillsuper+0xd3/0x280 gettreebdevflags+0x132/0x1d0 vfsgettree+0x29/0xd0 vfscmdcreate+0x59/0xe0 dosysfsconfig+0x4f6/0x6b0 dosyscall64+0x50/0x1f0 entrySYSCALL64afterhwframe+0x76/0x7e ==================================================================

This issue can be reproduced using the following commands: mkfs.ext4 -F -q -b 1024 /dev/sda 5G tune2fs -O quota,project /dev/sda mount /dev/sda /tmp/test

With DOUBLECHECK defined, mbgroupbbbitmapalloc() reads and validates the block bitmap. When the validation fails, ext4markgroupbitmapcorrupted() attempts to update sbi->sfreeclusterscounter. However, this percpucounter has not been initialized yet at this point, which leads to the panic described above.

Fix this by moving the execution of ext4percpuparaminit() to occur before ext4mbinit(), ensuring the per-CPU counters are initialized before they are used.

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

drm: Account property blob allocations to memcg

DRMIOCTLMODECREATEPROPBLOB allows userspace to allocate arbitrary-sized property blobs backed by kernel memory.

Currently, the blob data allocation is not accounted to the allocating process's memory cgroup, allowing unprivileged users to trigger unbounded kernel memory consumption and potentially cause system-wide OOM.

Mark the property blob data allocation with GFPKERNELACCOUNT so that the memory is properly charged to the caller's memcg. This ensures existing cgroup memory limits apply and prevents uncontrolled kernel memory growth without introducing additional policy or per-file limits.

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

mm/hugetlb: restore failed global reservations to subpool

Commit a833a693a490 ("mm: hugetlb: fix incorrect fallback for subpool") fixed an underflow error for hstate->resvhugepages caused by incorrectly attributing globally requested pages to the subpool's reservation.

Unfortunately, this fix also introduced the opposite problem, which would leave spool->usedhpages elevated if the globally requested pages could not be acquired. This is because while a subpool's reserve pages only accounts for what is requested and allocated from the subpool, its "used" counter keeps track of what is consumed in total, both from the subpool and globally. Thus, we need to adjust spool->usedhpages in the other direction, and make sure that globally requested pages are uncharged from the subpool's used counter.

Each failed allocation attempt increments the usedhpages counter by how many pages were requested from the global pool. Ultimately, this renders the subpool unusable, as usedhpages approaches the max limit.

The issue can be reproduced as follows: 1. Allocate 4 hugetlb pages 2. Create a hugetlb mount with max=4, min=2 3. Consume 2 pages globally 4. Request 3 pages from the subpool (2 from subpool + 1 from global) 4.1 hugepagesubpoolgetpages(spool, 3) succeeds. usedhpages += 3 4.2 hugetlbacctmemory(h, 1) fails: no global pages left usedhpages -= 2 5. Subpool now has usedhpages = 1, despite not being able to successfully allocate any hugepages. It believes it can now only allocate 3 more hugepages, not 4.

With each failed allocation attempt incrementing the used counter, the subpool eventually reaches a point where its used counter equals its max counter. At that point, any future allocations that try to allocate hugeTLB pages from the subpool will fail, despite the subpool not having any of its hugeTLB pages consumed by any user.

Once this happens, there is no way to make the subpool usable again, since there is no way to decrement the used counter as no process is really consuming the hugeTLB pages.

The underflow issue that the original commit fixes still remains fixed as well.

Without this fix, usedhpages would keep on leaking if hugetlbacctmemory() fails.

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

mm/slab: do not access current->memsallowedseq if !allowspin

Lockdep complains when getfromanypartial() is called in an NMI context, because current->memsallowedseq is seqcountspinlockt and not NMI-safe:

================================ WARNING: inconsistent lock state 6.19.0-rc5-kfree-rcu+ #315 Tainted: G N -------------------------------- inconsistent {INITIAL USE} -> {IN-NMI} usage. kunittrycatch/9989 [HC1[1]:SC0[0]:HE0:SE1] takes: ffff889085799820 (&s->seqcount#3){.-.-}-{0:0}, at: slaballoc+0x58f/0xc00 {INITIAL USE} state was registered at: lockacquire+0x185/0x320 kernelinitfreeable+0x391/0x1150 kernelinit+0x1f/0x220 retfromfork+0x736/0x8f0 retfromforkasm+0x1a/0x30 irq event stamp: 56 hardirqs last enabled at (55): [<ffffffff850a68d7>] rawspinunlockirq+0x27/0x70 hardirqs last disabled at (56): [<ffffffff850858ca>] schedule+0x2a8a/0x6630 softirqs last enabled at (0): [<ffffffff81536711>] copyprocess+0x1dc1/0x6a10 softirqs last disabled at (0): [<0000000000000000>] 0x0

other info that might help us debug this: Possible unsafe locking scenario:

CPU0 ---- lock(&s->seqcount#3); <Interrupt> lock(&s->seqcount#3);

DEADLOCK

According to Documentation/locking/seqlock.rst, seqcountt is not NMI-safe and seqcountlatcht should be used when read path can interrupt the write-side critical section. In this case, do not access current->memsallowedseq and avoid retry.

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

Bluetooth: hcisync: annotate data-races around hdev->reqstatus

hcicmdsyncsk() sets hdev->reqstatus under hdev->reqlock:

hdev->reqstatus = HCIREQPEND;

However, several other functions read or write hdev->reqstatus without holding any lock:

- hcisendcmdsync() reads reqstatus in hcicmdwork (workqueue) - hcicmdsynccomplete() reads/writes from HCI event completion - hcicmdsynccancel() / hcicmdsynccancelsync() read/write - hciabortconn() reads in connection abort path

Since hcicmdsyncsk() runs on hdev->reqworkqueue while hcisendcmdsync() runs on hdev->workqueue, these are different workqueues that can execute concurrently on different CPUs. The plain C accesses constitute a data race.

Add READONCE()/WRITEONCE() annotations on all concurrent accesses to hdev->reqstatus to prevent potential compiler optimizations that could affect correctness (e.g., load fusing in the waitevent condition or store reordering).

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

btrfs: fix zero size inode with non-zero size after log replay

When logging that an inode exists, as part of logging a new name or logging new dir entries for a directory, we always set the generation of the logged inode item to 0. This is to signal during log replay (in overwriteitem()), that we should not set the isize since we only logged that an inode exists, so the isize of the inode in the subvolume tree must be preserved (as when we log new names or that an inode exists, we don't log extents).

This works fine except when we have already logged an inode in full mode or it's the first time we are logging an inode created in a past transaction, that inode has a new isize of 0 and then we log a new name for the inode (due to a new hardlink or a rename), in which case we log an isize of 0 for the inode and a generation of 0, which causes the log replay code to not update the inode's isize to 0 (in overwriteitem()).

An example scenario:

mkdir /mnt/dir xfsio -f -c "pwrite 0 64K" /mnt/dir/foo

sync

xfsio -c "truncate 0" -c "fsync" /mnt/dir/foo

ln /mnt/dir/foo /mnt/dir/bar

xfsio -c "fsync" /mnt/dir

<power fail>

After log replay the file remains with a size of 64K. This is because when we first log the inode, when we fsync file foo, we log its current isize of 0, and then when we create a hard link we log again the inode in exists mode (LOGINODEEXISTS) but we set a generation of 0 for the inode item we add to the log tree, so during log replay overwriteitem() sees that the generation is 0 and isize is 0 so we skip updating the inode's isize from 64K to 0.

Fix this by making sure at fillinodeitem() we always log the real generation of the inode if it was logged in the current transaction with the isize we logged before. Also if an inode created in a previous transaction is logged in exists mode only, make sure we log the isize stored in the inode item located from the commit root, so that if we log multiple times that the inode exists we get the correct isize.

A test case for fstests will follow soon.

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

srcu: Use irqwork to start GP in tiny SRCU

Tiny SRCU's srcugpstartifneeded() directly calls schedulework(), which acquires the workqueue pool->lock.

This causes a lockdep splat when callsrcu() is called with a scheduler lock held, due to:

callsrcu() [holding pilock] srcugpstartifneeded() schedulework() -> pool->lock

workqueueinit() / createworker() [holding pool->lock] wakeupprocess() -> trytowakeup() -> pilock

Also add irqworksync() to cleanupsrcustruct() to prevent a use-after-free if a queued irqwork fires after cleanup begins.

Tested with rcutorture SRCU-T and no lockdep warnings.

[ Thanks to Boqun for similar fix in patch "rcu: Use an intermediate irqwork to start processsrcu()" ]

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

x86: shadow stacks: proper error handling for mmap lock

김영민 reports that shstkpopsigframe() doesn't check for errors from mmapreadlockkillable(), which is a silly oversight, and also shows that we haven't marked those functions with "mustcheck", which would have immediately caught it.

So let's fix both issues.

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

soc: qcom: pd-mapper: Fix element length in servreglocpfrreqei

It looks element length declared in servreglocpfrreqei for reason not matching servreglocpfrreq's reason field due which we could observe decoding error on PD crash.

qmidecodestringelem: String len 81 >= Max Len 65

Fix this by matching with servreglocpfrreq's reason field.

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

xfrm: account XFRMAIFID in aevent size calculation

xfrmgetae() allocates the reply skb with xfrmaeventmsgsize(), then buildaevent() appends attributes including XFRMAIFID when x->ifid is set.

xfrmaeventmsgsize() does not include space for XFRMAIFID. For states with ifid, buildaevent() can fail with -EMSGSIZE and hit BUGON(err < 0) in xfrmgetae(), turning a malformed netlink interaction into a kernel panic.

Account XFRMAIFID in the size calculation unconditionally and replace the BUGON with normal error unwinding.

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

drm/vc4: Fix memory leak of BO array in hang state

The hang state's BO array is allocated separately with kzalloc() in vc4savehangstate() but never freed in vc4freehangstate(). Add the missing kfree() for the BO array before freeing the hang state struct.