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

net: fix data-races around sk->skforwardalloc

Syzkaller reported this warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 16 at net/ipv4/afinet.c:156 inetsockdestruct+0x1c5/0x1e0 Modules linked in: CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc5 #26 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:inetsockdestruct+0x1c5/0x1e0 Code: 24 12 4c 89 e2 5b 48 c7 c7 98 ec bb 82 41 5c e9 d1 18 17 ff 4c 89 e6 5b 48 c7 c7 d0 ec bb 82 41 5c e9 bf 18 17 ff 0f 0b eb 83 <0f> 0b eb 97 0f 0b eb 87 0f 0b e9 68 ff ff ff 66 66 2e 0f 1f 84 00 RSP: 0018:ffffc9000008bd90 EFLAGS: 00010206 RAX: 0000000000000300 RBX: ffff88810b172a90 RCX: 0000000000000007 RDX: 0000000000000002 RSI: 0000000000000300 RDI: ffff88810b172a00 RBP: ffff88810b172a00 R08: ffff888104273c00 R09: 0000000000100007 R10: 0000000000020000 R11: 0000000000000006 R12: ffff88810b172a00 R13: 0000000000000004 R14: 0000000000000000 R15: ffff888237c31f78 FS: 0000000000000000(0000) GS:ffff888237c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffc63fecac8 CR3: 000000000342e000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? warn+0x88/0x130 ? inetsockdestruct+0x1c5/0x1e0 ? reportbug+0x18e/0x1a0 ? handlebug+0x53/0x90 ? excinvalidop+0x18/0x70 ? asmexcinvalidop+0x1a/0x20 ? inetsockdestruct+0x1c5/0x1e0 skdestruct+0x2a/0x200 rcudobatch+0x1aa/0x530 ? rcudobatch+0x13b/0x530 rcucore+0x159/0x2f0 handlesoftirqs+0xd3/0x2b0 ? pfxsmpbootthreadfn+0x10/0x10 runksoftirqd+0x25/0x30 smpbootthreadfn+0xdd/0x1d0 kthread+0xd3/0x100 ? pfxkthread+0x10/0x10 retfromfork+0x34/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK> ---[ end trace 0000000000000000 ]---

Its possible that two threads call tcpv6dorcv()/skforwardallocadd() concurrently when sk->skstate == TCPLISTEN with sk->sklock unlocked, which triggers a data-race around sk->skforwardalloc: tcpv6rcv tcpv6dorcv skbcloneandcharger skrmemschedule skmemschedule skforwardallocadd() skbsetownerr skmemcharge skforwardallocadd() kfreeskb skbreleaseall skbreleaseheadstate sockrfree skmemuncharge skforwardallocadd() skmemreclaim // set local var reclaimable skmemreclaim skforwardallocadd()

In this syzkaller testcase, two threads call tcpv6dorcv() with skb->truesize=768, the skforwardalloc changes like this: (cpu 1) | (cpu 2) | skforwardalloc ... | ... | 0 skmemschedule() | | +4096 = 4096 | skmemschedule() | +4096 = 8192 skmemcharge() | | -768 = 7424 | skmemcharge() | -768 = 6656 ... | ... | skmemuncharge() | | +768 = 7424 reclaimable=7424 | | | skmemuncharge() | +768 = 8192 | reclaimable=8192 | skmemreclaim() | | -4096 = 4096 | skmemreclaim() | -8192 = -4096 != 0

The skbcloneandcharger() should not be called in tcpv6dorcv() when sk->skstate is TCPLISTEN, it happens later in tcpv6synrecvsock(). Fix the same issue in dccpv6dorcv().

bpf: Fix overloading of MEMUNINIT's meaning

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

Bluetooth: SCO: Fix UAF on scosocktimeout

conn->sk maybe have been unlinked/freed while waiting for scoconnlock so this checks if the conn->sk is still valid by checking if it part of scosklist.

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

tracing: Consider the NULL character when validating the event length

strlen() returns a string length excluding the null byte. If the string length equals to the maximum buffer length, the buffer will have no space for the NULL terminating character.

This commit checks this condition and returns failure for it.

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

ksmbd: check outstanding simultaneous SMB operations

If Client send simultaneous SMB operations to ksmbd, It exhausts too much memory through the "ksmbdworkcache”. It will cause OOM issue. ksmbd has a credit mechanism but it can't handle this problem. This patch add the check if it exceeds max credits to prevent this problem by assuming that one smb request consumes at least one credit.

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

sctp: properly validate chunk size in sctpsfootb()

A size validation fix similar to that in Commit 50619dbf8db7 ("sctp: add size validation when walking chunks") is also required in sctpsfootb() to address a crash reported by syzbot:

BUG: KMSAN: uninit-value in sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpsfootb+0x7f5/0xce0 net/sctp/smstatefuns.c:3712 sctpdosm+0x181/0x93d0 net/sctp/smsideeffect.c:1166 sctpendpointbhrcv+0xc38/0xf90 net/sctp/endpointola.c:407 sctpinqpush+0x2ef/0x380 net/sctp/inqueue.c:88 sctprcv+0x3831/0x3b20 net/sctp/input.c:243 sctp4rcv+0x42/0x50 net/sctp/protocol.c:1159 ipprotocoldeliverrcu+0xb51/0x13d0 net/ipv4/ipinput.c:205 iplocaldeliverfinish+0x336/0x500 net/ipv4/ipinput.c:233

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

