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

posix-cpu-timers: fix race between handleposixcputimers() and posixcputimerdel()

If an exiting non-autoreaping task has already passed exitnotify() and calls handleposixcputimers() from IRQ, it can be reaped by its parent or debugger right after unlocktasksighand().

If a concurrent posixcputimerdel() runs at that moment, it won't be able to detect timer->it.cpu.firing != 0: cputimertaskrcu() and/or locktasksighand() will fail.

Add the tsk->exitstate check into runposixcputimers() to fix this.

This fix is not needed if CONFIGPOSIXCPUTIMERSTASKWORK=y, because exittaskwork() is called before exitnotify(). But the check still makes sense, taskworkadd(&tsk->posixcputimerswork.work) will fail anyway in this case.

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

perf/x86/intel: Fix crash in iclupdatetopdownevent()

The perffuzzer found a hard-lockup crash on a RaptorLake machine:

Oops: general protection fault, maybe for address 0xffff89aeceab400: 0000 CPU: 23 UID: 0 PID: 0 Comm: swapper/23 Tainted: [W]=WARN Hardware name: Dell Inc. Precision 9660/0VJ762 RIP: 0010:nativereadpmc+0x7/0x40 Code: cc e8 8d a9 01 00 48 89 03 5b cd cc cc cc cc 0f 1f ... RSP: 000:fffb03100273de8 EFLAGS: 00010046 .... Call Trace: <TASK> iclupdatetopdownevent+0x165/0x190 ? ktimeget+0x38/0xd0 intelpmureadevent+0xf9/0x210 perfeventread+0xf9/0x210

CPUs 16-23 are E-core CPUs that don't support the perf metrics feature. The iclupdatetopdownevent() should not be invoked on these CPUs.

It's a regression of commit:

f9bdf1f95339 ("perf/x86/intel: Avoid disable PMU if !cpuc->enabled in sample read")

The bug introduced by that commit is that the istopdownevent() function is mistakenly used to replace the istopdowncount() call to check if the topdown functions for the perf metrics feature should be invoked.

Fix it.

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

net: clear the dst when changing skb protocol

A not-so-careful NAT46 BPF program can crash the kernel if it indiscriminately flips ingress packets from v4 to v6:

BUG: kernel NULL pointer dereference, address: 0000000000000000 ip6rcvcore (net/ipv6/ip6input.c:190:20) ipv6rcv (net/ipv6/ip6input.c:306:8) processbacklog (net/core/dev.c:6186:4) napipoll (net/core/dev.c:6906:9) netrxaction (net/core/dev.c:7028:13) dosoftirq (kernel/softirq.c:462:3) netifrx (net/core/dev.c:5326:3) devloopbackxmit (net/core/dev.c:4015:2) ipmcfinishoutput (net/ipv4/ipoutput.c:363:8) NFHOOK (./include/linux/netfilter.h:314:9) ipmcoutput (net/ipv4/ipoutput.c:400:5) dstoutput (./include/net/dst.h:459:9) iplocalout (net/ipv4/ipoutput.c:130:9) ipsendskb (net/ipv4/ipoutput.c:1496:8) udpsendskb (net/ipv4/udp.c:1040:8) udpsendmsg (net/ipv4/udp.c:1328:10)

The output interface has a 4->6 program attached at ingress. We try to loop the multicast skb back to the sending socket. Ingress BPF runs as part of netifrx(), pushes a valid v6 hdr and changes skb->protocol to v6. We enter ip6rcvcore which tries to use skbdst(). But the dst is still an IPv4 one left after IPv4 mcast output.

Clear the dst in all BPF helpers which change the protocol. Try to preserve metadata dsts, those may carry non-routing metadata.

Bluetooth: MGMT: Fix UAF on mgmtremoveadvmonitorcomplete

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

smb: client: fix use-after-free in cifsoplockbreak

A race condition can occur in cifsoplockbreak() leading to a use-after-free of the cinode structure when unmounting:

