In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: fix UaF read in mptcppmnlrmaddrorsubflow
Syzkaller reported this splat:
================================================================== BUG: KASAN: slab-use-after-free in mptcppmnlrmaddrorsubflow+0xb44/0xcc0 net/mptcp/pmnetlink.c:881 Read of size 4 at addr ffff8880569ac858 by task syz.1.2799/14662
CPU: 0 UID: 0 PID: 14662 Comm: syz.1.2799 Not tainted 6.12.0-rc2-syzkaller-00307-g36c254515dc6 #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace: <TASK> dumpstack lib/dumpstack.c:94 [inline] dumpstacklvl+0x116/0x1f0 lib/dumpstack.c:120 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0xc3/0x620 mm/kasan/report.c:488 kasanreport+0xd9/0x110 mm/kasan/report.c:601 mptcppmnlrmaddrorsubflow+0xb44/0xcc0 net/mptcp/pmnetlink.c:881 mptcppmnlrmsubflowreceived net/mptcp/pmnetlink.c:914 [inline] mptcpnlremoveidzeroaddress+0x305/0x4a0 net/mptcp/pmnetlink.c:1572 mptcppmnldeladdrdoit+0x5c9/0x770 net/mptcp/pmnetlink.c:1603 genlfamilyrcvmsgdoit+0x202/0x2f0 net/netlink/genetlink.c:1115 genlfamilyrcvmsg net/netlink/genetlink.c:1195 [inline] genlrcvmsg+0x565/0x800 net/netlink/genetlink.c:1210 netlinkrcvskb+0x165/0x410 net/netlink/afnetlink.c:2551 genlrcv+0x28/0x40 net/netlink/genetlink.c:1219 netlinkunicastkernel net/netlink/afnetlink.c:1331 [inline] netlinkunicast+0x53c/0x7f0 net/netlink/afnetlink.c:1357 netlinksendmsg+0x8b8/0xd70 net/netlink/afnetlink.c:1901 socksendmsgnosec net/socket.c:729 [inline] socksendmsg net/socket.c:744 [inline] syssendmsg+0x9ae/0xb40 net/socket.c:2607 syssendmsg+0x135/0x1e0 net/socket.c:2661 syssendmsg+0x117/0x1f0 net/socket.c:2690 dosyscall32irqson arch/x86/entry/common.c:165 [inline] dofastsyscall32+0x73/0x120 arch/x86/entry/common.c:386 dofastsyscall32+0x32/0x80 arch/x86/entry/common.c:411 entrySYSENTERcompatafterhwframe+0x84/0x8e RIP: 0023:0xf7fe4579 Code: b8 01 10 06 03 74 b4 01 10 07 03 74 b0 01 10 08 03 74 d8 01 00 00 00 00 00 00 00 00 00 00 00 00 00 51 52 55 89 e5 0f 34 cd 80 <5d> 5a 59 c3 90 90 90 90 8d b4 26 00 00 00 00 8d b4 26 00 00 00 00 RSP: 002b:00000000f574556c EFLAGS: 00000296 ORIGRAX: 0000000000000172 RAX: ffffffffffffffda RBX: 000000000000000b RCX: 0000000020000140 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 </TASK>
Allocated by task 5387: kasansavestack+0x33/0x60 mm/kasan/common.c:47 kasansavetrack+0x14/0x30 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:377 [inline] kasankmalloc+0xaa/0xb0 mm/kasan/common.c:394 kmallocnoprof include/linux/slab.h:878 [inline] kzallocnoprof include/linux/slab.h:1014 [inline] subflowcreatectx+0x87/0x2a0 net/mptcp/subflow.c:1803 subflowulpinit+0xc3/0x4d0 net/mptcp/subflow.c:1956 tcpsetulp net/ipv4/tcpulp.c:146 [inline] tcpsetulp+0x326/0x7f0 net/ipv4/tcpulp.c:167 mptcpsubflowcreatesocket+0x4ae/0x10a0 net/mptcp/subflow.c:1764 mptcpsubflowconnect+0x3cc/0x1490 net/mptcp/subflow.c:1592 mptcppmcreatesubfloworsignaladdr+0xbda/0x23a0 net/mptcp/pmnetlink.c:642 mptcppmnlfullyestablished net/mptcp/pmnetlink.c:650 [inline] mptcppmnlwork+0x3a1/0x4f0 net/mptcp/pmnetlink.c:943 mptcpworker+0x15a/0x1240 net/mptcp/protocol.c:2777 processonework+0x958/0x1b30 kernel/workqueue.c:3229 processscheduledworks kernel/workqueue.c:3310 [inline] workerthread+0x6c8/0xf00 kernel/workqueue.c:3391 kthread+0x2c1/0x3a0 kernel/kthread.c:389 retfromfork+0x45/0x80 arch/x86/ke ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix possible double free in smb2setea()
Clang static checker(scan-build) warning： fs/smb/client/smb2ops.c:1304:2: Attempt to free released memory. 1304 | kfree(ea); | ^~~~~~~~~
There is a double free in such case: 'ea is initialized to NULL' -> 'first successful memory allocation for ea' -> 'something failed, goto seaexit' -> 'first memory release for ea' -> 'goto replayagain' -> 'second goto seaexit before allocate memory for ea' -> 'second memory release for ea resulted in double free'.
Re-initialie 'ea' to NULL near to the replayagain label, it can fix this double free problem.
In the Linux kernel, the following vulnerability has been resolved:
tcp/dccp: Don't use timerpending() in reqskqueueunlink().
Martin KaFai Lau reported use-after-free [0] in reqsktimerhandler().
""" We are seeing a use-after-free from a bpf prog attached to tracetcpretransmitsynack. The program passes the req->sk to the bpfskstoragegettracing kernel helper which does check for null before using it. """
The commit 83fccfc3940c ("inet: fix potential deadlock in reqskqueueunlink()") added timerpending() in reqskqueueunlink() not to call deltimersync() from reqsktimerhandler(), but it introduced a small race window.
Before the timer is called, expiretimers() calls detachtimer(timer, true) to clear timer->entry.pprev and marks it as not pending.
If reqskqueueunlink() checks timerpending() just after expiretimers() calls detachtimer(), TCP will miss deltimersync(); the reqsk timer will continue running and send multiple SYN+ACKs until it expires.
The reported UAF could happen if req->sk is close()d earlier than the timer expiration, which is 63s by default.
The scenario would be
1. inetcskcompletehashdance() calls inetcskreqskqueuedrop(), but deltimersync() is missed
2. reqsk timer is executed and scheduled again
3. req->sk is accept()ed and reqskput() decrements rskrefcnt, but reqsk timer still has another one, and inetcskaccept() does not clear req->sk for non-TFO sockets
4. sk is close()d
5. reqsk timer is executed again, and BPF touches req->sk
Let's not use timerpending() by passing the caller context to inetcskreqskqueuedrop().
Note that reqsk timer is pinned, so the issue does not happen in most use cases. [1]
[0] BUG: KFENCE: use-after-free read in bpfskstoragegettracing+0x2e/0x1b0
Use-after-free read at 0x00000000a891fb3a (in kfence-#1): bpfskstoragegettracing+0x2e/0x1b0 bpfprog5ea3e95db6da0438tcpretransmitsynack+0x1d20/0x1dda bpftracerun2+0x4c/0xc0 tcprtxsynack+0xf9/0x100 reqsktimerhandler+0xda/0x3d0 runtimersoftirq+0x292/0x8a0 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 intelidleirq+0x5a/0xa0 cpuidleenterstate+0x94/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb
kfence-#1: 0x00000000a72cc7b6-0x00000000d97616d9, size=2376, cache=TCPv6
allocated by task 0 on cpu 9 at 260507.901592s: skprotalloc+0x35/0x140 skclonelock+0x1f/0x3f0 inetcskclonelock+0x15/0x160 tcpcreateopenreqchild+0x1f/0x410 tcpv6synrecvsock+0x1da/0x700 tcpcheckreq+0x1fb/0x510 tcpv6rcv+0x98b/0x1420 ipv6listrcv+0x2258/0x26e0 napicompletedone+0x5b1/0x2990 mlx5enapipoll+0x2ae/0x8d0 netrxaction+0x13e/0x590 irqexitrcu+0xf5/0x320 commoninterrupt+0x80/0x90 asmcommoninterrupt+0x22/0x40 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb
freed by task 0 on cpu 9 at 260507.927527s: rcucoresi+0x4ff/0xf10 irqexitrcu+0xf5/0x320 sysvecapictimerinterrupt+0x6d/0x80 asmsysvecapictimerinterrupt+0x16/0x20 cpuidleenterstate+0xfb/0x273 cpustartupentry+0x15e/0x260 startsecondary+0x8a/0x90 secondarystartup64noverify+0xfa/0xfb
In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtkethsoc: fix memory corruption during fq dma init
The loop responsible for allocating up to MTKFQDMALENGTH buffers must only touch as many descriptors, otherwise it ends up corrupting unrelated memory. Fix the loop iteration count accordingly.
In the Linux kernel, the following vulnerability has been resolved:
net: vertexcom: mse102x: Fix possible double free of TX skb
The scope of the TX skb is wider than just mse102xtxframespi(), so in case the TX skb room needs to be expanded, we should free the the temporary skb instead of the original skb. Otherwise the original TX skb pointer would be freed again in mse102xtxwork(), which leads to crashes:
Internal error: Oops: 0000000096000004 [#2] PREEMPT SMP CPU: 0 PID: 712 Comm: kworker/0:1 Tainted: G D 6.6.23 Hardware name: chargebyte Charge SOM DC-ONE (DT) Workqueue: events mse102xtxwork [mse102x] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : skbreleasedata+0xb8/0x1d8 lr : skbreleasedata+0x1ac/0x1d8 sp : ffff8000819a3cc0 x29: ffff8000819a3cc0 x28: ffff0000046daa60 x27: ffff0000057f2dc0 x26: ffff000005386c00 x25: 0000000000000002 x24: 00000000ffffffff x23: 0000000000000000 x22: 0000000000000001 x21: ffff0000057f2e50 x20: 0000000000000006 x19: 0000000000000000 x18: ffff00003fdacfcc x17: e69ad452d0c49def x16: 84a005feff870102 x15: 0000000000000000 x14: 000000000000024a x13: 0000000000000002 x12: 0000000000000000 x11: 0000000000000400 x10: 0000000000000930 x9 : ffff00003fd913e8 x8 : fffffc00001bc008 x7 : 0000000000000000 x6 : 0000000000000008 x5 : ffff00003fd91340 x4 : 0000000000000000 x3 : 0000000000000009 x2 : 00000000fffffffe x1 : 0000000000000000 x0 : 0000000000000000 Call trace: skbreleasedata+0xb8/0x1d8 kfreeskbreason+0x48/0xb0 mse102xtxwork+0x164/0x35c [mse102x] processonework+0x138/0x260 workerthread+0x32c/0x438 kthread+0x118/0x11c retfromfork+0x10/0x20 Code: aa1303e0 97fffab6 72001c1f 54000141 (f9400660)
In the Linux kernel, the following vulnerability has been resolved:
RDMA/siw: Add sendpageok() check to disable MSGSPLICEPAGES
While running ISER over SIW, the initiator machine encounters a warning from skbsplicefromiter() indicating that a slab page is being used in sendpage. To address this, it is better to add a sendpageok() check within the driver itself, and if it returns 0, then MSGSPLICEPAGES flag should be disabled before entering the network stack.
A similar issue has been discussed for NVMe in this thread: https://lore.kernel.org/all/20240530142417.146696-1-ofir.gal@volumez.com/
WARNING: CPU: 0 PID: 5342 at net/core/skbuff.c:7140 skbsplicefromiter+0x173/0x320 Call Trace: tcpsendmsglocked+0x368/0xe40 siwtxhdt+0x695/0xa40 [siw] siwqpsqprocess+0x102/0xb00 [siw] siwsqresume+0x39/0x110 [siw] siwrunsq+0x74/0x160 [siw] kthread+0xd2/0x100 retfromfork+0x34/0x40 retfromforkasm+0x1a/0x30
In the Linux kernel, the following vulnerability has been resolved:
smb: client: Fix use-after-free of network namespace.
Recently, we got a customer report that CIFS triggers oops while reconnecting to a server. [0]
The workload runs on Kubernetes, and some pods mount CIFS servers in non-root network namespaces. The problem rarely happened, but it was always while the pod was dying.
The root cause is wrong reference counting for network namespace.
CIFS uses kernel sockets, which do not hold refcnt of the netns that the socket belongs to. That means CIFS must ensure the socket is always freed before its netns; otherwise, use-after-free happens.
The repro steps are roughly:
1. mount CIFS in a non-root netns 2. drop packets from the netns 3. destroy the netns 4. unmount CIFS
We can reproduce the issue quickly with the script [1] below and see the splat [2] if CONFIGNETNSREFCNTTRACKER is enabled.
When the socket is TCP, it is hard to guarantee the netns lifetime without holding refcnt due to async timers.
Let's hold netns refcnt for each socket as done for SMC in commit 9744d2bf1976 ("smc: Fix use-after-free in tcpwritetimerhandler().").
Note that we need to move putnet() from cifsputtcpsession() to cleandemultiplexinfo(); otherwise, sockcreate() still could touch a freed netns while cifsd tries to reconnect from cifsdemultiplexthread().
Also, maybegetnet() cannot be put just before sockcreate() because the code is not under RCU and there is a small chance that the same address happened to be reallocated to another netns.
[0]: CIFS: VFS: \\XXXXXXXXXXX has not responded in 15 seconds. Reconnecting... CIFS: Serverclose failed 4 times, giving up Unable to handle kernel paging request at virtual address 14de99e461f84a07 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 [14de99e461f84a07] address between user and kernel address ranges Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: clsbpf schingress nlsutf8 cifs cifsarc4 cifsmd4 dnsresolver tcpdiag inetdiag veth xtstate xtconnmark nfconntracknetlink xtnat xtstatistic xtMASQUERADE xtmark xtaddrtype iptREJECT nfrejectipv4 nftchainnat nfnat xtconntrack nfconntrack nfdefragipv6 nfdefragipv4 xtcomment nftcompat nftables nfnetlink overlay nlsascii nlscp437 sunrpc vfat fat aesceblk aescecipher ghashce sm4cecipher sm4 sm3ce sm3 sha3ce sha512ce sha512arm64 sha1ce ena button schfqcodel loop fuse configfs dmisysfs sha2ce sha256arm64 dmmirror dmregionhash dmlog dmmod dax efivarfs CPU: 5 PID: 2690970 Comm: cifsd Not tainted 6.1.103-109.184.amzn2023.aarch64 #1 Hardware name: Amazon EC2 r7g.4xlarge/, BIOS 1.0 11/1/2018 pstate: 00400005 (nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : fibruleslookup+0x44/0x238 lr : fiblookup+0x64/0xbc sp : ffff8000265db790 x29: ffff8000265db790 x28: 0000000000000000 x27: 000000000000bd01 x26: 0000000000000000 x25: ffff000b4baf8000 x24: ffff00047b5e4580 x23: ffff8000265db7e0 x22: 0000000000000000 x21: ffff00047b5e4500 x20: ffff0010e3f694f8 x19: 14de99e461f849f7 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 3f92800abd010002 x11: 0000000000000001 x10: ffff0010e3f69420 x9 : ffff800008a6f294 x8 : 0000000000000000 x7 : 0000000000000006 x6 : 0000000000000000 x5 : 0000000000000001 x4 : ffff001924354280 x3 : ffff8000265db7e0 x2 : 0000000000000000 x1 : ffff0010e3f694f8 x0 : ffff00047b5e4500 Call trace: fibruleslookup+0x44/0x238 fiblookup+0x64/0xbc iprouteoutputkeyhashrcu+0x2c4/0x398 iprouteoutputkeyhash+0x60/0x8c tcpv4connect+0x290/0x488 inetstreamconnect+0x108/0x3d0 inetstreamconnect+0x50/0x78 kernelconnect+0x6c/0xac genericipconne ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-use-after-free in ksmbdsmb2sessioncreate
There is a race condition between ksmbdsmb2sessioncreate and ksmbdexpiresession. This patch add missing sessionstablelock while adding/deleting session from global session table.
In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab-use-after-free in smb3preauthhashrsp
ksmbdusersessionput should be called under smb3preauthhashrsp(). It will avoid freeing session before calling smb3preauthhashrsp().
In the Linux kernel, the following vulnerability has been resolved:
firewire: core: fix invalid port index for parent device
In a commit 24b7f8e5cd65 ("firewire: core: use helper functions for self ID sequence"), the enumeration over self ID sequence was refactored with some helper functions with KUnit tests. These helper functions are guaranteed to work expectedly by the KUnit tests, however their application includes a mistake to assign invalid value to the index of port connected to parent device.
This bug affects the case that any extra node devices which has three or more ports are connected to 1394 OHCI controller. In the case, the path to update the tree cache could hits WARNON(), and gets general protection fault due to the access to invalid address computed by the invalid value.
This commit fixes the bug to assign correct port index.
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:
vmxnet3: Fix packet corruption in vmxnet3xdpxmitframe
Andrew and Nikolay reported connectivity issues with Cilium's service load-balancing in case of vmxnet3.
If a BPF program for native XDP adds an encapsulation header such as IPIP and transmits the packet out the same interface, then in case of vmxnet3 a corrupted packet is being sent and subsequently dropped on the path.
vmxnet3xdpxmitframe() which is called e.g. via vmxnet3runxdp() through vmxnet3xdpxmitback() calculates an incorrect DMA address:
page = virttopage(xdpf->data); tbi->dmaaddr = pagepoolgetdmaaddr(page) + VMXNET3XDPHEADROOM; dmasyncsinglefordevice(&adapter->pdev->dev, tbi->dmaaddr, bufsize, DMATODEVICE);
The above assumes a fixed offset (VMXNET3XDPHEADROOM), but the XDP BPF program could have moved xdp->data. While the passed bufsize is correct (xdpf->len), the dmaaddr needs to have a dynamic offset which can be calculated as xdpf->data - (void )xdpf, that is, xdp->data - xdp->datahardstart.
bpf: Fix overloading of MEMUNINIT's meaning
In the Linux kernel, the following vulnerability has been resolved:
RDMA/bnxtre: Fix a bug while setting up Level-2 PBL pages
Avoid memory corruption while setting up Level-2 PBL pages for the non MR resources when numpages > 256K.
There will be a single PDE page address (contiguous pages in the case of > PAGESIZE), but, current logic assumes multiple pages, leading to invalid memory access after 256K PBL entries in the PDE.
In the Linux kernel, the following vulnerability has been resolved:
virtionet: Add hashkeylength check
Add hashkeylength check in virtnetprobe() to avoid possible out of bound errors when setting/reading the hash key.
In the Linux kernel, the following vulnerability has been resolved:
virtiopci: Fix admin vq cleanup by using correct info pointer
vpmodernavqcleanup() and vpdelvqs() clean up admin vq resources by virtiopcivqinfo pointer. The info pointer of admin vq is stored in vpdev->adminvq.info instead of vpdev->vqs[]. Using the info pointer from vpdev->vqs[] for admin vq causes a kernel NULL pointer dereference bug. In vpmodernavqcleanup() and vpdelvqs(), get the info pointer from vpdev->adminvq.info for admin vq to clean up the resources. Also make info ptr as argument of vpdelvq() to be symmetric with vpsetupvq().
vpreset calls vpmodernavqcleanup, and causes the Call Trace: ================================================================== BUG: kernel NULL pointer dereference, address:0000000000000000 ... CPU: 49 UID: 0 PID: 4439 Comm: modprobe Not tainted 6.11.0-rc5 #1 RIP: 0010:vpreset+0x57/0x90 [virtiopci] Call Trace: <TASK> ... ? vpreset+0x57/0x90 [virtiopci] ? vpreset+0x38/0x90 [virtiopci] virtioresetdevice+0x1d/0x30 removevqcommon+0x1c/0x1a0 [virtionet] virtnetremove+0xa1/0xc0 [virtionet] virtiodevremove+0x46/0xa0 ... virtiopcidriverexit+0x14/0x810 [virtiopci] ==================================================================
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:
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:
net/mlx5e: CT: Fix null-ptr-deref in add rule err flow
In error flow of mlx5tcctentryaddrule(), in case ctruleadd() callback returns error, zonerule->attr is used uninitiated. Fix it to use attr which has the needed pointer value.
Kernel log: BUG: kernel NULL pointer dereference, address: 0000000000000110 RIP: 0010:mlx5tcctentryaddrule+0x2b1/0x2f0 [mlx5core] … Call Trace: <TASK> ? die+0x20/0x70 ? pagefaultoops+0x150/0x3e0 ? excpagefault+0x74/0x140 ? asmexcpagefault+0x22/0x30 ? mlx5tcctentryaddrule+0x2b1/0x2f0 [mlx5core] ? mlx5tcctentryaddrule+0x1d5/0x2f0 [mlx5core] mlx5tcctblockflowoffload+0xc6a/0xf90 [mlx5core] ? nfflowoffloadtuple+0xd8/0x190 [nfflowtable] nfflowoffloadtuple+0xd8/0x190 [nfflowtable] flowoffloadworkhandler+0x142/0x320 [nfflowtable] ? finishtaskswitch.isra.0+0x15b/0x2b0 processonework+0x16c/0x320 workerthread+0x28c/0x3a0 ? pfxworkerthread+0x10/0x10 kthread+0xb8/0xf0 ? pfxkthread+0x10/0x10 retfromfork+0x2d/0x50 ? pfxkthread+0x10/0x10 retfromforkasm+0x1a/0x30 </TASK>
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
In the Linux kernel, the following vulnerability has been resolved:
nvmet-auth: assign dhkey to NULL after kfreesensitive
ctrl->dhkey might be used across multiple calls to nvmetsetupdhgroup() for the same controller. So it's better to nullify it after release on error path in order to avoid double free later in nvmetdestroyauth().
Found by Linux Verification Center (linuxtesting.org) with Svace.
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: ISO: Fix UAF on isosocktimeout
conn->sk maybe have been unlinked/freed while waiting for isoconnlock so this checks if the conn->sk is still valid by checking if it part of isosklist.
In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: Fix shift-out-of-bounds bug
Fix a shift-out-of-bounds bug reported by UBSAN when running VM with MTE enabled host kernel.
UBSAN: shift-out-of-bounds in arch/arm64/kvm/sysregs.c:1988:14 shift exponent 33 is too large for 32-bit type 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dumpbacktrace+0xa0/0x128 showstack+0x20/0x38 dumpstacklvl+0x74/0x90 dumpstack+0x18/0x28 ubsanhandleshiftoutofbounds+0xf8/0x1e0 resetclidr+0x10c/0x1c8 kvmresetsysregs+0x50/0x1c8 kvmresetvcpu+0xec/0x2b0 kvmvcpusettarget+0x84/0x158 kvmvcpusettarget+0x138/0x168 kvmarchvcpuioctlvcpuinit+0x40/0x2b0 kvmarchvcpuioctl+0x28c/0x4b8 kvmvcpuioctl+0x4bc/0x7a8 arm64sysioctl+0xb4/0x100 invokesyscall+0x70/0x100 el0svccommon.constprop.0+0x48/0xf0 doel0svc+0x24/0x38 el0svc+0x3c/0x158 el0t64synchandler+0x120/0x130 el0t64sync+0x194/0x198
In the Linux kernel, the following vulnerability has been resolved:
mm/mremap: fix movenormalpmd/retractpagetables race
In mremap(), movepagetables() looks at the type of the PMD entry and the specified address range to figure out by which method the next chunk of page table entries should be moved.
At that point, the mmaplock is held in write mode, but no rmap locks are held yet. For PMD entries that point to page tables and are fully covered by the source address range, movepgtentry(NORMALPMD, ...) is called, which first takes rmap locks, then does movenormalpmd(). movenormalpmd() takes the necessary page table locks at source and destination, then moves an entire page table from the source to the destination.
The problem is: The rmap locks, which protect against concurrent page table removal by retractpagetables() in the THP code, are only taken after the PMD entry has been read and it has been decided how to move it. So we can race as follows (with two processes that have mappings of the same tmpfs file that is stored on a tmpfs mount with huge=advise); note that process A accesses page tables through the MM while process B does it through the file rmap:
process A process B ========= ========= mremap mremapto movevma movepagetables getoldpmd allocnewpmd PREEMPT madvise(MADVCOLLAPSE) domadvise madvisewalkvmas madvisevmabehavior madvisecollapse hpagecollapsescanfile collapsefile retractpagetables immaplockread(mapping) pmdpcollapseflush immapunlockread(mapping) movepgtentry(NORMALPMD, ...) takermaplocks movenormalpmd droprmaplocks
When this happens, movenormalpmd() can end up creating bogus PMD entries in the line pmdpopulate(mm, newpmd, pmdpgtable(pmd)). The effect depends on arch-specific and machine-specific details; on x86, you can end up with physical page 0 mapped as a page table, which is likely exploitable for user->kernel privilege escalation.
Fix the race by letting process B recheck that the PMD still points to a page table after the rmap locks have been taken. Otherwise, we bail and let the caller fall back to the PTE-level copying path, which will then bail immediately at the pmdnone() check.
Bug reachability: Reaching this bug requires that you can create shmem/file THP mappings - anonymous THP uses different code that doesn't zap stuff under rmap locks. File THP is gated on an experimental config flag (CONFIGREADONLYTHPFORFS), so on normal distro kernels you need shmem THP to hit this bug. As far as I know, getting shmem THP normally requires that you can mount your own tmpfs with the right mount flags, which would require creating your own user+mount namespace; though I don't know if some distros maybe enable shmem THP by default or something like that.
Bug impact: This issue can likely be used for user->kernel privilege escalation when it is reachable.
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:
parport: Proper fix for array out-of-bounds access
The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf(). However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit.
Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix uninitialized pointer free on readalloconename() error
The function readalloconename() does not initialize the name field of the passed fscryptstr struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscryptstr.name is initialized when freeing it.
This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 ("btrfs: use struct qstr instead of name and namelen pairs").
In the Linux kernel, the following vulnerability has been resolved:
net: microchip: vcap api: Fix memory leaks in vcapapiencoderuletest()
Commit a3c1e45156ad ("net: microchip: vcap: Fix use-after-free error in kunit test") fixed the use-after-free error, but introduced below memory leaks by removing necessary vcapfreerule(), add it to fix it.
unreferenced object 0xffffff80ca58b700 (size 192): comm "kunittrycatch", pid 1215, jiffies 4294898264 hex dump (first 32 bytes): 00 12 7a 00 05 00 00 00 0a 00 00 00 64 00 00 00 ..z.........d... 00 00 00 00 00 00 00 00 00 04 0b cc 80 ff ff ff ................ backtrace (crc 9c09c3fe): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] kmalloccachenoprof+0x26c/0x2f4 [<0000000040a01b8d>] vcapallocrule+0x3cc/0x9c4 [<000000003fe86110>] vcapapiencoderuletest+0x1ac/0x16b0 [<00000000b3595fc4>] kunittryruncase+0x13c/0x3ac [<0000000010f5d2bf>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] retfromfork+0x10/0x20 unreferenced object 0xffffff80cc0b0400 (size 64): comm "kunittrycatch", pid 1215, jiffies 4294898265 hex dump (first 32 bytes): 80 04 0b cc 80 ff ff ff 18 b7 58 ca 80 ff ff ff ..........X..... 39 00 00 00 02 00 00 00 06 05 04 03 02 01 ff ff 9............... backtrace (crc daf014e9): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] kmalloccachenoprof+0x26c/0x2f4 [<000000000ff63fd4>] vcapruleaddkey+0x2cc/0x528 [<00000000dfdb1e81>] vcapapiencoderuletest+0x224/0x16b0 [<00000000b3595fc4>] kunittryruncase+0x13c/0x3ac [<0000000010f5d2bf>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] retfromfork+0x10/0x20 unreferenced object 0xffffff80cc0b0700 (size 64): comm "kunittrycatch", pid 1215, jiffies 4294898265 hex dump (first 32 bytes): 80 07 0b cc 80 ff ff ff 28 b7 58 ca 80 ff ff ff ........(.X..... 3c 00 00 00 00 00 00 00 01 2f 03 b3 ec ff ff ff <......../...... backtrace (crc 8d877792): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] kmalloccachenoprof+0x26c/0x2f4 [<000000006eadfab7>] vcapruleaddaction+0x2d0/0x52c [<00000000323475d1>] vcapapiencoderuletest+0x4d4/0x16b0 [<00000000b3595fc4>] kunittryruncase+0x13c/0x3ac [<0000000010f5d2bf>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] retfromfork+0x10/0x20 unreferenced object 0xffffff80cc0b0900 (size 64): comm "kunittrycatch", pid 1215, jiffies 4294898266 hex dump (first 32 bytes): 80 09 0b cc 80 ff ff ff 80 06 0b cc 80 ff ff ff ................ 7d 00 00 00 01 00 00 00 00 00 00 00 ff 00 00 00 }............... backtrace (crc 34181e56): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] kmalloccachenoprof+0x26c/0x2f4 [<000000000ff63fd4>] vcapruleaddkey+0x2cc/0x528 [<00000000991e3564>] vcapvalrule+0xcf0/0x13e8 [<00000000fc9868e5>] vcapapiencoderuletest+0x678/0x16b0 [<00000000b3595fc4>] kunittryruncase+0x13c/0x3ac [<0000000010f5d2bf>] kunitgenericrunthreadfnadapter+0x80/0xec [<00000000c5d82c9a>] kthread+0x2e8/0x374 [<00000000f4287308>] retfromfork+0x10/0x20 unreferenced object 0xffffff80cc0b0980 (size 64): comm "kunittrycatch", pid 1215, jiffies 4294898266 hex dump (first 32 bytes): 18 b7 58 ca 80 ff ff ff 00 09 0b cc 80 ff ff ff ..X............. 67 00 00 00 00 00 00 00 01 01 74 88 c0 ff ff ff g.........t..... backtrace (crc 275fd9be): [<0000000052a0be73>] kmemleakalloc+0x34/0x40 [<0000000043605459>] kmalloccachenoprof+0x26c/0x2f4 [<000000000ff63fd4>] vcapruleaddkey+0x2cc/0x528 [<000000001396a1a2>] testaddde ---truncated---
btrfs: fix uninitialized pointer free in addinoderef()
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: nuvoton: fix a double free in ma35pinctrldtnodetomapfunc()
'newmap' is allocated using devm which takes care of freeing the allocated data on device removal, call to
.dtfreemap = pinconfgenericdtfreemap
double frees the map as pinconfgenericdtfreemap() calls pinctrlutilsfreemap().
Fix this by using kcalloc() instead of auto-managed devmkcalloc().