x86/entry32: Clear CPU buffers after register restore in NMI return

CPU buffers are currently cleared after call to excnmi, but before register state is restored. This may be okay for MDS mitigation but not for RDFS. Because RDFS mitigation requires CPU buffers to be cleared when registers don't have any sensitive data.

Move CLEARCPUBUFFERS after RESTOREALLNMI.

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

smb: client: fix OOBs when building SMB2IOCTL request

When using encryption, either enforced by the server or when using 'seal' mount option, the client will squash all compound request buffers down for encryption into a single iov in smb2setnextcommand().

SMB2ioctlinit() allocates a small buffer (448 bytes) to hold the SMB2IOCTL request in the first iov, and if the user passes an input buffer that is greater than 328 bytes, smb2setnextcommand() will end up writing off the end of @rqst->iov[0].iovbase as shown below:

mount.cifs //srv/share /mnt -o ...,seal ln -s $(perl -e "print('a')for 1..1024") /mnt/link

BUG: KASAN: slab-out-of-bounds in smb2setnextcommand.cold+0x1d6/0x24c [cifs] Write of size 4116 at addr ffff8881148fcab8 by task ln/859

CPU: 1 UID: 0 PID: 859 Comm: ln Not tainted 6.12.0-rc3 #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-2.fc40 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x5d/0x80 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] printreport+0x156/0x4d9 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] ? virtaddrvalid+0x145/0x310 ? physaddr+0x46/0x90 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] kasanreport+0xda/0x110 ? smb2setnextcommand.cold+0x1d6/0x24c [cifs] kasancheckrange+0x10f/0x1f0 asanmemcpy+0x3c/0x60 smb2setnextcommand.cold+0x1d6/0x24c [cifs] smb2compoundop+0x238c/0x3840 [cifs] ? kasansavetrack+0x14/0x30 ? kasansavefreeinfo+0x3b/0x70 ? vfssymlink+0x1a1/0x2c0 ? dosymlinkat+0x108/0x1c0 ? pfxsmb2compoundop+0x10/0x10 [cifs] ? kmemcachefree+0x118/0x3e0 ? cifsgetwritablepath+0xeb/0x1a0 [cifs] smb2getreparseinode+0x423/0x540 [cifs] ? pfxsmb2getreparseinode+0x10/0x10 [cifs] ? rcuiswatching+0x20/0x50 ? kmallocnoprof+0x37c/0x480 ? smb2createreparsesymlink+0x257/0x490 [cifs] ? smb2createreparsesymlink+0x38f/0x490 [cifs] smb2createreparsesymlink+0x38f/0x490 [cifs] ? pfxsmb2createreparsesymlink+0x10/0x10 [cifs] ? findheldlock+0x8a/0xa0 ? hlockclass+0x32/0xb0 ? buildpathfromdentryoptionalprefix+0x19d/0x2e0 [cifs] cifssymlink+0x24f/0x960 [cifs] ? pfxmakevfsuid+0x10/0x10 ? pfxcifssymlink+0x10/0x10 [cifs] ? makevfsgid+0x6b/0xc0 ? genericpermission+0x96/0x2d0 vfssymlink+0x1a1/0x2c0 dosymlinkat+0x108/0x1c0 ? pfxdosymlinkat+0x10/0x10 ? strncpyfromuser+0xaa/0x160 x64syssymlinkat+0xb9/0xf0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7f08d75c13bb

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

wifi: iwlegacy: Clear stale interrupts before resuming device

iwl4965 fails upon resume from hibernation on my laptop. The reason seems to be a stale interrupt which isn't being cleared out before interrupts are enabled. We end up with a race beween the resume trying to bring things back up, and the restart work (queued form the interrupt handler) trying to bring things down. Eventually the whole thing blows up.

Fix the problem by clearing out any stale interrupts before interrupts get enabled during resume.