cifsoplockbreak() cifsFileInfoput(cfile) cifsFileInfoputfinal() cifssbdeactive() [last ref, start releasing sb] killsb() killanonsuper() genericshutdownsuper() evictinodes() disposelist() evict() destroyinode() callrcu(&inode->ircu, icallback) spinlock(&cinode->openfilelock) <- OK [later] icallback() cifsfreeinode() kmemcachefree(cinode) spinunlock(&cinode->openfilelock) <- UAF cifsdoneoplockbreak(cinode) <- UAF

The issue occurs when umount has already released its reference to the superblock. When cifsFileInfoput() calls cifssbdeactive(), this releases the last reference, triggering the immediate cleanup of all inodes under RCU. However, cifsoplockbreak() continues to access the cinode after this point, resulting in use-after-free.

Fix this by holding an extra reference to the superblock during the entire oplock break operation. This ensures that the superblock and its inodes remain valid until the oplock break completes.

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

mptcp: make fallback action and fallback decision atomic

Syzkaller reported the following splat:

WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1223 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpdofallback net/mptcp/protocol.h:1244 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 checkfullyestablished net/mptcp/options.c:982 [inline] WARNING: CPU: 1 PID: 7704 at net/mptcp/protocol.h:1223 mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Modules linked in: CPU: 1 UID: 0 PID: 7704 Comm: syz.3.1419 Not tainted 6.16.0-rc3-gbd5ce2324dba #20 PREEMPT(voluntary) Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1223 [inline] RIP: 0010:mptcpdofallback net/mptcp/protocol.h:1244 [inline] RIP: 0010:checkfullyestablished net/mptcp/options.c:982 [inline] RIP: 0010:mptcpincomingoptions+0x21a8/0x2510 net/mptcp/options.c:1153 Code: 24 18 e8 bb 2a 00 fd e9 1b df ff ff e8 b1 21 0f 00 e8 ec 5f c4 fc 44 0f b7 ac 24 b0 00 00 00 e9 54 f1 ff ff e8 d9 5f c4 fc 90 <0f> 0b 90 e9 b8 f4 ff ff e8 8b 2a 00 fd e9 8d e6 ff ff e8 81 2a 00 RSP: 0018:ffff8880a3f08448 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff8880180a8000 RCX: ffffffff84afcf45 RDX: ffff888090223700 RSI: ffffffff84afdaa7 RDI: 0000000000000001 RBP: ffff888017955780 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff8880180a8910 R14: ffff8880a3e9d058 R15: 0000000000000000 FS: 00005555791b8500(0000) GS:ffff88811c495000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000110c2800b7 CR3: 0000000058e44000 CR4: 0000000000350ef0 Call Trace: <IRQ> tcpreset+0x26f/0x2b0 net/ipv4/tcpinput.c:4432 tcpvalidateincoming+0x1057/0x1b60 net/ipv4/tcpinput.c:5975 tcprcvestablished+0x5b5/0x21f0 net/ipv4/tcpinput.c:6166 tcpv4dorcv+0x5dc/0xa70 net/ipv4/tcpipv4.c:1925 tcpv4rcv+0x3473/0x44a0 net/ipv4/tcpipv4.c:2363 ipprotocoldeliverrcu+0xba/0x480 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x2f1/0x500 net/ipv4/ipinput.c:233 NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iplocaldeliver+0x1be/0x560 net/ipv4/ipinput.c:254 dstinput include/net/dst.h:469 [inline] iprcvfinish net/ipv4/ipinput.c:447 [inline] NFHOOK include/linux/netfilter.h:317 [inline] NFHOOK include/linux/netfilter.h:311 [inline] iprcv+0x514/0x810 net/ipv4/ipinput.c:567 netifreceiveskbonecore+0x197/0x1e0 net/core/dev.c:5975 netifreceiveskb+0x1f/0x120 net/core/dev.c:6088 processbacklog+0x301/0x1360 net/core/dev.c:6440 napipoll.constprop.0+0xba/0x550 net/core/dev.c:7453 napipoll net/core/dev.c:7517 [inline] netrxaction+0xb44/0x1010 net/core/dev.c:7644 handlesoftirqs+0x1d0/0x770 kernel/softirq.c:579 dosoftirq+0x3f/0x90 kernel/softirq.c:480 </IRQ> <TASK> localbhenableip+0xed/0x110 kernel/softirq.c:407 localbhenable include/linux/bottomhalf.h:33 [inline] inetcsklistenstop+0x2c5/0x1070 net/ipv4/inetconnectionsock.c:1524 mptcpchecklistenstop.part.0+0x1cc/0x220 net/mptcp/protocol.c:2985 mptcpchecklistenstop net/mptcp/mib.h:118 [inline] mptcpclose+0x9b9/0xbd0 net/mptcp/protocol.c:3000 mptcpclose+0x2f/0x140 net/mptcp/protocol.c:3066 inetrelease+0xed/0x200 net/ipv4/afinet.c:435 inet6release+0x4f/0x70 net/ipv6/afinet6.c:487 sockrelease+0xb3/0x270 net/socket.c:649 sockclose+0x1c/0x30 net/socket.c:1439 fput+0x402/0xb70 fs/filetable.c:465 taskworkrun+0x150/0x240 kernel/taskwork.c:227 resumeusermodework include/linux/resumeusermode.h:50 [inline] exittousermodeloop+0xd4 ---truncated---

