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

NTB: epf: Avoid pciiounmap() with offset when PEERSPAD and CONFIG share BAR

When BARPEERSPAD and BARCONFIG share one PCI BAR, the module teardown path ends up calling pciiounmap() on the same iomem with some offset, which is unnecessary and triggers a kernel warning like the following:

Trying to vunmap() nonexistent vm area (0000000069a5ffe8) WARNING: mm/vmalloc.c:3470 at vunmap+0x58/0x68, CPU#5: modprobe/2937 [...] Call trace: vunmap+0x58/0x68 (P) iounmap+0x34/0x48 pciiounmap+0x2c/0x40 ntbepfpciremove+0x44/0x80 [ntbhwepf] pcideviceremove+0x48/0xf8 deviceremove+0x50/0x88 devicereleasedriverinternal+0x1c8/0x228 driverdetach+0x50/0xb0 busremovedriver+0x74/0x100 driverunregister+0x34/0x68 pciunregisterdriver+0x34/0xa0 ntbepfpcidriverexit+0x14/0xfe0 [ntbhwepf] [...]

Fix it by unmapping only when PEERSPAD and CONFIG use difference bars.

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

Bluetooth: ISO: drop ISOEND frames received without prior ISOSTART

ISO data PDUs carry a packet-boundary flag indicating START, CONT, END or SINGLE. The ISOCONT branch of isorecv() guards against a missing ISOSTART by checking conn->rxlen before touching conn->rxskb, but ISOEND does not.

If a peer sends an ISOEND as the first packet on a fresh ISO connection, conn->rxskb is still NULL and conn->rxlen is zero, so skbput(conn->rxskb, ...) dereferences NULL and oopses. For BIS, where receivers sync to a broadcaster without pairing, any broadcaster on the air can trigger this.

Mirror the ISOCONT check at the top of ISOEND so a stray end fragment is logged and dropped instead of crashing the host.

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

drm/amd/display: Wrap DCN32 phantom-plane allocation in DCRUNWITHPREEMPTIONENABLED

[Why] dcn32validatebandwidth() wraps dcn32internalvalidatebw() with DCFPSTART()/DCFPEND(). In x86 non-RT, DCFPSTART takes fpregslock(), which disables local softirqs.

The DML1 path through dcn32enablephantomplane() calls kvzalloc() to allocate ~335 KiB for dcplanestate. This triggers the vmalloc path, which calls BUGON(ininterrupt()) because it's invoked within the FPU-enabled (softirq disabled) region, leading to a kernel crash.

[How] Wrap the dcstatecreatephantomplane() call with the DCRUNWITHPREEMPTIONENABLED() macro to allow preemption during this memory allocation.

(cherry picked from commit 885ccbef7b94a8b38f69c4211c679021aa27ad11)

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

drm/gma500/oaktraillvds: fix hang on init failure

The LVDS init code looks up an I2C adapter using i2cgetadapter() and tries to read the EDID before falling back to allocating and registering its own adapter.

The error handling does not separate these cases so on a late init failure it will try to deregister and free also an adapter that had previously been registered. Since i2cgetadapter() takes another reference to the adapter, deregistration hangs indefinitely while waiting for the reference to be released.

Fix this by only destroying adapters allocated during LVDS init on errors.

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

ceph: fix BUGON in cephbuildxattrsblob() due to stale blob size

The generic/642 test-case can reproduce the kernel crash:

[40243.605254] ------------[ cut here ]------------ [40243.605956] kernel BUG at fs/ceph/xattr.c:918! [40243.607142] Oops: invalid opcode: 0000 [#1] SMP PTI [40243.608067] CPU: 7 UID: 0 PID: 498762 Comm: kworker/7:1 Not tainted 7.0.0-rc7+ #3 PREEMPT(full) [40243.609700] Hardware name: QEMU Ubuntu 25.10 PC v2 (i440FX + PIIX, + 10.1 machine, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 [40243.611820] Workqueue: ceph-msgr cephconworkfn [40243.612715] RIP: 0010:cephbuildxattrsblob+0x1b8/0x1e0 [40243.613731] Code: 0f 84 82 fe ff ff e9 cf 8e 56 ff 48 8d 65 e8 31 c0 5b 41 5c 41 5d 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 c3 cc cc cc cc <0f> 0b 4c 8b 62 08 41 8b 85 24 07 00 00 49 83 c4 04 41 89 44 24 fc [40243.616888] RSP: 0018:ffffcc80c4d4b688 EFLAGS: 00010287 [40243.617773] RAX: 0000000000010026 RBX: 0000000000000001 RCX: 0000000000000000 [40243.618928] RDX: ffff8a773798dee0 RSI: 0000000000000000 RDI: 0000000000000000 [40243.620158] RBP: ffffcc80c4d4b6a0 R08: 0000000000000000 R09: 0000000000000000 [40243.621573] R10: 0000000000000000 R11: 0000000000000000 R12: ffff8a75f3b58000 [40243.622907] R13: ffff8a75f3b58000 R14: 0000000000000080 R15: 000000000000bffd [40243.624054] FS: 0000000000000000(0000) GS:ffff8a787d1b4000(0000) knlGS:0000000000000000 [40243.625331] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [40243.626269] CR2: 000072f390b623c0 CR3: 000000011c02a003 CR4: 0000000000372ef0 [40243.627408] Call Trace: [40243.627839] <TASK> [40243.628188] prepcap+0x3fd/0x4a0 [40243.628789] ? dorawspinunlock+0x4e/0xe0 [40243.629474] cephcheckcaps+0x46a/0xc80 [40243.630094] ? lockacquire+0x4a2/0x2650 [40243.630773] ? findheldlock+0x31/0x90 [40243.631347] ? handlecapgrant+0x79f/0x1060 [40243.632068] ? lockrelease+0xd9/0x300 [40243.632696] ? mutexunlockslowpath+0x3e/0x340 [40243.633429] ? lockrelease+0xd9/0x300 [40243.634052] handlecapgrant+0xcf6/0x1060 [40243.634745] cephhandlecaps+0x122b/0x2110 [40243.635415] mdsdispatch+0x5bd/0x2160 [40243.636034] ? cephconprocessmessage+0x65/0x190 [40243.636828] ? lockrelease+0xd9/0x300 [40243.637431] cephconprocessmessage+0x7a/0x190 [40243.638184] ? kfree+0x311/0x4f0 [40243.638749] ? kfree+0x311/0x4f0 [40243.639268] processmessage+0x16/0x1a0 [40243.639915] ? sgfreetable+0x39/0x90 [40243.640572] cephconv2tryread+0xf58/0x2120 [40243.641255] ? lockacquire+0xc8/0x300 [40243.641863] cephconworkfn+0x151/0x820 [40243.642493] processonework+0x22f/0x630 [40243.643093] ? processonework+0x254/0x630 [40243.643770] workerthread+0x1e2/0x400 [40243.644332] ? pfxworkerthread+0x10/0x10 [40243.645020] kthread+0x109/0x140 [40243.645560] ? pfxkthread+0x10/0x10 [40243.646125] retfromfork+0x3f8/0x480 [40243.646752] ? pfxkthread+0x10/0x10 [40243.647316] ? pfxkthread+0x10/0x10 [40243.647919] retfromforkasm+0x1a/0x30 [40243.648556] </TASK> [40243.648902] Modules linked in: overlay hctr2 libpolyval chacha libchacha adiantum libnh libpoly1305 essiv intelraplmsr intelraplcommon inteluncorefrequencycommon skxedaccommon nfit kvmintel kvm irqbypass joydev ghashclmulniintel aesniintel rapl inputleds machid psmouse vga16fb serioraw vgastate floppy i2cpiix4 pataacpi bochs qemufwcfg i2csmbus schfqcodel rbd dmcrypt msr parportpc ppdev lp parport efipstore [40243.654766] ---[ end trace 0000000000000000 ]---

Commit d93231a6bc8a ("ceph: prevent a client from exceeding the MDS maximum xattr size") moved the requiredblobsize computation to before the buildxattrs() call, introducing a race.

buildxattrs() releases and reacquires icephlock during execution. In that window, handlecapgrant() may update ixattrs.blob with a newer MDS-provided blob and bump ixattrs.version. When bui ---truncated---

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

spi: s3c64xx: fix NULL-deref on driver unbind

A change moving DMA channel allocation from probe() back to s3c64xxspipreparetransfer() failed to remove the corresponding deallocation from remove().

Drop the bogus DMA channel release from remove() to avoid triggering a NULL-pointer dereference on driver unbind.

This issue was flagged by Sashiko when reviewing a controller deregistration fix.

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

xfs: fix a resource leak in xfsallocbuftarg()

In the error path, call fsputdax() to drop the DAX device reference.

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

ublk: Validate SQE128 flag before accessing the cmd

ublkctrlcmddump() accesses (header )sqe->cmd before IOURINGFSQE128 flag check. This could cause out of boundary memory access.

Move the SQE128 flag check earlier in ublkctrluringcmd() to return -EINVAL immediately if the flag is not set.

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

soc: mediatek: svs: Fix memory leak in svsenabledebugwrite()

In svsenabledebugwrite(), the buf allocated by memdupusernul() is leaked if kstrtoint() fails.

Fix this by using free(kfree) to automatically free buf, eliminating the need for explicit kfree() calls and preventing leaks.

[Angelo: Added missing cleanup.h inclusion]

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

net/mlx5: Fix deadlock between devlink lock and esw->wq

esw->workqueue executes eswfunctionschangedeventhandler -> eswvfschangedeventhandler and acquires the devlink lock.

.eswitchmodeset (acquires devlink lock in devlinknlpredoit) -> mlx5devlinkeswitchmodeset -> mlx5eswitchdisablelocked -> mlx5eswitcheventhandlerunregister -> flushworkqueue deadlocks when eswvfschangedeventhandler executes.

Fix that by no longer flushing the work to avoid the deadlock, and using a generation counter to keep track of work relevance. This avoids an old handler manipulating an esw that has undergone one or more mode changes: - the counter is incremented in mlx5eswitcheventhandlerunregister. - the counter is read and passed to the ephemeral mlx5hostwork struct. - the work handler takes the devlink lock and bails out if the current generation is different than the one it was scheduled to operate on. - mlx5eswitchcleanup does the final draining before destroying the wq.

No longer flushing the workqueue has the side effect of maybe no longer cancelling pending vportchangehandler work items, but that's ok since those are disabled elsewhere: - mlx5eswitchdisablelocked disables the vport eq notifier. - mlx5eswvportdisable disarms the HW EQ notification and marks vport->enabled under statelock to false to prevent pending vport handler from doing anything. - mlx5eswitchcleanup destroys the workqueue and makes sure all events are disabled/finished.

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

md raid: fix hang when stopping arrays with metadata through dm-raid

When using device-mapper's dm-raid target, stopping a RAID array can cause the system to hang under specific conditions.

This occurs when:

- A dm-raid managed device tree is suspended from top to bottom (the top-level RAID device is suspended first, followed by its underlying metadata and data devices)

- The top-level RAID device is then removed

Removing the top-level device triggers a hang in the following sequence: the dm-raid destructor calls mdstop(), which tries to flush the write-intent bitmap by writing to the metadata sub-devices. However, these devices are already suspended, making them unable to complete the write-intent operations and causing an indefinite block.

Fix:

- Prevent bitmap flushing when mdstop() is called from dm-raid destructor context and avoid a quiescing/unquescing cycle which could also cause I/O

- Still allow write-intent bitmap flushing when called from dm-raid suspend context

This ensures that RAID array teardown can complete successfully even when the underlying devices are in a suspended state.

This second patch uses mdisrdwr() to distinguish between suspend and destructor paths as elaborated on above.

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

x86/kexec: add a sanity check on previous kernel's ima kexec buffer

When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>", the physical range that contains the carried over IMA measurement list may fall outside the truncated RAM leading to a kernel panic.

BUG: unable to handle page fault for address: ffff97793ff47000 RIP: imarestoremeasurementlist+0xdc/0x45a #PF: errorcode(0x0000) – not-present page

Other architectures already validate the range with pageisram(), as done in commit cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") do a similar check on x86.

Without carrying the measurement list across kexec, the attestation would fail.

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

ima: verify the previous kernel's IMA buffer lies in addressable RAM

Patch series "Address page fault in imarestoremeasurementlist()", v3.

When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens.

BUG: unable to handle page fault for address: ffff97793ff47000 RIP: imarestoremeasurementlist+0xdc/0x45a #PF: errorcode(0x0000) not-present page

This happens on x8664 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds")

This patch (of 3):

When the second-stage kernel is booted with a limiting command line (e.g. "mem=<size>"), the IMA measurement buffer handed over from the previous kernel may fall outside the addressable RAM of the new kernel. Accessing such a buffer can fault during early restore.

Introduce a small generic helper, imavalidaterange(), which verifies that a physical [start, end] range for the previous-kernel IMA buffer lies within addressable memory: - On x86, use pfnrangeismapped(). - On OF based architectures, use pageisram().

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

PCI: endpoint: pci-epf-vntb: Stop cmdhandler work in epfntbepccleanup

Disable the delayed work before clearing BAR mappings and doorbells to avoid running the handler after resources have been torn down.

Unable to handle kernel paging request at virtual address ffff800083f46004 [...] Internal error: Oops: 0000000096000007 [#1] SMP [...] Call trace: epfntbcmdhandler+0x54/0x200 [pciepfvntb] (P) processonework+0x154/0x3b0 workerthread+0x2c8/0x400 kthread+0x148/0x210 retfromfork+0x10/0x20

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

PCI: endpoint: pci-epf-vntb: Remove duplicate resource teardown

epfntbepcdestroy() duplicates the teardown that the caller is supposed to perform later. This leads to an oops when .allowlink fails or when .droplink is performed. The following is an example oops of the former case:

Unable to handle kernel paging request at virtual address dead000000000108 [...] [dead000000000108] address between user and kernel address ranges Internal error: Oops: 0000000096000044 [#1] SMP [...] Call trace: pciepcremoveepf+0x78/0xe0 (P) pciprimaryepcepflink+0x88/0xa8 configfssymlink+0x1f4/0x5a0 vfssymlink+0x134/0x1d8 dosymlinkat+0x88/0x138 arm64syssymlinkat+0x74/0xe0 [...]

Remove the helper, and drop pciepcput(). EPC device refcounting is tied to the configfs EPC group lifetime, and pciepcput() in the .droplink path is sufficient.

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

spi: fix statistics allocation

The controller per-cpu statistics is not allocated until after the controller has been registered with driver core, which leaves a window where accessing the sysfs attributes can trigger a NULL-pointer dereference.

Fix this by moving the statistics allocation to controller allocation while tying its lifetime to that of the controller (rather than using implicit devres).

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

drm/logicvc: Fix device node reference leak in logicvcdrmconfigparse()

The logicvcdrmconfigparse() function calls ofgetchildbyname() to find the "layers" node but fails to release the reference, leading to a device node reference leak.

Fix this by using the free(devicenode) cleanup attribute to automatic release the reference when the variable goes out of scope.

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

arm64: io: Extract user memory type in ioremapprot()

The only caller of ioremapprot() outside of the generic ioremap() implementation is genericaccessphys(), which passes a 'pgprott' value determined from the user mapping of the target 'pfn' being accessed by the kernel. On arm64, the 'pgprott' contains all of the non-address bits from the pte, including the permission controls, and so we end up returning a new user mapping from ioremapprot() which faults when accessed from the kernel on systems with PAN:

| Unable to handle kernel read from unreadable memory at virtual address ffff80008ea89000 | ... | Call trace: | memcpyfromio+0x80/0xf8 | genericaccessphys+0x20c/0x2b8 | accessremotevm+0x46c/0x5b8 | accessremotevm+0x18/0x30 | environread+0x238/0x3e8 | vfsread+0xe4/0x2b0 | ksysread+0xcc/0x178 | arm64sysread+0x4c/0x68

Extract only the memory type from the user 'pgprott' in ioremapprot() and assert that we're being passed a user mapping, to protect us against any changes in future that may require additional handling. To avoid falsely flagging users of ioremap(), provide our own ioremap() macro which simply wraps ioremapprot().

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

net: ethernet: mtkethsoc: Reset prog ptr to oldprog in case of error in mtkxdpsetup()

Reset eBPF program pointer to oldprog and do not decrease its ref-count if mtkopen routine in mtkxdpsetup() fails.

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

flexproportions: make fpropnewperiod() hardirq safe

Bernd has reported a lockdep splat from flexible proportions code that is essentially complaining about the following race:

<timer fires> runtimersoftirq - we are in softirq context calltimerfn writeoutperiod fpropnewperiod writeseqcountbegin(&p->sequence);

<hardirq is raised> ... blkmqendrequest() blkupdaterequest() ext4endbio() folioendwriteback() wbwriteoutadd() fpropaddpercpumax() if (unlikely(maxfrac < FPROPFRACBASE)) { fpropfractionpercpu() seq = readseqcountbegin(&p->sequence); - sees odd sequence so loops indefinitely

Note that a deadlock like this is only possible if the bdi has configured maximum fraction of writeout throughput which is very rare in general but frequent for example for FUSE bdis. To fix this problem we have to make sure write section of the sequence counter is irqsafe.

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

mmc: sdhci-of-dwcmshc: Prevent illegal clock reduction in HS200/HS400 mode

When operating in HS200 or HS400 timing modes, reducing the clock frequency below 52MHz will lead to link broken as the Rockchip DWC MSHC controller requires maintaining a minimum clock of 52MHz in these modes.

Add a check to prevent illegal clock reduction through debugfs:

root@debian:/# echo 50000000 > /sys/kernel/debug/mmc0/clock root@debian:/# [ 30.090146] mmc0: running CQE recovery mmc0: cqhci: Failed to halt mmc0: cqhci: spurious TCN for tag 0 WARNING: drivers/mmc/host/cqhci-core.c:797 at cqhciirq+0x254/0x818, CPU#1: kworker/1:0H/24 Modules linked in: CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0H Not tainted 6.19.0-rc1-00001-g09db0998649d-dirty #204 PREEMPT Hardware name: Rockchip RK3588 EVB1 V10 Board (DT) Workqueue: kblockd blkmqrunworkfn pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cqhciirq+0x254/0x818 lr : cqhciirq+0x254/0x818 ...

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

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

ublk: fix deadlock when reading partition table

When one process(such as udev) opens ublk block device (e.g., to read the partition table via bdevopen()), a deadlock[1] can occur:

1. bdevopen() grabs disk->openmutex 2. The process issues read I/O to ublk backend to read partition table 3. In ublkcompleterq(), blkupdaterequest() or blkmqendrequest() runs bio->biendio() callbacks 4. If this triggers fput() on file descriptor of ublk block device, the work may be deferred to current task's task work (see fput() implementation) 5. This eventually calls blkdevrelease() from the same context 6. blkdevrelease() tries to grab disk->openmutex again 7. Deadlock: same task waiting for a mutex it already holds

The fix is to run blkupdaterequest() and blkmqendrequest() with bottom halves disabled. This forces blkdevrelease() to run in kernel work-queue context instead of current task work context, and allows ublk server to make forward progress, and avoids the deadlock.

[axboe: rewrite comment in ublk]

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

nvme-core: fix devpmqos memleak

Call devpmqoshidelatencytolerance() in the error unwind patch to avoid following kmemleak:-

blktests (master) # kmemleak-clear; ./check nvme/044; blktests (master) # kmemleak-scan ; kmemleak-show nvme/044 (Test bi-directional authentication) [passed] runtime 2.111s ... 2.124s unreferenced object 0xffff888110c46240 (size 96): comm "nvme", pid 33461, jiffies 4345365353 (age 75.586s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000069ac2cec>] kmalloctrace+0x25/0x90 [<000000006acc66d5>] devpmqosupdateuserlatencytolerance+0x6f/0x100 [<00000000cc376ea7>] nvmeinitctrl+0x38e/0x410 [nvmecore] [<000000007df61b4b>] 0xffffffffc05e88b3 [<00000000d152b985>] 0xffffffffc05744cb [<00000000f04a4041>] vfswrite+0xc5/0x3c0 [<00000000f9491baf>] ksyswrite+0x5f/0xe0 [<000000001c46513d>] dosyscall64+0x3b/0x90 [<00000000ecf348fe>] entrySYSCALL64afterhwframe+0x72/0xdc

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

usb: host: xhci: Fix potential memory leak in xhciallocstreaminfo()

xhciallocstreaminfo() allocates stream context array for streaminfo ->streamctxarray with xhciallocstreamctx(). When some error occurs, streaminfo->streamctxarray is not released, which will lead to a memory leak.

We can fix it by releasing the streaminfo->streamctxarray with xhcifreestreamctx() on the error path to avoid the potential memory leak.

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

dmaengine: ti: k3-udma: Reset UDMACHANRT byte counters to prevent overflow

UDMACHANRTBCNTREG stores the real-time channel bytecount statistics. These registers are 32-bit hardware counters and the driver uses these counters to monitor the operational progress status for a channel, when transferring more than 4GB of data it was observed that these counters overflow and completion calculation of a operation gets affected and the transfer hangs indefinitely.

This commit adds changes to decrease the byte count for every complete transaction so that these registers never overflow and the proper byte count statistics is maintained for ongoing transaction by the RT counters.

Earlier uc->bcnt used to maintain a count of the completed bytes at driver side, since the RT counters maintain the statistics of current transaction now, the maintenance of uc->bcnt is not necessary.

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

dmaengine: qcom-adm: fix wrong sizeof config in slaveconfig

Fix broken slaveconfig function that uncorrectly compare the peripheralsize with the size of the config pointer instead of the size of the config struct. This cause the crci value to be ignored and cause a kernel panic on any slave that use adm driver.

To fix this, compare to the size of the struct and NOT the size of the pointer.

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

bpf, arm64: Fixed a BTI error on returning to patched function

When BPFTRAMPFCALLORIG is set, BPF trampoline uses BLR to jump back to the instruction next to call site to call the patched function. For BTI-enabled kernel, the instruction next to call site is usually PACIASP, in this case, it's safe to jump back with BLR. But when the call site is not followed by a PACIASP or bti, a BTI exception is triggered.

Here is a fault log:

Unhandled 64-bit el1h sync exception on CPU0, ESR 0x0000000034000002 -- BTI CPU: 0 PID: 263 Comm: testprogs Tainted: GF Hardware name: linux,dummy-virt (DT) pstate: 40400805 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=-c) pc : bpffentrytest1+0xc/0x30 lr : bpftrampoline64425738920+0x48/0x1000 sp : ffff80000c0c3a50 x29: ffff80000c0c3a90 x28: ffff0000c2e6c080 x27: 0000000000000000 x26: 0000000000000000 x25: 0000000000000000 x24: 0000000000000050 x23: 0000000000000000 x22: 0000ffffcfd2a7f0 x21: 000000000000000a x20: 0000ffffcfd2a7f0 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000ffffcfd2a7f0 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000000 x10: ffff80000914f5e4 x9 : ffff8000082a1528 x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0101010101010101 x5 : 0000000000000000 x4 : 00000000fffffff2 x3 : 0000000000000001 x2 : ffff8001f4b82000 x1 : 0000000000000000 x0 : 0000000000000001 Kernel panic - not syncing: Unhandled exception CPU: 0 PID: 263 Comm: testprogs Tainted: GF Hardware name: linux,dummy-virt (DT) Call trace: dumpbacktrace+0xec/0x144 showstack+0x24/0x7c dumpstacklvl+0x8c/0xb8 dumpstack+0x18/0x34 panic+0x1cc/0x3ec el0errorhandlercommon+0x0/0x130 el1h64synchandler+0x60/0xd0 el1h64sync+0x78/0x7c bpffentrytest1+0xc/0x30 bpffentrytest1+0xc/0x30 bpfprogtestruntracing+0xdc/0x2a0 sysbpf+0x438/0x22a0 arm64sysbpf+0x30/0x54 invokesyscall+0x78/0x110 el0svccommon.constprop.0+0x6c/0x1d0 doel0svc+0x38/0xe0 el0svc+0x30/0xd0 el0t64synchandler+0x1ac/0x1b0 el0t64sync+0x1a0/0x1a4 Kernel Offset: disabled CPU features: 0x0000,00034c24,f994fdab Memory Limit: none

And the instruction next to call site of bpffentrytest1 is ADD, not PACIASP:

<bpffentrytest1>: bti c nop nop add w0, w0, #0x1 paciasp

For BPF prog, JIT always puts a PACIASP after call site for BTI-enabled kernel, so there is no problem. To fix it, replace BLR with RET to bypass the branch target check.

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

wifi: mac80211: mlme: fix null-ptr deref on failed assoc

If association to an AP without a link 0 fails, then we crash in tracing because it assumes that either apmldaddr or link 0 BSS is valid, since we clear sdata->vif.validlinks and then don't add the apmldaddr to the struct.

Since we clear also sdata->vif.cfg.apaddr, keep a local copy of it and assign it earlier, before clearing validlinks, to fix this.

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

nilfs2: replace WARNONs by nilfserror for checkpoint acquisition failure

If creation or finalization of a checkpoint fails due to anomalies in the checkpoint metadata on disk, a kernel warning is generated.

This patch replaces the WARNONs by nilfserror, so that a kernel, booted with paniconwarn, does not panic. A nilfserror is appropriate here to handle the abnormal filesystem condition.

This also replaces the detected error codes with an I/O error so that neither of the internal error codes is returned to callers.