Here's a debug log of the indicent: [ 12.042589] ieee80211 phy0: ilisr ISR inta 0x00000080, enabled 0xaa00008b, fh 0x00000000 [ 12.042625] ieee80211 phy0: il4965irqtasklet inta 0x00000080, enabled 0x00000000, fh 0x00000000 [ 12.042651] iwl4965 0000:10:00.0: RFKILL bit toggled to enable radio. [ 12.042653] iwl4965 0000:10:00.0: On demand firmware reload [ 12.042690] ieee80211 phy0: il4965irqtasklet End inta 0x00000000, enabled 0xaa00008b, fh 0x00000000, flags 0x00000282 [ 12.052207] ieee80211 phy0: il4965macstart enter [ 12.052212] ieee80211 phy0: ilprepstation Add STA to driver ID 31: ff:ff:ff:ff:ff:ff [ 12.052244] ieee80211 phy0: il4965sethwready hardware ready [ 12.052324] ieee80211 phy0: ilapminit Init card's basic functions [ 12.052348] ieee80211 phy0: ilapminit L1 Enabled; Disabling L0S [ 12.055727] ieee80211 phy0: il4965loadbsm Begin load bsm [ 12.056140] ieee80211 phy0: il4965verifybsm Begin verify bsm [ 12.058642] ieee80211 phy0: il4965verifybsm BSM bootstrap uCode image OK [ 12.058721] ieee80211 phy0: il4965loadbsm BSM write complete, poll 1 iterations [ 12.058734] ieee80211 phy0: il4965up iwl4965 is coming up [ 12.058737] ieee80211 phy0: il4965macstart Start UP work done. [ 12.058757] ieee80211 phy0: il4965down iwl4965 is going down [ 12.058761] ieee80211 phy0: ilscancanceltimeout Scan cancel timeout [ 12.058762] ieee80211 phy0: ildoscanabort Not performing scan to abort [ 12.058765] ieee80211 phy0: ilclearucodestations Clearing ucode stations in driver [ 12.058767] ieee80211 phy0: ilclearucodestations No active stations found to be cleared [ 12.058819] ieee80211 phy0: ilapmstop Stop card, put in low power state [ 12.058827] ieee80211 phy0: ilapmstopmaster stop master [ 12.058864] ieee80211 phy0: il4965clearfreeframes 0 frames on pre-allocated heap on clear. [ 12.058869] ieee80211 phy0: Hardware restart was requested [ 16.132299] iwl4965 0000:10:00.0: STARTALIVE timeout after 4000ms. [ 16.132303] ------------[ cut here ]------------ [ 16.132304] Hardware became unavailable upon resume. This could be a software issue prior to suspend or a hardware issue. [ 16.132338] WARNING: CPU: 0 PID: 181 at net/mac80211/util.c:1826 ieee80211reconfig+0x8f/0x14b0 [mac80211] [ 16.132390] Modules linked in: ctr ccm schfqcodel xttcpudp xtmultiport xtstate iptablefilter iptablenat nfnat nfconntrack nfdefragipv4 iptables xtables binfmtmisc joydev mousedev btusb btrtl btintel btbcm bluetooth ecdhgeneric ecc iTCOwdt i2cdev iwl4965 iwlegacy coretemp sndhdacodecanalog pcspkr psmouse mac80211 sndhdacodecgeneric libarc4 sdhcipci cqhci sha256generic sdhci libsha256 firewireohci sndhdaintel sndinteldspcfg mmccore sndhdacodec sndhwdep firewirecore ledclass iosfmbi sndhdacore uhcihcd lpcich crcitut cfg80211 ehcipci ehcihcd sndpcm usbcore mfdcore rfkill sndtimer snd usbcommon soundcore video parportpc parport intelagp wmi intelgtt backlight e1000e agpgart evdev [ 16.132456] CPU: 0 UID: 0 PID: 181 Comm: kworker/u8:6 Not tainted 6.11.0-cl+ #143 [ 16.132460] Hardware name: Hewlett-Packard HP Compaq 6910p/30BE, BIOS 68MCU Ver. F.19 07/06/2010 [ 16.132463] Workqueue: async asyncrunentryfn [ 16.132469] RIP: 0010:ieee80211reconfig+0x8f/0x14b0 [mac80211] [ 16.132501] Code: da 02 00 0 ---truncated---

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

ksmbd: Fix the missing xastore error check

xastore() can fail, it return xaerr(-EINVAL) if the entry cannot be stored in an XArray, or xaerr(-ENOMEM) if memory allocation failed, so check error for xastore() to fix it.

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

usb: typec: fix potential out of bounds in ucsiccgupdatesetnewcamcmd()

The "cmd" variable can be controlled by the user via debugfs. That means "newcam" can be as high as 255 while the size of the uc->updated[] array is UCSIMAXALTMODES (30).

The call tree is: ucsicmd() // val comes from simpleattrwritexsigned() -> ucsisendcommand() -> ucsisendcommandcommon() -> ucsiruncommand() // calls ucsi->ops->synccontrol() -> ucsiccgsynccontrol()

bpf: Fix out-of-bounds write in triegetnextkey()

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

vsock/virtio: Initialization of the dangling pointer occurring in vsk->trans

During loopback communication, a dangling pointer can be created in vsk->trans, potentially leading to a Use-After-Free condition. This issue is resolved by initializing vsk->trans to NULL.

drm/amdgpu: add missing size check in amdgpudebugfsgprwaveread()

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

nilfs2: fix kernel bug due to missing clearing of checked flag

Syzbot reported that in directory operations after nilfs2 detects filesystem corruption and degrades to read-only, blockwritebeginint(), which is called to prepare block writes, may fail the BUGON check for accesses exceeding the folio/page size, triggering a kernel bug.

This was found to be because the "checked" flag of a page/folio was not cleared when it was discarded by nilfs2's own routine, which causes the sanity check of directory entries to be skipped when the directory page/folio is reloaded. So, fix that.

This was necessary when the use of nilfs2's own page discard routine was applied to more than just metadata files.

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

wifi: iwlwifi: mvm: Fix response handling in iwlmvmsendrecoverycmd()

1. The size of the response packet is not validated. 2. The response buffer is not freed.

Resolve these issues by switching to iwlmvmsendcmdstatus(), which handles both size validation and frees the buffer.

dm cache: fix potential out-of-bounds access on the first resume

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

security/keys: fix slab-out-of-bounds in keytaskpermission

KASAN reports an out of bounds read: BUG: KASAN: slab-out-of-bounds in kuidval include/linux/uidgid.h:36 BUG: KASAN: slab-out-of-bounds in uideq include/linux/uidgid.h:63 [inline] BUG: KASAN: slab-out-of-bounds in keytaskpermission+0x394/0x410 security/keys/permission.c:54 Read of size 4 at addr ffff88813c3ab618 by task stress-ng/4362