iio: accel: fxls8962af: Fix use after free in fxls8962affifoflush

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

rxrpc: Fix recv-recv race of completed call

If a call receives an event (such as incoming data), the call gets placed on the socket's queue and a thread in recvmsg can be awakened to go and process it. Once the thread has picked up the call off of the queue, further events will cause it to be requeued, and once the socket lock is dropped (recvmsg uses call->usermutex to allow the socket to be used in parallel), a second thread can come in and its recvmsg can pop the call off the socket queue again.

In such a case, the first thread will be receiving stuff from the call and the second thread will be blocked on call->usermutex. The first thread can, at this point, process both the event that it picked call for and the event that the second thread picked the call for and may see the call terminate - in which case the call will be "released", decoupling the call from the user call ID assigned to it (RXRPCUSERCALLID in the control message).

The first thread will return okay, but then the second thread will wake up holding the usermutex and, if it sees that the call has been released by the first thread, it will BUG thusly:

kernel BUG at net/rxrpc/recvmsg.c:474!

Fix this by just dequeuing the call and ignoring it if it is seen to be already released. We can't tell userspace about it anyway as the user call ID has become stale.

Bluetooth: MGMT: Protect mgmtpending list with its own lock

atm: clip: Fix infinite recursive call of clippush().

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

rxrpc: Fix irq-disabled in localbhenable()

The rxrpcassessMTUsize() function calls down into the IP layer to find out the MTU size for a route. When accepting an incoming call, this is called from rxrpcnewincomingcall() which holds interrupts disabled across the code that calls down to it. Unfortunately, the IP layer uses localbhenable() which, config dependent, throws a warning if IRQs are enabled:

WARNING: CPU: 1 PID: 5544 at kernel/softirq.c:387 localbhenableip+0x43/0xd0 ... RIP: 0010:localbhenableip+0x43/0xd0 ... Call Trace: <TASK> rtcacheroute+0x7e/0xa0 rtsetnexthop.isra.0+0x3b3/0x3f0 mkrouteoutput+0x43a/0x460 iprouteoutputkeyhash+0xf7/0x140 iprouteoutputflow+0x1b/0x90 rxrpcassessMTUsize.isra.0+0x2a0/0x590 rxrpcnewincomingpeer+0x46/0x120 rxrpcallocincomingcall+0x1b1/0x400 rxrpcnewincomingcall+0x1da/0x5e0 rxrpcinputpacket+0x827/0x900 rxrpciothread+0x403/0xb60 kthread+0x2f7/0x310 retfromfork+0x2a/0x230 retfromforkasm+0x1a/0x30 ... hardirqs last enabled at (23): rawspinunlockirq+0x24/0x50 hardirqs last disabled at (24): rawreadlockirq+0x17/0x70 softirqs last enabled at (0): copyprocess+0xc61/0x2730 softirqs last disabled at (25): rtadduncachedlist+0x3c/0x90

