eth: bnxt: always recalculate features after XDP clearing, fix null-deref
In the Linux kernel, the following vulnerability has been resolved:
net: fec: handle pagepooldevallocpages error
The fecenetupdatecbd function calls pagepooldevallocpages but did not handle the case when it returned NULL. There was a WARNON(!newpage) but it would still proceed to use the NULL pointer and then crash.
This case does seem somewhat rare but when the system is under memory pressure it can happen. One case where I can duplicate this with some frequency is when writing over a smbd share to a SATA HDD attached to an imx6q.
Setting /proc/sys/vm/minfreekbytes to higher values also seems to solve the problem for my test case. But it still seems wrong that the fec driver ignores the memory allocation error and can crash.
This commit handles the allocation error by dropping the current packet.
In the Linux kernel, the following vulnerability has been resolved:
iouring/eventfd: ensure ioeventfdsignal() defers another RCU period
ioeventfddosignal() is invoked from an RCU callback, but when dropping the reference to the ioevfd, it calls ioeventfdfree() directly if the refcount drops to zero. This isn't correct, as any potential freeing of the ioevfd should be deferred another RCU grace period.
Just call ioeventfdput() rather than open-code the dec-and-test and free, which will correctly defer it another RCU grace period.
In the Linux kernel, the following vulnerability has been resolved:
topology: Keep the cpumask unchanged when printing cpumap
During fuzz testing, the following warning was discovered:
different return values (15 and 11) from vsnprintf("%pbl ", ...)
test:keyward is WARNING in kvasprintf WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130 Call Trace: kvasprintf+0x121/0x130 kasprintf+0xa6/0xe0 bitmapprinttobuf+0x89/0x100 coresiblingslistread+0x7e/0xb0 kernfsfilereaditer+0x15b/0x270 newsyncread+0x153/0x260 vfsread+0x215/0x290 ksysread+0xb9/0x160 dosyscall64+0x56/0x100 entrySYSCALL64afterhwframe+0x78/0xe2
The call trace shows that kvasprintf() reported this warning during the printing of coresiblingslist. kvasprintf() has several steps:
(1) First, calculate the length of the resulting formatted string.
(2) Allocate a buffer based on the returned length.
(3) Then, perform the actual string formatting.
(4) Check whether the lengths of the formatted strings returned in steps (1) and (2) are consistent.
If the corecpumask is modified between steps (1) and (3), the lengths obtained in these two steps may not match. Indeed our test includes cpu hotplugging, which should modify corecpumask while printing.
To fix this issue, cache the cpumask into a temporary variable before calling cpumapprint{list, cpumask}tobuf(), to keep it unchanged during the printing process.
In the Linux kernel, the following vulnerability has been resolved:
scsi: sg: Fix slab-use-after-free read in sgrelease()
Fix a use-after-free bug in sgrelease(), detected by syzbot with KASAN:
BUG: KASAN: slab-use-after-free in lockrelease+0x151/0xa30 kernel/locking/lockdep.c:5838 mutexunlockslowpath+0xe2/0x750 kernel/locking/mutex.c:912 sgrelease+0x1f4/0x2e0 drivers/scsi/sg.c:407
In sgrelease(), the function krefput(&sfp->fref, sgremovesfp) is called before releasing the openrellock mutex. The krefput() call may decrement the reference count of sfp to zero, triggering its cleanup through sgremovesfp(). This cleanup includes scheduling deferred work via sgremovesfpusercontext(), which ultimately frees sfp.
After krefput(), sgrelease() continues to unlock openrellock and may reference sfp or sdp. If sfp has already been freed, this results in a slab-use-after-free error.
Move the krefput(&sfp->fref, sgremovesfp) call after unlocking the openrellock mutex. This ensures:
- No references to sfp or sdp occur after the reference count is decremented.
- Cleanup functions such as sgremovesfp() and sgremovesfpusercontext() can safely execute without impacting the mutex handling in sgrelease().
The fix has been tested and validated by syzbot. This patch closes the bug reported at the following syzkaller link and ensures proper sequencing of resource cleanup and mutex operations, eliminating the risk of use-after-free errors in sgrelease().
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: properly synchronize freeing resources during CPU hotunplug
In zswapcompress() and zswapdecompress(), the per-CPU acompctx of the current CPU at the beginning of the operation is retrieved and used throughout. However, since neither preemption nor migration are disabled, it is possible that the operation continues on a different CPU.
If the original CPU is hotunplugged while the acompctx is still in use, we run into a UAF bug as some of the resources attached to the acompctx are freed during hotunplug in zswapcpucompdead() (i.e. acompctx.buffer, acompctx.req, or acompctx.acomp).
The problem was introduced in commit 1ec3b5fe6eec ("mm/zswap: move to use cryptoacomp API for hardware acceleration") when the switch to the cryptoacomp API was made. Prior to that, the per-CPU cryptocomp was retrieved using getcpuptr() which disables preemption and makes sure the CPU cannot go away from under us. Preemption cannot be disabled with the cryptoacomp API as a sleepable context is needed.
Use the acompctx.mutex to synchronize CPU hotplug callbacks allocating and freeing resources with compression/decompression paths. Make sure that acompctx.req is NULL when the resources are freed. In the compression/decompression paths, check if acompctx.req is NULL after acquiring the mutex (meaning the CPU was offlined) and retry on the new CPU.
The initialization of acompctx.mutex is moved from the CPU hotplug callback to the pool initialization where it belongs (where the mutex is allocated). In addition to adding clarity, this makes sure that CPU hotplug cannot reinitialize a mutex that is already locked by compression/decompression.
Previously a fix was attempted by holding cpusreadlock() [1]. This would have caused a potential deadlock as it is possible for code already holding the lock to fall into reclaim and enter zswap (causing a deadlock). A fix was also attempted using SRCU for synchronization, but Johannes pointed out that synchronizesrcu() cannot be used in CPU hotplug notifiers [2].
Alternative fixes that were considered/attempted and could have worked: - Refcounting the per-CPU acompctx. This involves complexity in handling the race between the refcount dropping to zero in zswap[de]compress() and the refcount being re-initialized when the CPU is onlined. - Disabling migration before getting the per-CPU acompctx [3], but that's discouraged and is a much bigger hammer than needed, and could result in subtle performance issues.
[1]
bpf: check changespktdata property for extension programs
afpacket: fix vlangetprotocoldgram() vs MSGPEEK
afpacket: fix vlangettci() vs MSGPEEK
gfs2: Truncate address space when flipping GFS2DIFJDATA flag
drm/v3d: Ensure job pointer is set to NULL after job completion
hrtimers: Handle CPU state correctly on hotplug
ila: serialize calls to nfregisternethooks()
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: udpport: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using containerof().
Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctlsock' still needs to be retrieved from 'net' structure.
btrfs: flush delalloc workers queue before stopping cleaner kthread during unmount
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix a missing return value check bug
In the smb2sendinterimresp(), if ksmbdallocworkstruct() fails to allocate a node, it returns a NULL pointer to the inwork pointer. This can lead to an illegal memory write of inwork->responsebuf when allocateinterimrspbuf() attempts to perform a kzalloc() on it.
To address this issue, incorporating a check for the return value of ksmbdallocworkstruct() ensures that the function returns immediately upon allocation failure, thereby preventing the aforementioned illegal memory access.
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: cookiehmacalg: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using containerof().
Note that table->data could also be used directly, as this is the only member needed from the 'net' structure, but that would increase the size of this fix, to use 'data' everywhere 'net->sctp.sctphmacalg' is used.
In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix slab-use-after-free due to dangling pointer dqipriv
When mounting ocfs2 and then remounting it as read-only, a slab-use-after-free occurs after the user uses a syscall to quotagetnextquota. Specifically, sbdqinfo(sb, type)->dqipriv is the dangling pointer.
During the remounting process, the pointer dqipriv is freed but is never set as null leaving it to be accessed. Additionally, the read-only option for remounting sets the DQUOTSUSPENDED flag instead of setting the DQUOTUSAGEENABLED flags. Moreover, later in the process of getting the next quota, the function ocfs2getnextid is called and only checks the quota usage flags and not the quota suspended flags.
To fix this, I set dqipriv to null when it is freed after remounting with read-only and put a check for DQUOTSUSPENDED in ocfs2getnextid.
[akpm@linux-foundation.org: coding-style cleanups]
In the Linux kernel, the following vulnerability has been resolved:
sctp: sysctl: authenable: avoid using current->nsproxy
As mentioned in a previous commit of this series, using the 'net' structure via 'current' is not recommended for different reasons:
- Inconsistency: getting info from the reader's/writer's netns vs only from the opener's netns.
- current->nsproxy can be NULL in some cases, resulting in an 'Oops' (null-ptr-deref), e.g. when the current task is exiting, as spotted by syzbot [1] using acct(2).
The 'net' structure can be obtained from the table->data using containerof().
Note that table->data could also be used directly, but that would increase the size of this fix, while 'sctp.ctlsock' still needs to be retrieved from 'net' structure.
drm: adv7511: Fix use-after-free in adv7533attachdsi()
In the Linux kernel, the following vulnerability has been resolved:
mtd: rawnand: fix double free in atmelpmecccreateuser()
The "user" pointer was converted from being allocated with kzalloc() to being allocated by devmkzalloc(). Calling kfree(user) will lead to a double free.
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: discard packets if the transport changes
If the socket has been de-assigned or assigned to another transport, we must discard any packets received because they are not expected and would cause issues when we access vsk->transport.
A possible scenario is described by Hyunwoo Kim in the attached link, where after a first connect() interrupted by a signal, and a second connect() failed, we can find vsk->transport at NULL, leading to a NULL pointer dereference.
In the Linux kernel, the following vulnerability has been resolved:
pktgen: Avoid out-of-bounds access in getimixentries
Passing a sufficient amount of imix entries leads to invalid access to the pktdev->imixentries array because of the incorrect boundary check.
UBSAN: array-index-out-of-bounds in net/core/pktgen.c:874:24 index 20 is out of range for type 'imixpkt [20]' CPU: 2 PID: 1210 Comm: bash Not tainted 6.10.0-rc1 #121 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) Call Trace: <TASK> dumpstacklvl lib/dumpstack.c:117 ubsanhandleoutofbounds lib/ubsan.c:429 getimixentries net/core/pktgen.c:874 pktgenifwrite net/core/pktgen.c:1063 pdewrite fs/proc/inode.c:334 procregwrite fs/proc/inode.c:346 vfswrite fs/readwrite.c:593 ksyswrite fs/readwrite.c:644 dosyscall64 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe arch/x86/entry/entry64.S:130
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[ fp: allow to fill the array completely; minor changelog cleanup ]
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: set ATTRCTIME flags when setting mtime
David reported that the new warning from setattrcopymgtime is coming like the following.
[ 113.215316] ------------[ cut here ]------------ [ 113.215974] WARNING: CPU: 1 PID: 31 at fs/attr.c:300 setattrcopy+0x1ee/0x200 [ 113.219192] CPU: 1 UID: 0 PID: 31 Comm: kworker/1:1 Not tainted 6.13.0-rc1+ #234 [ 113.220127] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 [ 113.221530] Workqueue: ksmbd-io handleksmbdwork [ksmbd] [ 113.222220] RIP: 0010:setattrcopy+0x1ee/0x200 [ 113.222833] Code: 24 28 49 8b 44 24 30 48 89 53 58 89 43 6c 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc 48 89 df e8 77 d6 ff ff e9 cd fe ff ff <0f> 0b e9 be fe ff ff 66 0 [ 113.225110] RSP: 0018:ffffaf218010fb68 EFLAGS: 00010202 [ 113.225765] RAX: 0000000000000120 RBX: ffffa446815f8568 RCX: 0000000000000003 [ 113.226667] RDX: ffffaf218010fd38 RSI: ffffa446815f8568 RDI: ffffffff94eb03a0 [ 113.227531] RBP: ffffaf218010fb90 R08: 0000001a251e217d R09: 00000000675259fa [ 113.228426] R10: 0000000002ba8a6d R11: ffffa4468196c7a8 R12: ffffaf218010fd38 [ 113.229304] R13: 0000000000000120 R14: ffffffff94eb03a0 R15: 0000000000000000 [ 113.230210] FS: 0000000000000000(0000) GS:ffffa44739d00000(0000) knlGS:0000000000000000 [ 113.231215] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 113.232055] CR2: 00007efe0053d27e CR3: 000000000331a000 CR4: 00000000000006b0 [ 113.232926] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 113.233812] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 113.234797] Call Trace: [ 113.235116] <TASK> [ 113.235393] ? warn+0x73/0xd0 [ 113.235802] ? setattrcopy+0x1ee/0x200 [ 113.236299] ? reportbug+0xf3/0x1e0 [ 113.236757] ? handlebug+0x4d/0x90 [ 113.237202] ? excinvalidop+0x13/0x60 [ 113.237689] ? asmexcinvalidop+0x16/0x20 [ 113.238185] ? setattrcopy+0x1ee/0x200 [ 113.238692] btrfssetattr+0x80/0x820 [btrfs] [ 113.239285] ? getstackinfonoinstr+0x12/0xf0 [ 113.239857] ? moduleaddress+0x22/0xa0 [ 113.240368] ? handleksmbdwork+0x6e/0x460 [ksmbd] [ 113.240993] ? moduletextaddress+0x9/0x50 [ 113.241545] ? moduleaddress+0x22/0xa0 [ 113.242033] ? unwindnextframe+0x10e/0x920 [ 113.242600] ? pfxstacktraceconsumeentry+0x10/0x10 [ 113.243268] notifychange+0x2c2/0x4e0 [ 113.243746] ? stackdepotsaveflags+0x27/0x730 [ 113.244339] ? setfilebasicinfo+0x130/0x2b0 [ksmbd] [ 113.244993] setfilebasicinfo+0x130/0x2b0 [ksmbd] [ 113.245613] ? processscheduledworks+0xbe/0x310 [ 113.246181] ? workerthread+0x100/0x240 [ 113.246696] ? kthread+0xc8/0x100 [ 113.247126] ? retfromfork+0x2b/0x40 [ 113.247606] ? retfromforkasm+0x1a/0x30 [ 113.248132] smb2setinfo+0x63f/0xa70 [ksmbd]
ksmbd is trying to set the atime and mtime via notifychange without also setting the ctime. so This patch add ATTRCTIME flags when setting mtime to avoid a warning.
drm/dpmst: Ensure mstprimary pointer is valid in drmdpmsthandleupreq()
In the Linux kernel, the following vulnerability has been resolved:
nvme-rdma: unquiesce adminq before destroy it
Kernel will hang on destroy adminq while we create ctrl failed, such as following calltrace:
PID: 23644 TASK: ff2d52b40f439fc0 CPU: 2 COMMAND: "nvme" #0 [ff61d23de260fb78] schedule at ffffffff8323bc15 #1 [ff61d23de260fc08] schedule at ffffffff8323c014 #2 [ff61d23de260fc28] blkmqfreezequeuewait at ffffffff82a3dba1 #3 [ff61d23de260fc78] blkfreezequeue at ffffffff82a4113a #4 [ff61d23de260fc90] blkcleanupqueue at ffffffff82a33006 #5 [ff61d23de260fcb0] nvmerdmadestroyadminqueue at ffffffffc12686ce #6 [ff61d23de260fcc8] nvmerdmasetupctrl at ffffffffc1268ced #7 [ff61d23de260fd28] nvmerdmacreatectrl at ffffffffc126919b #8 [ff61d23de260fd68] nvmfdevwrite at ffffffffc024f362 #9 [ff61d23de260fe38] vfswrite at ffffffff827d5f25 RIP: 00007fda7891d574 RSP: 00007ffe2ef06958 RFLAGS: 00000202 RAX: ffffffffffffffda RBX: 000055e8122a4d90 RCX: 00007fda7891d574 RDX: 000000000000012b RSI: 000055e8122a4d90 RDI: 0000000000000004 RBP: 00007ffe2ef079c0 R8: 000000000000012b R9: 000055e8122a4d90 R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000004 R13: 000055e8122923c0 R14: 000000000000012b R15: 00007fda78a54500 ORIGRAX: 0000000000000001 CS: 0033 SS: 002b
This due to we have quiesced admiq before cancel requests, but forgot to unquiesce before destroy it, as a result we fail to drain the pending requests, and hang on blkmqfreezequeuewait() forever. Here try to reuse nvmerdmateardownadminqueue() to fix this issue and simplify the code.
In the Linux kernel, the following vulnerability has been resolved:
net: sched: fix ets qdisc OOB Indexing
Haowei Yan <g1042620637@gmail.com> found that etsclassfromarg() can index an Out-Of-Bound class in etsclassfromarg() when passed clid of 0. The overflow may cause local privilege escalation.
[ 18.852298] ------------[ cut here ]------------ [ 18.853271] UBSAN: array-index-out-of-bounds in net/sched/schets.c:93:20 [ 18.853743] index 18446744073709551615 is out of range for type 'etsclass [16]' [ 18.854254] CPU: 0 UID: 0 PID: 1275 Comm: poc Not tainted 6.12.6-dirty #17 [ 18.854821] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 [ 18.856532] Call Trace: [ 18.857441] <TASK> [ 18.858227] dumpstacklvl+0xc2/0xf0 [ 18.859607] dumpstack+0x10/0x20 [ 18.860908] ubsanhandleoutofbounds+0xa7/0xf0 [ 18.864022] etsclasschange+0x3d6/0x3f0 [ 18.864322] tcctltclass+0x251/0x910 [ 18.864587] ? lockacquire+0x5e/0x140 [ 18.865113] ? mutexlock+0x9c/0xe70 [ 18.866009] ? mutexlock+0xa34/0xe70 [ 18.866401] rtnetlinkrcvmsg+0x170/0x6f0 [ 18.866806] ? lockacquire+0x578/0xc10 [ 18.867184] ? pfxrtnetlinkrcvmsg+0x10/0x10 [ 18.867503] netlinkrcvskb+0x59/0x110 [ 18.867776] rtnetlinkrcv+0x15/0x30 [ 18.868159] netlinkunicast+0x1c3/0x2b0 [ 18.868440] netlinksendmsg+0x239/0x4b0 [ 18.868721] syssendmsg+0x3e2/0x410 [ 18.869012] syssendmsg+0x88/0xe0 [ 18.869276] ? rseqipfixup+0x198/0x260 [ 18.869563] ? rsequpdatecpunodeid+0x10a/0x190 [ 18.869900] ? tracehardirqsoff+0x5a/0xd0 [ 18.870196] ? syscallexittousermode+0xcc/0x220 [ 18.870547] ? dosyscall64+0x93/0x150 [ 18.870821] ? memcgslabfreehook+0x69/0x290 [ 18.871157] syssendmsg+0x69/0xd0 [ 18.871416] x64syssendmsg+0x1d/0x30 [ 18.871699] x64syscall+0x9e2/0x2670 [ 18.871979] dosyscall64+0x87/0x150 [ 18.873280] ? dosyscall64+0x93/0x150 [ 18.874742] ? lockrelease+0x7b/0x160 [ 18.876157] ? douseraddrfault+0x5ce/0x8f0 [ 18.877833] ? irqentryexittousermode+0xc2/0x210 [ 18.879608] ? irqentryexit+0x77/0xb0 [ 18.879808] ? clearbhbloop+0x15/0x70 [ 18.880023] ? clearbhbloop+0x15/0x70 [ 18.880223] ? clearbhbloop+0x15/0x70 [ 18.880426] entrySYSCALL64afterhwframe+0x76/0x7e [ 18.880683] RIP: 0033:0x44a957 [ 18.880851] Code: ff ff e8 fc 00 00 00 66 2e 0f 1f 84 00 00 00 00 00 66 90 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 89 54 24 1c 48 8974 24 10 [ 18.881766] RSP: 002b:00007ffcdd00fad8 EFLAGS: 00000246 ORIGRAX: 000000000000002e [ 18.882149] RAX: ffffffffffffffda RBX: 00007ffcdd010db8 RCX: 000000000044a957 [ 18.882507] RDX: 0000000000000000 RSI: 00007ffcdd00fb70 RDI: 0000000000000003 [ 18.885037] RBP: 00007ffcdd010bc0 R08: 000000000703c770 R09: 000000000703c7c0 [ 18.887203] R10: 0000000000000080 R11: 0000000000000246 R12: 0000000000000001 [ 18.888026] R13: 00007ffcdd010da8 R14: 00000000004ca7d0 R15: 0000000000000001 [ 18.888395] </TASK> [ 18.888610] ---[ end trace ]---
In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: check the bounds of read/write syscalls
count and offset are passed from user space and not checked, only offset is capped to 40 bits, which can be used to read/write out of bounds of the device.
In the Linux kernel, the following vulnerability has been resolved:
gtp: Destroy device along with udp socket's netns dismantle.
gtpnewlink() links the device to a list in devnet(dev) instead of srcnet, where a udp tunnel socket is created.
Even when srcnet is removed, the device stays alive on devnet(dev). Then, removing srcnet triggers the splat below. [0]
In this example, gtp0 is created in ns2, and the udp socket is created in ns1.
ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name gtp0 type gtp role sgsn ip netns del ns1
Let's link the device to the socket's netns instead.
Now, gtpnetexitbatchrtnl() needs another netdev iteration to remove all gtp devices in the netns.
[0]: reftracker: net notrefcnt@000000003d6e7d05 has 1/2 users at skalloc (./include/net/netnamespace.h:345 net/core/sock.c:2236) inetcreate (net/ipv4/afinet.c:326 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1558) udpsockcreate4 (net/ipv4/udptunnelcore.c:18) gtpcreatesock (./include/net/udptunnel.h:59 drivers/net/gtp.c:1423) gtpcreatesockets (drivers/net/gtp.c:1447) gtpnewlink (drivers/net/gtp.c:1507) rtnlnewlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlinkrcvmsg (net/core/rtnetlink.c:6922) netlinkrcvskb (net/netlink/afnetlink.c:2542) netlinkunicast (net/netlink/afnetlink.c:1321 net/netlink/afnetlink.c:1347) netlinksendmsg (net/netlink/afnetlink.c:1891) syssendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) syssendmsg (net/socket.c:2639) syssendmsg (net/socket.c:2669) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
WARNING: CPU: 1 PID: 60 at lib/reftracker.c:179 reftrackerdirexit (lib/reftracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 60 Comm: kworker/u16:2 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanupnet RIP: 0010:reftrackerdirexit (lib/reftracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000009a07b60 EFLAGS: 00010286 RAX: 0000000000002bd3 RBX: ff1100000f4e1aa0 RCX: 1ffffffff0e40ac6 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000f4e1af0 R08: 0000000000000001 R09: fffffbfff0e395ae R10: 0000000000000001 R11: 0000000000036001 R12: ff1100000f4e1af0 R13: dead000000000100 R14: ff1100000f4e1af0 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f9b2464bd98 CR3: 0000000005286005 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn (kernel/panic.c:748) ? reftrackerdirexit (lib/reftracker.c:179) ? reportbug (lib/bug.c:201 lib/bug.c:219) ? handlebug (arch/x86/kernel/traps.c:285) ? excinvalidop (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asmexcinvalidop (./arch/x86/include/asm/idtentry.h:621) ? rawspinunlockirqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlockapismp.h:151 kernel/locking/spinlock.c:194) ? reftrackerdirexit (lib/reftracker.c:179) ? pfxreftrackerdirexit (lib/reftracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) netfree (net/core/netnamespace.c:476 net/core/netnamespace.c:467) cleanupnet (net/core/netnamespace.c:664 (discriminator 3)) processonework (kernel/workqueue.c:3229) workerthread (kernel/workqueue.c:3304 kernel/workqueue.c:3391 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
pfcp: Destroy device along with udp socket's netns dismantle.
pfcpnewlink() links the device to a list in devnet(dev) instead of net, where a udp tunnel socket is created.
Even when net is removed, the device stays alive on devnet(dev). Then, removing net triggers the splat below. [0]
In this example, pfcp0 is created in ns2, but the udp socket is created in ns1.
ip netns add ns1 ip netns add ns2 ip -n ns1 link add netns ns2 name pfcp0 type pfcp ip netns del ns1
Let's link the device to the socket's netns instead.
Now, pfcpnetexit() needs another netdev iteration to remove all pfcp devices in the netns.
pfcpdevlist is not used under RCU, so the list API is converted to the non-RCU variant.
pfcpnetexit() can be converted to .exitbatchrtnl() in net-next.
[0]: reftracker: net notrefcnt@00000000128b34dc has 1/1 users at skalloc (./include/net/netnamespace.h:345 net/core/sock.c:2236) inetcreate (net/ipv4/afinet.c:326 net/ipv4/afinet.c:252) sockcreate (net/socket.c:1558) udpsockcreate4 (net/ipv4/udptunnelcore.c:18) pfcpcreatesock (drivers/net/pfcp.c:168) pfcpnewlink (drivers/net/pfcp.c:182 drivers/net/pfcp.c:197) rtnlnewlink (net/core/rtnetlink.c:3786 net/core/rtnetlink.c:3897 net/core/rtnetlink.c:4012) rtnetlinkrcvmsg (net/core/rtnetlink.c:6922) netlinkrcvskb (net/netlink/afnetlink.c:2542) netlinkunicast (net/netlink/afnetlink.c:1321 net/netlink/afnetlink.c:1347) netlinksendmsg (net/netlink/afnetlink.c:1891) syssendmsg (net/socket.c:711 net/socket.c:726 net/socket.c:2583) syssendmsg (net/socket.c:2639) syssendmsg (net/socket.c:2669) dosyscall64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:130)
WARNING: CPU: 1 PID: 11 at lib/reftracker.c:179 reftrackerdirexit (lib/reftracker.c:179) Modules linked in: CPU: 1 UID: 0 PID: 11 Comm: kworker/u16:0 Not tainted 6.13.0-rc5-00147-g4c1224501e9d #5 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 Workqueue: netns cleanupnet RIP: 0010:reftrackerdirexit (lib/reftracker.c:179) Code: 00 00 00 fc ff df 4d 8b 26 49 bd 00 01 00 00 00 00 ad de 4c 39 f5 0f 85 df 00 00 00 48 8b 74 24 08 48 89 df e8 a5 cc 12 02 90 <0f> 0b 90 48 8d 6b 44 be 04 00 00 00 48 89 ef e8 80 de 67 ff 48 89 RSP: 0018:ff11000007f3fb60 EFLAGS: 00010286 RAX: 00000000000020ef RBX: ff1100000d6481e0 RCX: 1ffffffff0e40d82 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8423ee3c RBP: ff1100000d648230 R08: 0000000000000001 R09: fffffbfff0e395af R10: 0000000000000001 R11: 0000000000000000 R12: ff1100000d648230 R13: dead000000000100 R14: ff1100000d648230 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ff1100006ce80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005620e1363990 CR3: 000000000eeb2002 CR4: 0000000000771ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? warn (kernel/panic.c:748) ? reftrackerdirexit (lib/reftracker.c:179) ? reportbug (lib/bug.c:201 lib/bug.c:219) ? handlebug (arch/x86/kernel/traps.c:285) ? excinvalidop (arch/x86/kernel/traps.c:309 (discriminator 1)) ? asmexcinvalidop (./arch/x86/include/asm/idtentry.h:621) ? rawspinunlockirqrestore (./arch/x86/include/asm/irqflags.h:42 ./arch/x86/include/asm/irqflags.h:97 ./arch/x86/include/asm/irqflags.h:155 ./include/linux/spinlockapismp.h:151 kernel/locking/spinlock.c:194) ? reftrackerdirexit (lib/reftracker.c:179) ? pfxreftrackerdirexit (lib/reftracker.c:158) ? kfree (mm/slub.c:4613 mm/slub.c:4761) netfree (net/core/netnamespace.c:476 net/core/netnamespace.c:467) cleanupnet (net/cor ---truncated---