CPU: 2 PID: 4362 Comm: stress-ng Not tainted 5.10.0-14930-gafbffd6c3ede #15 Call Trace: dumpstack lib/dumpstack.c:82 [inline] dumpstack+0x107/0x167 lib/dumpstack.c:123 printaddressdescription.constprop.0+0x19/0x170 mm/kasan/report.c:400 kasanreport.cold+0x6c/0x84 mm/kasan/report.c:560 kasanreport+0x3a/0x50 mm/kasan/report.c:585 kuidval include/linux/uidgid.h:36 [inline] uideq include/linux/uidgid.h:63 [inline] keytaskpermission+0x394/0x410 security/keys/permission.c:54 searchnestedkeyrings+0x90e/0xe90 security/keys/keyring.c:793

This issue was also reported by syzbot.

It can be reproduced by following these steps(more details [1]): 1. Obtain more than 32 inputs that have similar hashes, which ends with the pattern '0xxxxxxxe6'. 2. Reboot and add the keys obtained in step 1.

The reproducer demonstrates how this issue happened: 1. In the searchnestedkeyrings function, when it iterates through the slots in a node(below tag ascendtonode), if the slot pointer is meta and node->backpointer != NULL(it means a root), it will proceed to descendtonode. However, there is an exception. If node is the root, and one of the slots points to a shortcut, it will be treated as a keyring. 2. Whether the ptr is keyring decided by keyringptriskeyring function. However, KEYRINGPTRSUBTYPE is 0x2UL, the same as ASSOCARRAYPTRSUBTYPEMASK. 3. When 32 keys with the similar hashes are added to the tree, the ROOT has keys with hashes that are not similar (e.g. slot 0) and it splits NODE A without using a shortcut. When NODE A is filled with keys that all hashes are xxe6, the keys are similar, NODE A will split with a shortcut. Finally, it forms the tree as shown below, where slot 6 points to a shortcut.

NODE A +------>+---+ ROOT | | 0 | xxe6 +---+ | +---+ xxxx | 0 | shortcut : : xxe6 +---+ | +---+ xxe6 : : | | | xxe6 +---+ | +---+ | 6 |---+ : : xxe6 +---+ +---+ xxe6 : : | f | xxe6 +---+ +---+ xxe6 | f | +---+

4. As mentioned above, If a slot(slot 6) of the root points to a shortcut, it may be mistakenly transferred to a key, leading to a read out-of-bounds read.

To fix this issue, one should jump to descendtonode if the ptr is a shortcut, regardless of whether the node is root or not.

[1] https://lore.kernel.org/linux-kernel/1cfa878e-8c7b-4570-8606-21daf5e13ce7@huaweicloud.com/

[jarkko: tweaked the commit message a bit to have an appropriate closes tag.]

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

mm: resolve faulty mmapregion() error path behaviour

The mmapregion() function is somewhat terrifying, with spaghetti-like control flow and numerous means by which issues can arise and incomplete state, memory leaks and other unpleasantness can occur.

A large amount of the complexity arises from trying to handle errors late in the process of mapping a VMA, which forms the basis of recently observed issues with resource leaks and observable inconsistent state.

Taking advantage of previous patches in this series we move a number of checks earlier in the code, simplifying things by moving the core of the logic into a static internal function mmapregion().

Doing this allows us to perform a number of checks up front before we do any real work, and allows us to unwind the writable unmap check unconditionally as required and to perform a CONFIGDEBUGVMMAPLETREE validation unconditionally also.

We move a number of things here:

1. We preallocate memory for the iterator before we call the file-backed memory hook, allowing us to exit early and avoid having to perform complicated and error-prone close/free logic. We carefully free iterator state on both success and error paths.

2. The enclosing mmapregion() function handles the mappingmapwritable() logic early. Previously the logic had the mappingmapwritable() at the point of mapping a newly allocated file-backed VMA, and a matching mappingunmapwritable() on success and error paths.

We now do this unconditionally if this is a file-backed, shared writable mapping. If a driver changes the flags to eliminate VMMAYWRITE, however doing so does not invalidate the seal check we just performed, and we in any case always decrement the counter in the wrapper.

We perform a debug assert to ensure a driver does not attempt to do the opposite.

3. We also move archvalidateflags() up into the mmapregion() function. This is only relevant on arm64 and sparc64, and the check is only meaningful for SPARC with ADI enabled. We explicitly add a warning for this arch if a driver invalidates this check, though the code ought eventually to be fixed to eliminate the need for this.

With all of these measures in place, we no longer need to explicitly close the VMA on error paths, as we place all checks which might fail prior to a call to any driver mmap hook.

This eliminates an entire class of errors, makes the code easier to reason about and more robust.

i40e: fix race condition by adding filter's intermediate sync state

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

posix-clock: Fix missing timespec64 check in pcclocksettime()

As Andrew pointed out, it will make sense that the PTP core checked timespec64 struct's tvsec and tvnsec range before calling ptp->info->settime64().

As the man manual of clocksettime() said, if tp.tvsec is negative or tp.tvnsec is outside the range [0..999,999,999], it should return EINVAL, which include dynamic clocks which handles PTP clock, and the condition is consistent with timespec64valid(). As Thomas suggested, timespec64valid() only check the timespec is valid, but not ensure that the time is in a valid range, so check it ahead using timespec64validstrict() in pcclocksettime() and return -EINVAL if not valid.

There are some drivers that use tp->tvsec and tp->tvnsec directly to write registers without validity checks and assume that the higher layer has checked it, which is dangerous and will benefit from this, such as hclgeptpsettime(), igbptpsettimei210(), rcargen4ptpsettime(), and some drivers can remove the checks of itself.