Fix this by moving the call to rxrpcassessMTUsize() out of rxrpcinitpeer() and further up the stack where it can be done without interrupts disabled.

It shouldn't be a problem for rxrpcnewincomingcall() to do it after the locks are dropped as pmtud is going to be performed by the I/O thread - and we're in the I/O thread at this point.

drm/gem: Acquire references on GEM handles for framebuffers

Bluetooth: hcicore: Fix use-after-free in vhciflush()

drm/amdkfd: Don't call mmput from MMU notifier callback

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

s390/ism: fix concurrency management in ismcmd()

The s390x ISM device data sheet clearly states that only one request-response sequence is allowable per ISM function at any point in time. Unfortunately as of today the s390/ism driver in Linux does not honor that requirement. This patch aims to rectify that.

This problem was discovered based on Aliaksei's bug report which states that for certain workloads the ISM functions end up entering error state (with PEC 2 as seen from the logs) after a while and as a consequence connections handled by the respective function break, and for future connection requests the ISM device is not considered -- given it is in a dysfunctional state. During further debugging PEC 3A was observed as well.

A kernel message like [ 1211.244319] zpci: 061a:00:00.0: Event 0x2 reports an error for PCI function 0x61a is a reliable indicator of the stated function entering error state with PEC 2. Let me also point out that a kernel message like [ 1211.244325] zpci: 061a:00:00.0: The ism driver bound to the device does not support error recovery is a reliable indicator that the ISM function won't be auto-recovered because the ISM driver currently lacks support for it.

On a technical level, without this synchronization, commands (inputs to the FW) may be partially or fully overwritten (corrupted) by another CPU trying to issue commands on the same function. There is hard evidence that this can lead to DMB token values being used as DMB IOVAs, leading to PEC 2 PCI events indicating invalid DMA. But this is only one of the failure modes imaginable. In theory even completely losing one command and executing another one twice and then trying to interpret the outputs as if the command we intended to execute was actually executed and not the other one is also possible. Frankly, I don't feel confident about providing an exhaustive list of possible consequences.

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

xfrm: state: initialize stateptrs earlier in xfrmstatefind

In case of preemption, xfrmstatelookat will find a different pcpuid and look up states for that other CPU. If we matched a state for CPU2 in the statecache while the lookup started on CPU1, we will jump to "found", but the "best" state that we got will be ignored and we will enter the "acquire" block. This block uses stateptrs, which isn't initialized at this point.

Let's initialize stateptrs just after taking rcureadlock. This will also prevent a possible misuse in the future, if someone adjusts this function.

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

arm64/entry: Mask DAIF in cpuswitchto(), callonirqstack()

cpuswitchto() and callonirqstack() manipulate SP to change to different stacks along with the Shadow Call Stack if it is enabled. Those two stack changes cannot be done atomically and both functions can be interrupted by SErrors or Debug Exceptions which, though unlikely, is very much broken : if interrupted, we can end up with mismatched stacks and Shadow Call Stack leading to clobbered stacks.

In cpuswitchto(), it can happen when SPEL0 points to the new task, but x18 stills points to the old task's SCS. When the interrupt handler tries to save the task's SCS pointer, it will save the old task SCS pointer (x18) into the new task struct (pointed to by SPEL0), clobbering it.

