OESA-2025-1463

The Linux Kernel, the operating system core itself.

Security Fix(es):

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

PCI/ASPM: Fix link state exit during switch upstream function removal

Before 456d8aa37d0f ("PCI/ASPM: Disable ASPM on MFD function removal to avoid use-after-free"), we would free the ASPM link only after the last function on the bus pertaining to the given link was removed.

That was too late. If function 0 is removed before sibling function, link->downstream would point to free'd memory after.

After above change, we freed the ASPM parent link state upon any function removal on the bus pertaining to a given link.

That is too early. If the link is to a PCIe switch with MFD on the upstream port, then removing functions other than 0 first would free a link which still remains parent_link to the remaining downstream ports.

The resulting GPFs are especially frequent during hot-unplug, because pciehp removes devices on the link bus in reverse order.

On that switch, function 0 is the virtual P2P bridge to the internal bus. Free exactly when function 0 is removed -- before the parent link is obsolete, but after all subordinate links are gone.

kwilczynski: commit log

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

jfs: add check read-only before truncation in jfstruncatenolock()

Added a check for "read-only" mode in the jfs_truncate_nolock function to avoid errors related to writing to a read-only filesystem.

Call stack:

blockwritebegin() { jfswritefailed() { jfstruncate() { jfstruncatenolock() { txEnd() { ... log = JFSSBI(tblk->sb)->log; // (log == NULL)

If the isReadOnly(ip) condition is triggered in jfs_truncate_nolock, the function execution will stop, and no further data modification will occur. Instead, the xtTruncate function will be called with the "COMMIT_WMAP" flag, preventing modifications in "read-only" mode.(CVE-2024-58094)

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

vmxnet3: Fix packet corruption in vmxnet3xdpxmit_frame

Andrew and Nikolay reported connectivity issues with Cilium's service load-balancing in case of vmxnet3.

If a BPF program for native XDP adds an encapsulation header such as IPIP and transmits the packet out the same interface, then in case of vmxnet3 a corrupted packet is being sent and subsequently dropped on the path.

vmxnet3xdpxmitframe() which is called e.g. via vmxnet3runxdp() through vmxnet3xdpxmitback() calculates an incorrect DMA address:

page = virttopage(xdpf->data); tbi->dmaaddr = pagepoolgetdmaaddr(page) + VMXNET3XDPHEADROOM; dmasyncsinglefordevice(&adapter->pdev->dev, tbi->dmaaddr, bufsize, DMATO_DEVICE);

The above assumes a fixed offset (VMXNET3XDPHEADROOM), but the XDP BPF program could have moved xdp->data. While the passed bufsize is correct (xdpf->len), the dmaaddr needs to have a dynamic offset which can be calculated as xdpf->data - (void *)xdpf, that is, xdp->data - xdp->datahardstart.(CVE-2024-58099)

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

rds: sysctl: rdstcp{rcv,snd}buf: avoid using current->nsproxy

As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:

• Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.

• current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).

The per-netns structure can be obtained from the table->data using container_of(), then the 'net' one can be retrieved from the listen socket (if available).(CVE-2025-21635)

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

net: hns3: make sure ptp clock is unregister and freed if hclgeptpget_cycle returns an error

During the initialization of ptp, hclgeptpgetcycle might return an error and returned directly without unregister clock and free it. To avoid that, call hclgeptpdestroyclock to unregist and free clock if hclgeptpget_cycle failed.(CVE-2025-21924)

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

HID: appleir: Fix potential NULL dereference at raw event handle

Syzkaller reports a NULL pointer dereference issue in input_event().

BUG: KASAN: null-ptr-deref in instrumentatomicread include/linux/instrumented.h:68 [inline] BUG: KASAN: null-ptr-deref in testbit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] BUG: KASAN: null-ptr-deref in iseventsupported drivers/input/input.c:67 [inline] BUG: KASAN: null-ptr-deref in input_event+0x42/0xa0 drivers/input/input.c:395 Read of size 8 at addr 0000000000000028 by task syz-executor199/2949

CPU: 0 UID: 0 PID: 2949 Comm: syz-executor199 Not tainted 6.13.0-rc4-syzkaller-00076-gf097a36ef88d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 Call Trace: <IRQ> _dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 kasanreport+0xd9/0x110 mm/kasan/report.c:602 checkregioninline mm/kasan/generic.c:183 [inline] kasancheckrange+0xef/0x1a0 mm/kasan/generic.c:189 instrumentatomicread include/linux/instrumented.h:68 [inline] _testbit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline] iseventsupported drivers/input/input.c:67 [inline] inputevent+0x42/0xa0 drivers/input/input.c:395 inputreportkey include/linux/input.h:439 [inline] keydown drivers/hid/hid-appleir.c:159 [inline] appleirrawevent+0x3e5/0x5e0 drivers/hid/hid-appleir.c:232 _hidinputreport.constprop.0+0x312/0x440 drivers/hid/hid-core.c:2111 hidctrl+0x49f/0x550 drivers/hid/usbhid/hid-core.c:484 _usbhcdgivebackurb+0x389/0x6e0 drivers/usb/core/hcd.c:1650 usbhcdgivebackurb+0x396/0x450 drivers/usb/core/hcd.c:1734 dummytimer+0x17f7/0x3960 drivers/usb/gadget/udc/dummyhcd.c:1993 _runhrtimer kernel/time/hrtimer.c:1739 [inline] _hrtimerrunqueues+0x20a/0xae0 kernel/time/hrtimer.c:1803 hrtimerrunsoftirq+0x17d/0x350 kernel/time/hrtimer.c:1820 handlesoftirqs+0x206/0x8d0 kernel/softirq.c:561 _dosoftirq kernel/softirq.c:595 [inline] invokesoftirq kernel/softirq.c:435 [inline] _irqexitrcu+0xfa/0x160 kernel/softirq.c:662 irqexitrcu+0x9/0x30 kernel/softirq.c:678 instrsysvecapictimerinterrupt arch/x86/kernel/apic/apic.c:1049 [inline] sysvecapictimerinterrupt+0x90/0xb0 arch/x86/kernel/apic/apic.c:1049 </IRQ> <TASK> asmsysvecapictimerinterrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702 _modtimer+0x8f6/0xdc0 kernel/time/timer.c:1185 addtimer+0x62/0x90 kernel/time/timer.c:1295 scheduletimeout+0x11f/0x280 kernel/time/sleeptimeout.c:98 usbhidwaitio+0x1c7/0x380 drivers/hid/usbhid/hid-core.c:645 usbhidinitreports+0x19f/0x390 drivers/hid/usbhid/hid-core.c:784 hiddevioctl+0x1133/0x15b0 drivers/hid/usbhid/hiddev.c:794 vfsioctl fs/ioctl.c:51 [inline] _dosysioctl fs/ioctl.c:906 [inline] _sesysioctl fs/ioctl.c:892 [inline] _x64sysioctl+0x190/0x200 fs/ioctl.c:892 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcd/0x250 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f </TASK>

This happens due to the malformed report items sent by the emulated device which results in a report, that has no fields, being added to the report list. Due to this appleirinputconfigured() is never called, hidinputconnect() fails which results in the HIDCLAIMEDINPUT flag is not being set. However, it does not make appleirprobe() fail and lets the event callback to be called without the associated input device.

Thus, add a check for the HIDCLAIMEDINPUT flag and leave the event hook early if the driver didn't claim any inputdev for some reason. Moreover, some other hid drivers accessing inputdev in their event callbacks do have similar checks, too.

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-21948)

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

scsi: qla1280: Fix kernel oops when debug level > 2

A null dereference or oops exception will eventually occur when qla1280.c driver is compiled with DEBUGQLA1280 enabled and qldebuglevel > 2. I think its clear from the code that the intention here is sgdmalen(s) not length of sgnext(s) when printing the debug info.(CVE-2025-21957)

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

wifi: cfg80211: cancel wiphy_work before freeing wiphy

A wiphywork can be queued from the moment the wiphy is allocated and initialized (i.e. wiphynewnm). When a wiphywork is queued, the rdev::wiphy_work is getting queued.

If wiphyfree is called before the rdev::wiphywork had a chance to run, the wiphy memory will be freed, and then when it eventally gets to run it'll use invalid memory.

Fix this by canceling the work before freeing the wiphy.(CVE-2025-21979)

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

RDMA/hns: Fix soft lockup during bt pages loop

Driver runs a for-loop when allocating bt pages and mapping them with buffer pages. When a large buffer (e.g. MR over 100GB) is being allocated, it may require a considerable loop count. This will lead to soft lockup:

    watchdog: BUG: soft lockup - CPU#27 stuck for 22s!
    ...
    Call trace:
     hem_list_alloc_mid_bt+0x124/0x394 [hns_roce_hw_v2]
     hns_roce_hem_list_request+0xf8/0x160 [hns_roce_hw_v2]
     hns_roce_mtr_create+0x2e4/0x360 [hns_roce_hw_v2]
     alloc_mr_pbl+0xd4/0x17c [hns_roce_hw_v2]
     hns_roce_reg_user_mr+0xf8/0x190 [hns_roce_hw_v2]
     ib_uverbs_reg_mr+0x118/0x290

    watchdog: BUG: soft lockup - CPU#35 stuck for 23s!
    ...
    Call trace:
     hns_roce_hem_list_find_mtt+0x7c/0xb0 [hns_roce_hw_v2]
     mtr_map_bufs+0xc4/0x204 [hns_roce_hw_v2]
     hns_roce_mtr_create+0x31c/0x3c4 [hns_roce_hw_v2]
     alloc_mr_pbl+0xb0/0x160 [hns_roce_hw_v2]
     hns_roce_reg_user_mr+0x108/0x1c0 [hns_roce_hw_v2]
     ib_uverbs_reg_mr+0x120/0x2bc

Add a condresched() to fix soft lockup during these loops. In order not to affect the allocation performance of normal-size buffer, set the loop count of a 100GB MR as the threshold to call condresched().(CVE-2025-22010)

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

soc: qcom: pdr: Fix the potential deadlock

When some client process A call pdraddlookup() to add the look up for the service and does schedule locator work, later a process B got a new server packet indicating locator is up and call pdrlocatornewserver() which eventually sets pdr->locatorinit_complete to true which process A sees and takes list lock and queries domain list but it will timeout due to deadlock as the response will queued to the same qmi->wq and it is ordered workqueue and process B is not able to complete new server request work due to deadlock on list lock.

Fix it by removing the unnecessary list iteration as the list iteration is already being done inside locator work, so avoid it here and just call schedule_work() here.

   Process A                        Process B

                                 process_scheduled_works()

pdraddlookup() qmidatareadywork() processscheduledworks() pdrlocatornewserver() pdr->locatorinitcomplete=true; pdrlocatorwork() mutexlock(&pdr->listlock);

 pdr_locate_service()                  mutex_lock(&pdr->list_lock);

  pdr_get_domain_list()
   pr_err("PDR: %s get domain list
           txn wait failed: %d\n",
           req->service_name,
           ret);

Timeout error log due to deadlock:

" PDR: tms/servreg get domain list txn wait failed: -110 PDR: service lookup for msm/adsp/sensor_pd:tms/servreg failed: -110 "

Thanks to Bjorn and Johan for letting me know that this commit also fixes an audio regression when using the in-kernel pd-mapper as that makes it easier to hit this race. 1

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

mm/migrate: fix shmem xarray update during migration

A shmem folio can be either in page cache or in swap cache, but not at the same time. Namely, once it is in swap cache, folio->mapping should be NULL, and the folio is no longer in a shmem mapping.

In _foliomigratemapping(), to determine the number of xarray entries to update, foliotestswapbacked() is used, but that conflates shmem in page cache case and shmem in swap cache case. It leads to xarray multi-index entry corruption, since it turns a sibling entry to a normal entry during xasstore() (see [1] for a userspace reproduction). Fix it by only using foliotestswapcache() to determine whether xarray is storing swap cache entries or not to choose the right number of xarray entries to update.

[1] https://lore.kernel.org/linux-mm/Z8idPCkaJW1IChjT@casper.infradead.org/

Note: In _splithugepage(), foliotestanon() && foliotestswapcache() is used to get swapcache address space, but that ignores the shmem folio in swap cache case. It could lead to NULL pointer dereferencing when a in-swap-cache shmem folio is split at _xastore(), since !foliotestanon() is true and folio->mapping is NULL. But fortunately, its caller splithugepagetolisttoorder() bails out early with EBUSY when folio->mapping is NULL. So no need to take care of it here.(CVE-2025-22015)

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

media: streamzap: fix race between device disconnection and urb callback

Syzkaller has reported a general protection fault at function irraweventstorewithfilter(). This crash is caused by a NULL pointer dereference of dev->raw pointer, even though it is checked for NULL in the same function, which means there is a race condition. It occurs due to the incorrect order of actions in the streamzapdisconnect() function: rcunregisterdevice() is called before usbkillurb(). The dev->raw pointer is freed and set to NULL in rcunregisterdevice(), and only after that usbkillurb() waits for in-progress requests to finish.

If rcunregisterdevice() is called while streamzapcallback() handler is not finished, this can lead to accessing freed resources. Thus rcunregisterdevice() should be called after usbkill_urb().

Found by Linux Verification Center (linuxtesting.org) with Syzkaller.(CVE-2025-22027)

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

ksmbd: fix session use-after-free in multichannel connection

There is a race condition between session setup and ksmbdsessionsderegister. The session can be freed before the connection is added to channel list of session. This patch check reference count of session before freeing it.(CVE-2025-22040)

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

ksmbd: fix use-after-free in ksmbdsessionsderegister()

In multichannel mode, UAF issue can occur in session_deregister when the second channel sets up a session through the connection of the first channel. session that is freed through the global session table can be accessed again through ->sessions of connection.(CVE-2025-22041)

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

acpi: nfit: fix narrowing conversion in acpinfitctl

Syzkaller has reported a warning in tonfitbusuuid(): "only secondary bus families can be translated". This warning is emited if the argument is equal to NVDIMMBUSFAMILYNFIT == 0. Function acpinfitctl() first verifies that a user-provided value callpkg->ndfamily of type u64 is not equal to 0. Then the value is converted to int, and only after that is compared to NVDIMMBUSFAMILYMAX. This can lead to passing an invalid argument to acpinfitctl(), if callpkg->nd_family is non-zero, while the lower 32 bits are zero.

Furthermore, it is best to return EINVAL immediately upon seeing the invalid user input. The WARNING is insufficient to prevent further undefined behavior based on other invalid user input.

All checks of the input value should be applied to the original variable callpkg->ndfamily.

iweiny: update commit message

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

x86/mm: Fix flushtlbrange() when used for zapping normal PMDs

On the following path, flushtlbrange() can be used for zapping normal PMD entries (PMD entries that point to page tables) together with the PTE entries in the pointed-to page table:

collapse_pte_mapped_thp
  pmdp_collapse_flush
    flush_tlb_range

The arm64 version of flushtlbrange() has a comment describing that it can be used for page table removal, and does not use any last-level invalidation optimizations. Fix the X86 version by making it behave the same way.

Currently, X86 only uses this information for the following two purposes, which I think means the issue doesn't have much impact:

• In nativeflushtlb_multi() for checking if lazy TLB CPUs need to be IPI'd to avoid issues with speculative page table walks.
• In Hyper-V TLB paravirtualization, again for lazy TLB stuff.

The patch "x86/mm: only invalidate final translations with INVLPGB" which is currently under review (see <https://lore.kernel.org/all/20241230175550.4046587-13-riel@surriel.com/>) would probably be making the impact of this a lot worse.(CVE-2025-22045)

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

LoongArch: BPF: Don't override subprog's return value

The verifier test calls: div by 0 in subprog triggers a panic at the ld.bu instruction. The ld.bu insn is trying to load byte from memory address returned by the subprog. The subprog actually set the correct address at the a5 register (dedicated register for BPF return values). But at commit 73c359d1d356 ("LoongArch: BPF: Sign-extend return values") we also sign extended a5 to the a0 register (return value in LoongArch). For function call insn, we later propagate the a0 register back to a5 register. This is right for native calls but wrong for bpf2bpf calls which expect zero-extended return value in a5 register. So only move a0 to a5 for native calls (i.e. non-BPFPSEUDOCALL).(CVE-2025-22048)

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

spufs: fix gang directory lifetimes

prior to "[POWERPC] spufs: Fix gang destroy leaks" we used to have a problem with gang lifetimes - creation of a gang returns opened gang directory, which normally gets removed when that gets closed, but if somebody has created a context belonging to that gang and kept it alive until the gang got closed, removal failed and we ended up with a leak.

Unfortunately, it had been fixed the wrong way. Dentry of gang directory was no longer pinned, and rmdir on close was gone. One problem was that failure of open kept calling simple_rmdir() as cleanup, which meant an unbalanced dput(). Another bug was in the success case - gang creation incremented link count on root directory, but that was no longer undone when gang got destroyed.

Fix consists of * reverting the commit in question * adding a counter to gang, protected by ->irwsem of gang directory inode. * having it set to 1 at creation time, dropped in both spufsdirclose() and spufsgangclose() and bumped in spufscreatecontext(), provided that it's not 0. * using simplerecursive_removal() to take the gang directory out when counter reaches zero.(CVE-2025-22072)

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

PCI: brcmstb: Fix error path after a call to regulatorbulkget()

If the regulatorbulkget() returns an error and no regulators are created, we need to set their number to zero.

If we don't do this and the PCIe link up fails, a call to the regulatorbulkfree() will result in a kernel panic.

While at it, print the error value, as we cannot return an error upwards as the kernel will WARN() on an error from add_bus().

kwilczynski: commit log, use comma in the message to match style with other similar messages

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

ext4: avoid journaling sb update on error if journal is destroying

Presently we always BUGON if trying to start a transaction on a journal marked with JBD2UNMOUNT, since this should never happen. However, while ltp running stress tests, it was observed that in case of some error handling paths, it is possible for updatesuperwork to start a transaction after the journal is destroyed eg:

(umount) ext4killsb killblocksuper genericshutdownsuper syncfilesystem /* commits all txns */ evictinodes /* might start a new txn / ext4_put_super flush_work(&sbi->s_sb_upd_work) / flush the workqueue */ jbd2journaldestroy journalkillthread journal->jflags |= JBD2UNMOUNT; jbd2journalcommittransaction jbd2journalgetdescriptorbuffer jbd2journalbmap ext4journalbmap ext4mapblocks ... ext4inodeerror ext4handleerror schedulework(&sbi->ssbupd_work)

                                           /* work queue kicks in */
                                           update_super_work
                                             jbd2_journal_start
                                               start_this_handle
                                                 BUG_ON(journal->j_flags &
                                                        JBD2_UNMOUNT)

Hence, introduce a new mount flag to indicate journal is destroying and only do a journaled (and deferred) update of sb if this flag is not set. Otherwise, just fallback to an un-journaled commit.

Further, in the journal destroy path, we have the following sequence:

1. Set mount flag indicating journal is destroying
2. force a commit and wait for it
3. flush pending sb updates

This sequence is important as it ensures that, after this point, there is no sb update that might be journaled so it is safe to update the sb outside the journal. (To avoid race discussed in 2d01ddc86606)

Also, we don't need a similar check in ext4grplocked_error since it is only called from mballoc and AFAICT it would be always valid to schedule work here.(CVE-2025-22113)

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

ext4: fix out-of-bound read in ext4xattrinodedecref_all()

There's issue as follows: BUG: KASAN: use-after-free in ext4xattrinodedecref_all+0x6ff/0x790 Read of size 4 at addr ffff88807b003000 by task syz-executor.0/15172

CPU: 3 PID: 15172 Comm: syz-executor.0 Call Trace: _dumpstack lib/dumpstack.c:82 [inline] dumpstack+0xbe/0xfd lib/dumpstack.c:123 printaddressdescription.constprop.0+0x1e/0x280 mm/kasan/report.c:400 _kasanreport.cold+0x6c/0x84 mm/kasan/report.c:560 kasanreport+0x3a/0x50 mm/kasan/report.c:585 ext4xattrinodedecrefall+0x6ff/0x790 fs/ext4/xattr.c:1137 ext4xattrdeleteinode+0x4c7/0xda0 fs/ext4/xattr.c:2896 ext4evictinode+0xb3b/0x1670 fs/ext4/inode.c:323 evict+0x39f/0x880 fs/inode.c:622 iputfinal fs/inode.c:1746 [inline] iput fs/inode.c:1772 [inline] iput+0x525/0x6c0 fs/inode.c:1758 ext4orphancleanup fs/ext4/super.c:3298 [inline] ext4fillsuper+0x8c57/0xba40 fs/ext4/super.c:5300 mountbdev+0x355/0x410 fs/super.c:1446 legacygettree+0xfe/0x220 fs/fscontext.c:611 vfsgettree+0x8d/0x2f0 fs/super.c:1576 donewmount fs/namespace.c:2983 [inline] pathmount+0x119a/0x1ad0 fs/namespace.c:3316 domount+0xfc/0x110 fs/namespace.c:3329 _dosysmount fs/namespace.c:3540 [inline] _sesysmount+0x219/0x2e0 fs/namespace.c:3514 dosyscall64+0x33/0x40 arch/x86/entry/common.c:46 entrySYSCALL64after_hwframe+0x67/0xd1

Memory state around the buggy address: ffff88807b002f00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff88807b002f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >ffff88807b003000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ^ ffff88807b003080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ffff88807b003100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

Above issue happens as ext4xattrdeleteinode() isn't check xattr is valid if xattr is in inode. To solve above issue call xattrcheckinode() check if xattr if valid in inode. In fact, we can directly verify in ext4igetextrainode(), so that there is no divergent verification.(CVE-2025-22121)

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

md/raid1,raid10: don't ignore IO flags

If blk-wbt is enabled by default, it's found that raid write performance is quite bad because all IO are throttled by wbt of underlying disks, due to flag REQ_IDLE is ignored. And turns out this behaviour exist since blk-wbt is introduced.

Other than REQIDLE, other flags should not be ignored as well, for example REQMETA can be set for filesystems, clearing it can cause priority reverse problems; And REQ_NOWAIT should not be cleared as well, because io will wait instead of failing directly in underlying disks.

Fix those problems by keep IO flags from master bio.

Fises: f51d46d0e7cb ("md: add support for REQ_NOWAIT")(CVE-2025-22125)

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

LoongArch: BPF: Fix off-by-one error in build_prologue()

Vincent reported that running BPF progs with tailcalls on LoongArch causes kernel hard lockup. Debugging the issues shows that the JITed image missing a jirl instruction at the end of the epilogue.

There are two passes in JIT compiling, the first pass set the flags and the second pass generates JIT code based on those flags. With BPF progs mixing bpf2bpf and tailcalls, buildprologue() generates N insns in the first pass and then generates N+1 insns in the second pass. This makes epilogueoffset off by one and we will jump to some unexpected insn and cause lockup. Fix this by inserting a nop insn.(CVE-2025-37893)