bpf: Add skisinet and ISICSK check in tlsswhasctxtx/rx

btrfs: reinitialize delayed ref list after deleting it from the list

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

nvme-multipath: defer partition scanning

We need to suppress the partition scan from occuring within the controller's scanwork context. If a path error occurs here, the IO will wait until a path becomes available or all paths are torn down, but that action also occurs within scanwork, so it would deadlock. Defer the partion scan to a different context that does not block scanwork.

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

nvme: tcp: avoid race between queuelock lock and destroy

Commit 76d54bf20cdc ("nvme-tcp: don't access released socket during error recovery") added a mutexlock() call for the queue->queuelock in nvmetcpgetaddress(). However, the mutexlock() races with mutexdestroy() in nvmetcpfreequeue(), and causes the WARN below.

DEBUGLOCKSWARNON(lock->magic != lock) WARNING: CPU: 3 PID: 34077 at kernel/locking/mutex.c:587 mutexlock+0xcf0/0x1220 Modules linked in: nvmettcp nvmet nvmetcp nvmefabrics iwcm ibcm ibcore pktcdvd nftfibinet nftfibipv4 nftfibipv6 nftfib nftrejectinet nfrejectipv4 nfrejectipv6 nftreject nftct nftchainnat nfnat nfconntrack nfdefragipv6 nfdefragipv4 ipset nftables qrtr sunrpc ppdev 9pnetvirtio 9pnet pcspkr netfs parportpc parport e1000 i2cpiix4 i2csmbus loop fuse nfnetlink zram bochs drmvramhelper drmttmhelper ttm drmkmshelper xfs drm sym53c8xx floppy nvme scsitransportspi nvmecore nvmeauth serioraw atageneric pataacpi dmmultipath qemufwcfg [last unloaded: ibuverbs] CPU: 3 UID: 0 PID: 34077 Comm: udisksd Not tainted 6.11.0-rc7 #319 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014 RIP: 0010:mutexlock+0xcf0/0x1220 Code: 08 84 d2 0f 85 c8 04 00 00 8b 15 ef b6 c8 01 85 d2 0f 85 78 f4 ff ff 48 c7 c6 20 93 ee af 48 c7 c7 60 91 ee af e8 f0 a7 6d fd <0f> 0b e9 5e f4 ff ff 48 b8 00 00 00 00 00 fc ff df 4c 89 f2 48 c1 RSP: 0018:ffff88811305f760 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88812c652058 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000001 RBP: ffff88811305f8b0 R08: 0000000000000001 R09: ffffed1075c36341 R10: ffff8883ae1b1a0b R11: 0000000000010498 R12: 0000000000000000 R13: 0000000000000000 R14: dffffc0000000000 R15: ffff88812c652058 FS: 00007f9713ae4980(0000) GS:ffff8883ae180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fcd78483c7c CR3: 0000000122c38000 CR4: 00000000000006f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ? warn.cold+0x5b/0x1af ? mutexlock+0xcf0/0x1220 ? reportbug+0x1ec/0x390 ? handlebug+0x3c/0x80 ? excinvalidop+0x13/0x40 ? asmexcinvalidop+0x16/0x20 ? mutexlock+0xcf0/0x1220 ? nvmetcpgetaddress+0xc2/0x1e0 [nvmetcp] ? pfxmutexlock+0x10/0x10 ? lockacquire+0xd6a/0x59e0 ? nvmetcpgetaddress+0xc2/0x1e0 [nvmetcp] nvmetcpgetaddress+0xc2/0x1e0 [nvmetcp] ? pfxnvmetcpgetaddress+0x10/0x10 [nvmetcp] nvmesysfsshowaddress+0x81/0xc0 [nvmecore] devattrshow+0x42/0x80 ? asanmemset+0x1f/0x40 sysfskfseqshow+0x1f0/0x370 seqreaditer+0x2cb/0x1130 ? rwverifyarea+0x3b1/0x590 ? mutexlock+0x433/0x1220 vfsread+0x6a6/0xa20 ? lockdephardirqson+0x78/0x100 ? pfxvfsread+0x10/0x10 ksysread+0xf7/0x1d0 ? pfxksysread+0x10/0x10 ? x64sysopenat+0x105/0x1d0 dosyscall64+0x93/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? pfxksysread+0x10/0x10 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? lockdephardirqsonprepare+0x16d/0x400 ? dosyscall64+0x9f/0x180 ? lockdephardirqson+0x78/0x100 ? dosyscall64+0x9f/0x180 ? dosyscall64+0x9f/0x180 entrySYSCALL64afterhwframe+0x76/0x7e RIP: 0033:0x7f9713f55cfa Code: 55 48 89 e5 48 83 ec 20 48 89 55 e8 48 89 75 f0 89 7d f8 e8 e8 74 f8 ff 48 8b 55 e8 48 8b 75 f0 4 ---truncated---

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

mm/thp: fix deferred split unqueue naming and locking