In callonirqstack(), it can happen when switching from the task stack to the IRQ stack and when switching back. In both cases, we can be interrupted when the SCS pointer points to the IRQ SCS, but SP points to the task stack. The nested interrupt handler pushes its return addresses on the IRQ SCS. It then detects that SP points to the task stack, calls callonirqstack() and clobbers the task SCS pointer with the IRQ SCS pointer, which it will also use !

This leads to tasks returning to addresses on the wrong SCS, or even on the IRQ SCS, triggering kernel panics via CONFIGVMAPSTACK or FPAC if enabled.

This is possible on a default config, but unlikely. However, when enabling CONFIGARM64PSEUDONMI, DAIF is unmasked and instead the GIC is responsible for filtering what interrupts the CPU should receive based on priority. Given the goal of emulating NMIs, pseudo-NMIs can be received by the CPU even in cpuswitchto() and callonirqstack(), possibly very frequently depending on the system configuration and workload, leading to unpredictable kernel panics.

Completely mask DAIF in cpuswitchto() and restore it when returning. Do the same in callonirqstack(), but restore and mask around the branch. Mask DAIF even if CONFIGSHADOWCALLSTACK is not enabled for consistency of behaviour between all configurations.

Introduce and use an assembly macro for saving and masking DAIF, as the existing one saves but only masks IF.

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

iio: fix potential out-of-bound write

The buffer is set to 20 characters. If a caller write more characters, count is truncated to the max available space in "simplewritetobuffer". To protect from OoB access, check that the input size fit into buffer and add a zero terminator after copy to the end of the copied data.

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

ASoC: mediatek: mt8365-dai-i2s: pass correct size to mt8365daisetpriv

Given mt8365daisetpriv allocate privsize space to copy privdata which means we should pass mt8365i2spriv[i] or "struct mtkafei2spriv" instead of afepriv which has the size of "struct mt8365afeprivate".

Otherwise the KASAN complains about.

[ 59.389765] BUG: KASAN: global-out-of-bounds in mt8365daisetpriv+0xc8/0x168 [sndsocmt8365pcm] ... [ 59.394789] Call trace: [ 59.395167] dumpbacktrace+0xa0/0x128 [ 59.395733] showstack+0x20/0x38 [ 59.396238] dumpstacklvl+0xe8/0x148 [ 59.396806] printreport+0x37c/0x5e0 [ 59.397358] kasanreport+0xac/0xf8 [ 59.397885] kasancheckrange+0xe8/0x190 [ 59.398485] asanmemcpy+0x3c/0x98 [ 59.399022] mt8365daisetpriv+0xc8/0x168 [sndsocmt8365pcm] [ 59.399928] mt8365daii2sregister+0x1e8/0x2b0 [sndsocmt8365pcm] [ 59.400893] mt8365afepcmdevprobe+0x4d0/0xdf0 [sndsocmt8365pcm] [ 59.401873] platformprobe+0xcc/0x228 [ 59.402442] reallyprobe+0x340/0x9e8 [ 59.402992] driverprobedevice+0x16c/0x3f8 [ 59.403638] driverprobedevice+0x64/0x1d8 [ 59.404256] driverattach+0x1dc/0x4c8 [ 59.404840] busforeachdev+0x100/0x190 [ 59.405442] driverattach+0x44/0x68 [ 59.405980] busadddriver+0x23c/0x500 [ 59.406550] driverregister+0xf8/0x3d0 [ 59.407122] platformdriverregister+0x68/0x98 [ 59.407810] mt8365afepcmdriverinit+0x2c/0xff8 [sndsocmt8365pcm]

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

platform/x86: alienware-wmi-wmax: Fix dmisystemid array

Add missing empty member to awccdmitable.

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

mptcp: plug races between subflow fail and subflow creation

We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger.

The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock.

The socket fallback makes such flag true, and also receiving or sending an MPFAIL option.

The field 'allowinfinitefallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write.

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

ipv6: mcast: Delay put pmc->idev in mlddeldelrec()

pmc->idev is still used in ip6mcclearsrc(), so as mldcleardelrec() does, the reference should be put after ip6mcclearsrc() return.

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

iio: adc: axp20xadc: Add missing sentinel to AXP717 ADC channel maps

The AXP717 ADC channel maps is missing a sentinel entry at the end. This causes a KASAN warning.

Add the missing sentinel entry.

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

net: ethernet: ti: am65-cpsw-nuss: Fix skb size by accounting for skbsharedinfo

While transitioning from netdevallocipalign() to buildskb(), memory for the "skbsharedinfo" member of an "skb" was not allocated. Fix this by allocating "PAGESIZE" as the skb length, accounting for the packet length, headroom and tailroom, thereby including the required memory space for skbsharedinfo.

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

net: appletalk: Fix device refcount leak in atrtrcreate()

When updating an existing route entry in atrtrcreate(), the old device reference was not being released before assigning the new device, leading to a device refcount leak. Fix this by calling devput() to release the old device reference before holding the new one.

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

tracing: Add downwrite(traceeventsem) when adding trace event

When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values.

If two modules are loaded at the same time, the adding of the event to the ftraceevents list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel.

The addition of the event should take the traceeventsem for write while it adds the new event.

Also add a lockdepassertheld() on that semaphore in traceaddeventdirs() as it iterates the list.

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

net: airoha: fix potential use-after-free in airohanpuget()

np->name was being used after calling ofnodeput(np), which releases the node and can lead to a use-after-free bug. Previously, ofnodeput(np) was called unconditionally after offinddevicebynode(np), which could result in a use-after-free if pdev is NULL.

This patch moves ofnodeput(np) after the error check to ensure the node is only released after both the error and success cases are handled appropriately, preventing potential resource issues.

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

net: libwx: fix the using of Rx buffer DMA

The wxrxbuffer structure contained two DMA address fields: 'dma' and 'pagedma'. However, only 'pagedma' was actually initialized and used to program the Rx descriptor. But 'dma' was uninitialized and used in some paths.

This could lead to undefined behavior, including DMA errors or use-after-free, if the uninitialized 'dma' was used. Althrough such error has not yet occurred, it is worth fixing in the code.

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

net: libwx: properly reset Rx ring descriptor

When device reset is triggered by feature changes such as toggling Rx VLAN offload, wx->doreset() is called to reinitialize Rx rings. The hardware descriptor ring may retain stale values from previous sessions. And only set the length to 0 in rxdesc[0] would result in building malformed SKBs. Fix it to ensure a clean slate after device reset.