Recent changes are putting more pressure on THP deferred split queues: under load revealing long-standing races, causing listdel corruptions, "Bad page state"s and worse (I keep BUGs in both of those, so usually don't get to see how badly they end up without). The relevant recent changes being 6.8's mTHP, 6.10's mTHP swapout, and 6.12's mTHP swapin, improved swap allocation, and underused THP splitting.

Before fixing locking: rename misleading folioundolargermappable(), which does not undo largermappable, to foliounqueuedeferredsplit(), which is what it does. But that and its out-of-line callee are mm internals of very limited usability: add comment and WARNONONCEs to check usage; and return a bool to say if a deferred split was unqueued, which can then be used in WARNONONCEs around safety checks (sparing callers the arcane conditionals in foliounqueuedeferredsplit()).

Just omit the foliounqueuedeferredsplit() from freeunreffolios(), all of whose callers now call it beforehand (and if any forget then badpage() will tell) - except for its caller putpageslist(), which itself no longer has any callers (and will be deleted separately).

Swapout: memcgroupswapout() has been resetting folio->memcgdata 0 without checking and unqueueing a THP folio from deferred split list; which is unfortunate, since the splitqueuelock depends on the memcg (when memcg is enabled); so swapout has been unqueueing such THPs later, when freeing the folio, using the pgdat's lock instead: potentially corrupting the memcg's list. removemapping() has frozen refcount to 0 here, so no problem with calling foliounqueuedeferredsplit() before resetting memcgdata.

That goes back to 5.4 commit 87eaceb3faa5 ("mm: thp: make deferred split shrinker memcg aware"): which included a check on swapcache before adding to deferred queue, but no check on deferred queue before adding THP to swapcache. That worked fine with the usual sequence of events in reclaim (though there were a couple of rare ways in which a THP on deferred queue could have been swapped out), but 6.12 commit dafff3f4c850 ("mm: split underused THPs") avoids splitting underused THPs in reclaim, which makes swapcache THPs on deferred queue commonplace.

Keep the check on swapcache before adding to deferred queue? Yes: it is no longer essential, but preserves the existing behaviour, and is likely to be a worthwhile optimization (vmstat showed much more traffic on the queue under swapping load if the check was removed); update its comment.

Memcg-v1 move (deprecated): memcgroupmoveaccount() has been changing folio->memcgdata without checking and unqueueing a THP folio from the deferred list, sometimes corrupting "from" memcg's list, like swapout. Refcount is non-zero here, so foliounqueuedeferredsplit() can only be used in a WARNONONCE to validate the fix, which must be done earlier: memcgroupmovechargepterange() first try to split the THP (splitting of course unqueues), or skip it if that fails. Not ideal, but moving charge has been requested, and khugepaged should repair the THP later: nobody wants new custom unqueueing code just for this deprecated case.

The 87eaceb3faa5 commit did have the code to move from one deferred list to another (but was not conscious of its unsafety while refcount non-0); but that was removed by 5.6 commit fac0516b5534 ("mm: thp: don't need care deferred split queue in memcg charge move path"), which argued that the existence of a PMD mapping guarantees that the THP cannot be on a deferred list. As above, false in rare cases, and now commonly false.

Backport to 6.11 should be straightforward. Earlier backports must take care that other deferredlist fixes and dependencies are included. There is not a strong case for backports, but they can fix cornercases.

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

netfilter: nfrejectipv6: fix potential crash in nfsendreset6()

I got a syzbot report without a repro [1] crashing in nfsendreset6()

I think the issue is that dev->hardheaderlen is zero, and we attempt later to push an Ethernet header.

Use LLMAXHEADER, as other functions in net/ipv6/netfilter/nfrejectipv6.c.

[1]

skbuff: skbunderpanic: text:ffffffff89b1d008 len:74 put:14 head:ffff88803123aa00 data:ffff88803123a9f2 tail:0x3c end:0x140 dev:syztun kernel BUG at net/core/skbuff.c:206 ! Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 0 UID: 0 PID: 7373 Comm: syz.1.568 Not tainted 6.12.0-rc2-syzkaller-00631-g6d858708d465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024 RIP: 0010:skbpanic net/core/skbuff.c:206 [inline] RIP: 0010:skbunderpanic+0x14b/0x150 net/core/skbuff.c:216 Code: 0d 8d 48 c7 c6 60 a6 29 8e 48 8b 54 24 08 8b 0c 24 44 8b 44 24 04 4d 89 e9 50 41 54 41 57 41 56 e8 ba 30 38 02 48 83 c4 20 90 <0f> 0b 0f 1f 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 RSP: 0018:ffffc900045269b0 EFLAGS: 00010282 RAX: 0000000000000088 RBX: dffffc0000000000 RCX: cd66dacdc5d8e800 RDX: 0000000000000000 RSI: 0000000000000200 RDI: 0000000000000000 RBP: ffff88802d39a3d0 R08: ffffffff8174afec R09: 1ffff920008a4ccc R10: dffffc0000000000 R11: fffff520008a4ccd R12: 0000000000000140 R13: ffff88803123aa00 R14: ffff88803123a9f2 R15: 000000000000003c FS: 00007fdbee5ff6c0(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000005d322000 CR4: 00000000003526f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> skbpush+0xe5/0x100 net/core/skbuff.c:2636 ethheader+0x38/0x1f0 net/ethernet/eth.c:83 devhardheader include/linux/netdevice.h:3208 [inline] nfsendreset6+0xce6/0x1270 net/ipv6/netfilter/nfrejectipv6.c:358 nftrejectineteval+0x3b9/0x690 net/netfilter/nftrejectinet.c:48 exprcallopseval net/netfilter/nftablescore.c:240 [inline] nftdochain+0x4ad/0x1da0 net/netfilter/nftablescore.c:288 nftdochaininet+0x418/0x6b0 net/netfilter/nftchainfilter.c:161 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xc3/0x220 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] NFHOOK include/linux/netfilter.h:312 [inline] brnfpreroutingipv6+0x63e/0x770 net/bridge/brnetfilteripv6.c:184 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookbridgepre net/bridge/brinput.c:277 [inline] brhandleframe+0x9fd/0x1530 net/bridge/brinput.c:424 netifreceiveskbcore+0x13e8/0x4570 net/core/dev.c:5562 netifreceiveskbonecore net/core/dev.c:5666 [inline] netifreceiveskb+0x12f/0x650 net/core/dev.c:5781 netifreceiveskbinternal net/core/dev.c:5867 [inline] netifreceiveskb+0x1e8/0x890 net/core/dev.c:5926 tunrxbatched+0x1b7/0x8f0 drivers/net/tun.c:1550 tungetuser+0x3056/0x47e0 drivers/net/tun.c:2007 tunchrwriteiter+0x10d/0x1f0 drivers/net/tun.c:2053 newsyncwrite fs/readwrite.c:590 [inline] vfswrite+0xa6d/0xc90 fs/readwrite.c:683 ksyswrite+0x183/0x2b0 fs/readwrite.c:736 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xf3/0x230 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fdbeeb7d1ff Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 c9 8d 02 00 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 1c 8e 02 00 48 RSP: 002b:00007fdbee5ff000 EFLAGS: 00000293 ORIGRAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fdbeed36058 RCX: 00007fdbeeb7d1ff RDX: 000000000000008e RSI: 0000000020000040 RDI: 00000000000000c8 RBP: 00007fdbeebf12be R08: 0000000 ---truncated---

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

tty: ngsm: Fix use-after-free in gsmcleanupmux

BUG: KASAN: slab-use-after-free in gsmcleanupmux+0x77b/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsmcleanupmux+0x77b/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] pfxgsmcleanupmux+0x10/0x10 drivers/tty/ngsm.c:3124 [ngsm] pfxschedclockcpu+0x10/0x10 kernel/sched/clock.c:389 updateloadavg+0x1c1/0x27b0 kernel/sched/fair.c:4500 pfxminvruntimecbrotate+0x10/0x10 kernel/sched/fair.c:846 rbinsertaugmented+0x492/0xbf0 lib/rbtree.c:161 gsmldioctl+0x395/0x1450 drivers/tty/ngsm.c:3408 [ngsm] rawspinlockirqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 pfxgsmldioctl+0x10/0x10 drivers/tty/ngsm.c:3822 [ngsm] ktimeget+0x5e/0x140 kernel/time/timekeeping.c:195 ldsemdownread+0x94/0x4e0 arch/x86/include/asm/atomic6464.h:79 pfxldsemdownread+0x10/0x10 drivers/tty/ttyldsem.c:338 pfxdovfsioctl+0x10/0x10 fs/ioctl.c:805 ttyioctl+0x643/0x1100 drivers/tty/ttyio.c:2818