[ 549.186435] [ C16] ------------[ cut here ]------------ [ 549.186457] [ C16] kernel BUG at net/core/skbuff.c:2814! [ 549.186468] [ C16] Oops: invalid opcode: 0000 [#1] SMP NOPTI [ 549.186472] [ C16] CPU: 16 UID: 0 PID: 0 Comm: swapper/16 Kdump: loaded Not tainted 6.16.0-rc4+ #23 PREEMPT(voluntary) [ 549.186476] [ C16] Hardware name: Micro-Star International Co., Ltd. MS-7E16/X670E GAMING PLUS WIFI (MS-7E16), BIOS 1.90 12/31/2024 [ 549.186478] [ C16] RIP: 0010:pskbpulltail+0x3ff/0x510 [ 549.186484] [ C16] Code: 06 f0 ff 4f 34 74 7b 4d 8b 8c 24 c8 00 00 00 45 8b 84 24 c0 00 00 00 e9 c8 fd ff ff 48 c7 44 24 08 00 00 00 00 e9 5e fe ff ff <0f> 0b 31 c0 e9 23 90 5b ff 41 f7 c6 ff 0f 00 00 75 bf 49 8b 06 a8 [ 549.186487] [ C16] RSP: 0018:ffffb391c0640d70 EFLAGS: 00010282 [ 549.186490] [ C16] RAX: 00000000fffffff2 RBX: ffff8fe7e4d40200 RCX: 00000000fffffff2 [ 549.186492] [ C16] RDX: ffff8fe7c3a4bf8e RSI: 0000000000000180 RDI: ffff8fe7c3a4bf40 [ 549.186494] [ C16] RBP: ffffb391c0640da8 R08: ffff8fe7c3a4c0c0 R09: 000000000000000e [ 549.186496] [ C16] R10: ffffb391c0640d88 R11: 000000000000000e R12: ffff8fe7e4d40200 [ 549.186497] [ C16] R13: 00000000fffffff2 R14: ffff8fe7fa01a000 R15: 00000000fffffff2 [ 549.186499] [ C16] FS: 0000000000000000(0000) GS:ffff8fef5ae40000(0000) knlGS:0000000000000000 [ 549.186502] [ C16] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 549.186503] [ C16] CR2: 00007f77d81d6000 CR3: 000000051a032000 CR4: 0000000000750ef0 [ 549.186505] [ C16] PKRU: 55555554 [ 549.186507] [ C16] Call Trace: [ 549.186510] [ C16] <IRQ> [ 549.186513] [ C16] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 549.186517] [ C16] skbpad+0xc7/0xf0 [ 549.186523] [ C16] wxcleanrxirq+0x355/0x3b0 [libwx] [ 549.186533] [ C16] wxpoll+0x92/0x120 [libwx] [ 549.186540] [ C16] napipoll+0x28/0x190 [ 549.186544] [ C16] netrxaction+0x301/0x3f0 [ 549.186548] [ C16] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 549.186551] [ C16] ? rawspinlockirqsave+0x1e/0x50 [ 549.186554] [ C16] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 549.186557] [ C16] ? wakeupnohzcpu+0x35/0x160 [ 549.186559] [ C16] ? srsoaliasreturnthunk+0x5/0xfbef5 [ 549.186563] [ C16] handlesoftirqs+0xf9/0x2c0 [ 549.186568] [ C16] irqexitrcu+0xc7/0x130 [ 549.186572] [ C16] commoninterrupt+0xb8/0xd0 [ 549.186576] [ C16] </IRQ> [ 549.186577] [ C16] <TASK> [ 549.186579] [ C16] asmcommoninterrupt+0x22/0x40 [ 549.186582] [ C16] RIP: 0010:cpuidleenterstate+0xc2/0x420 [ 549.186585] [ C16] Code: 00 00 e8 11 0e 5e ff e8 ac f0 ff ff 49 89 c5 0f 1f 44 00 00 31 ff e8 0d ed 5c ff 45 84 ff 0f 85 40 02 00 00 fb 0f 1f 44 00 00 <45> 85 f6 0f 88 84 01 00 00 49 63 d6 48 8d 04 52 48 8d 04 82 49 8d [ 549.186587] [ C16] RSP: 0018:ffffb391c0277e78 EFLAGS: 00000246 [ 549.186590] [ C16] RAX: ffff8fef5ae40000 RBX: 0000000000000003 RCX: 0000000000000000 [ 549.186591] [ C16] RDX: 0000007fde0faac5 RSI: ffffffff826e53f6 RDI: ffffffff826fa9b3 [ 549.186593] [ C16] RBP: ffff8fe7c3a20800 R08: 0000000000000002 R09: 0000000000000000 [ 549.186595] [ C16] R10: 0000000000000000 R11: 000000000000ffff R12: ffffffff82ed7a40 [ 549.186596] [ C16] R13: 0000007fde0faac5 R14: 0000000000000003 R15: 0000000000000000 [ 549.186601] [ C16] ? cpuidleenterstate+0xb3/0x420 [ 549.186605] [ C16] cpuidleen ---truncated---

bpf: Reject %p% format string in bprintf-like helpers