Allocated by task 65: gsmdataalloc.constprop.0+0x27/0x190 drivers/tty/ngsm.c:926 [ngsm] gsmsend+0x2c/0x580 drivers/tty/ngsm.c:819 [ngsm] gsm1receive+0x547/0xad0 drivers/tty/ngsm.c:3038 [ngsm] gsmldreceivebuf+0x176/0x280 drivers/tty/ngsm.c:3609 [ngsm] ttyldiscreceivebuf+0x101/0x1e0 drivers/tty/ttybuffer.c:391 ttyportdefaultreceivebuf+0x61/0xa0 drivers/tty/ttyport.c:39 flushtoldisc+0x1b0/0x750 drivers/tty/ttybuffer.c:445 processscheduledworks+0x2b0/0x10d0 kernel/workqueue.c:3229 workerthread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 retfromfork+0x2d/0x70 arch/x86/kernel/process.c:147 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:257

Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsmcleanupmux+0x36c/0x7b0 drivers/tty/ngsm.c:3160 [ngsm] gsmldioctl+0x395/0x1450 drivers/tty/ngsm.c:3408 [ngsm] ttyioctl+0x643/0x1100 drivers/tty/ttyio.c:2818

[Analysis] gsmmsg on the txctrllist or txdatalist of gsmmux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.

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

uprobe: avoid out-of-bounds memory access of fetching args

Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.

Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And storetraceargs() won't check whether these data exceeds a single page or not, caused out-of-bounds memory access.

It could be reproduced by following steps: 1. build kernel with CONFIGKASAN enabled 2. save follow program as test.c

\#include <stdio.h> \#include <stdlib.h> \#include <string.h>

// If string length large than MAXSTRINGSIZE, the fetchstorestrlen() // will return 0, cause getdatasize() return shorter size, and // storetraceargs() will not trigger out-of-bounds access. // So make string length less than 4096. \#define STRLEN 4093

void generatestring(char str, int n) { int i; for (i = 0; i < n; ++i) { char c = i % 26 + 'a'; str[i] = c; } str[n-1] = '\0'; }

void printstring(char str) { printf("%s\n", str); }

int main() { char tmp[STRLEN];

generatestring(tmp, STRLEN); printstring(tmp);

return 0; } 3. compile program gcc -o test test.c

4. get the offset of printstring() objdump -t test | grep -w printstring 0000000000401199 g F .text 000000000000001b printstring

5. configure uprobe with offset 0x1199 off=0x1199

cd /sys/kernel/debug/tracing/ echo "p /root/test:${off} arg1=+0(%di):ustring arg2=\$comm arg3=+0(%di):ustring" > uprobeevents echo 1 > events/uprobes/enable echo 1 > tracingon

6. run test, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpyfromuser+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace: <TASK> dumpstacklvl+0x55/0x70 printaddressdescription.constprop.0+0x27/0x310 kasanreport+0x10f/0x120 ? strncpyfromuser+0x1d6/0x1f0 strncpyfromuser+0x1d6/0x1f0 ? rmqueue.constprop.0+0x70d/0x2ad0 processfetchinsn+0xb26/0x1470 ? pfxprocessfetchinsn+0x10/0x10 ? rawspinlock+0x85/0xe0 ? pfxrawspinlock+0x10/0x10 ? pteoffsetmap+0x1f/0x2d0 ? unwindnextframe+0xc5f/0x1f80 ? archstackwalk+0x68/0xf0 ? isbpftextaddress+0x23/0x30 ? kerneltextaddress.part.0+0xbb/0xd0 ? kerneltextaddress+0x66/0xb0 ? unwindgetreturnaddress+0x5e/0xa0 ? pfxstacktraceconsumeentry+0x10/0x10 ? archstackwalk+0xa2/0xf0 ? rawspinlockirqsave+0x8b/0xf0 ? pfxrawspinlockirqsave+0x10/0x10 ? depotallocstack+0x4c/0x1f0 ? rawspinunlockirqrestore+0xe/0x30 ? stackdepotsaveflags+0x35d/0x4f0 ? kasansavestack+0x34/0x50 ? kasansavestack+0x24/0x50 ? mutexlock+0x91/0xe0 ? pfxmutexlock+0x10/0x10 prepareuprobebuffer.part.0+0x2cd/0x500 uprobedispatcher+0x2c3/0x6a0 ? pfxuprobedispatcher+0x10/0x10 ? kasanslaballoc+0x4d/0x90 handlerchain+0xdd/0x3e0 handleswbp+0x26e/0x3d0 ? pfxhandleswbp+0x10/0x10 ? uprobepresstepnotifier+0x151/0x1b0 irqentryexittousermode+0xe2/0x1b0 asmexcint3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000 </TASK>

This commit enforces the buffer's maxlen less than a page-size to avoid storetraceargs() out-of-memory access.

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

net: fix udp gso skbsegment after pull from fraglist

Commit a1e40ac5b5e9 ("net: gso: fix udp gso fraglist segmentation after pull from fraglist") detected invalid geometry in fraglist skbs and redirects them from skbsegmentlist to more robust skbsegment. But some packets with modified geometry can also hit bugs in that code. We don't know how many such cases exist. Addressing each one by one also requires touching the complex skbsegment code, which risks introducing bugs for other types of skbs. Instead, linearize all these packets that fail the basic invariants on gso fraglist skbs. That is more robust.

If only part of the fraglist payload is pulled into headskb, it will always cause exception when splitting skbs by skbsegment. For detailed call stack information, see below.

Valid SKBGSOFRAGLIST skbs - consist of two or more segments - the headskb holds the protocol headers plus first gsosize - one or more fraglist skbs hold exactly one segment - all but the last must be gsosize

Optional datapath hooks such as NAT and BPF (bpfskbpulldata) can modify fraglist skbs, breaking these invariants.

In extreme cases they pull one part of data into skb linear. For UDP, this causes three payloads with lengths of (11,11,10) bytes were pulled tail to become (12,10,10) bytes.

The skbs no longer meets the above SKBGSOFRAGLIST conditions because payload was pulled into headskb, it needs to be linearized before pass to regular skbsegment.

skbsegment+0xcd0/0xd14 udpgsosegment+0x334/0x5f4 udp4ufofragment+0x118/0x15c inetgsosegment+0x164/0x338 skbmacgsosegment+0xc4/0x13c skbgsosegment+0xc4/0x124 validatexmitskb+0x9c/0x2c0 validatexmitskblist+0x4c/0x80 schdirectxmit+0x70/0x404 devqueuexmit+0x64c/0xe5c neighresolveoutput+0x178/0x1c4 ipfinishoutput2+0x37c/0x47c ipfinishoutput+0x194/0x240 ipfinishoutput+0x20/0xf4 ipoutput+0x100/0x1a0 NFHOOK+0xc4/0x16c ipforward+0x314/0x32c iprcv+0x90/0x118 netifreceiveskb+0x74/0x124 processbacklog+0xe8/0x1a4 napipoll+0x5c/0x1f8 netrxaction+0x154/0x314 handlesoftirqs+0x154/0x4b8

[118.376811] [C201134] rxq0pus: [name:bug&]kernel BUG at net/core/skbuff.c:4278! [118.376829] [C201134] rxq0pus: [name:traps&]Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP [118.470774] [C201134] rxq0pus: [name:mrdump&]Kernel Offset: 0x178cc00000 from 0xffffffc008000000 [118.470810] [C201134] rxq0pus: [name:mrdump&]PHYSOFFSET: 0x40000000 [118.470827] [C201134] rxq0pus: [name:mrdump&]pstate: 60400005 (nZCv daif +PAN -UAO) [118.470848] [C201134] rxq0pus: [name:mrdump&]pc : [0xffffffd79598aefc] skbsegment+0xcd0/0xd14 [118.470900] [C201134] rxq0pus: [name:mrdump&]lr : [0xffffffd79598a5e8] skbsegment+0x3bc/0xd14 [118.470928] [C201134] rxq0pus: [name:mrdump&]sp : ffffffc008013770