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

RDMA/hns: Fix NULL pointer problem in freemrinit()

Lock grab occurs in a concurrent scenario, resulting in stepping on a NULL pointer. It should be init mutexinit() first before use the lock.

Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: mutexlock.constprop.0+0xd0/0x5c0 mutexlockslowpath+0x1c/0x2c mutexlock+0x44/0x50 freemrsendcmdtohw+0x7c/0x1c0 [hnsrocehwv2] hnsrocev2deregmr+0x30/0x40 [hnsrocehwv2] hnsrocederegmr+0x4c/0x130 [hnsrocehwv2] ibderegmruser+0x54/0x124 uverbsfreemr+0x24/0x30 destroyhwidruobject+0x38/0x74 uverbsdestroyuobject+0x48/0x1c4 uobjdestroy+0x74/0xcc ibuverbscmdverbs+0x368/0xbb0 ibuverbsioctl+0xec/0x1a4 arm64sysioctl+0xb4/0x100 invokesyscall+0x50/0x120 el0svccommon.constprop.0+0x58/0x190 doel0svc+0x30/0x90 el0svc+0x2c/0xb4 el0t64synchandler+0x1a4/0x1b0 el0t64sync+0x19c/0x1a0

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

RDMA/rxe: Fix mr leak in RESPSTERRRNR

rxerecheckmr() will increase mr's refcnt, so we should call rxeput(mr) to drop mr's refcnt in RESPSTERRRNR to avoid below warning:

WARNING: CPU: 0 PID: 4156 at drivers/infiniband/sw/rxe/rxepool.c:259 rxecleanup+0x1df/0x240 [rdmarxe] ... Call Trace: rxederegmr+0x4c/0x60 [rdmarxe] ibderegmruser+0xa8/0x200 [ibcore] ibmrpooldestroy+0x77/0xb0 [ibcore] nvmerdmadestroyqueueib+0x89/0x240 [nvmerdma] nvmerdmafreequeue+0x40/0x50 [nvmerdma] nvmerdmateardownioqueues.part.0+0xc3/0x120 [nvmerdma] nvmerdmaerrorrecoverywork+0x4d/0xf0 [nvmerdma] processonework+0x582/0xa40 ? pwqdecnrinflight+0x100/0x100 ? rwlockbug.part.0+0x60/0x60 workerthread+0x2a9/0x700 ? processonework+0xa40/0xa40 kthread+0x168/0x1a0 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x22/0x30

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

nfs4: Fix kmemleak when allocate slot failed

If one of the slot allocate failed, should cleanup all the other allocated slots, otherwise, the allocated slots will leak:

unreferenced object 0xffff8881115aa100 (size 64): comm ""mount.nfs"", pid 679, jiffies 4294744957 (age 115.037s) hex dump (first 32 bytes): 00 cc 19 73 81 88 ff ff 00 a0 5a 11 81 88 ff ff ...s......Z..... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<000000007a4c434a>] nfs4findorcreateslot+0x8e/0x130 [<000000005472a39c>] nfs4reallocslottable+0x23f/0x270 [<00000000cd8ca0eb>] nfs40initclient+0x4a/0x90 [<00000000128486db>] nfs4initclient+0xce/0x270 [<000000008d2cacad>] nfs4setclient+0x1a2/0x2b0 [<000000000e593b52>] nfs4createserver+0x300/0x5f0 [<00000000e4425dd2>] nfs4trygettree+0x65/0x110 [<00000000d3a6176f>] vfsgettree+0x41/0xf0 [<0000000016b5ad4c>] pathmount+0x9b3/0xdd0 [<00000000494cae71>] x64sysmount+0x190/0x1d0 [<000000005d56bdec>] dosyscall64+0x35/0x80 [<00000000687c9ae4>] entrySYSCALL64afterhwframe+0x46/0xb0

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

net: dsa: Fix possible memory leaks in dsaloopinit()

kmemleak reported memory leaks in dsaloopinit():

kmemleak: 12 new suspected memory leaks

unreferenced object 0xffff8880138ce000 (size 2048): comm "modprobe", pid 390, jiffies 4295040478 (age 238.976s) backtrace: [<000000006a94f1d5>] kmalloctrace+0x26/0x60 [<00000000a9c44622>] phydevicecreate+0x5d/0x970 [<00000000d0ee2afc>] getphydevice+0xf3/0x2b0 [<00000000dca0c71f>] fixedphyregister.part.0+0x92/0x4e0 [<000000008a834798>] fixedphyregister+0x84/0xb0 [<0000000055223fcb>] dsaloopinit+0xa9/0x116 [dsaloop] ...

There are two reasons for memleak in dsaloopinit().

First, fixedphyregister() create and register phydevice:

fixedphyregister() getphydevice() phydevicecreate() # freed by phydevicefree() phydeviceregister() # freed by phydeviceremove()

But fixedphyunregister() only calls phydeviceremove(). So the memory allocated in phydevicecreate() is leaked.

Second, when mdiodriverregister() fail in dsaloopinit(), it just returns and there is no cleanup for phydevs.

Fix the problems by catching the error of mdiodriverregister() in dsaloopinit(), then calling both fixedphyunregister() and phydevicefree() to release phydevs. Also add a function for phydevs cleanup to avoid duplacate.

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

nfc: fdp: Fix potential memory leak in fdpncisend()

fdpncisend() will call fdpncii2cwrite that will not free skb in the function. As a result, when fdpncii2cwrite() finished, the skb will memleak. fdpncisend() should free skb after fdpncii2cwrite() finished.

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

RDMA/core: Fix null-ptr-deref in ibcorecleanup()

KASAN reported a null-ptr-deref error:

KASAN: null-ptr-deref in range [0x0000000000000118-0x000000000000011f] CPU: 1 PID: 379 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:destroyworkqueue+0x2f/0x740 RSP: 0018:ffff888016137df8 EFLAGS: 00000202 ... Call Trace: ibcorecleanup+0xa/0xa1 [ibcore] dosysdeletemodule.constprop.0+0x34f/0x5b0 dosyscall64+0x3a/0x90 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7fa1a0d221b7 ...

It is because the fail of rocegidmgmtinit() is ignored:

ibcoreinit() rocegidmgmtinit() gidcachewq = allocorderedworkqueue # fail ... ibcorecleanup() rocegidmgmtcleanup() destroyworkqueue(gidcachewq) # destroy an unallocated wq

Fix this by catching the fail of rocegidmgmtinit() in ibcoreinit().

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

nfc: nxp-nci: Fix potential memory leak in nxpncisend()

nxpncisend() will call nxpncii2cwrite(), and only free skb when nxpncii2cwrite() failed. However, even if the nxpncii2cwrite() run succeeds, the skb will not be freed in nxpncii2cwrite(). As the result, the skb will memleak. nxpncisend() should also free the skb when nxpncii2cwrite() succeeds.

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

nfc: nfcmrvl: Fix potential memory leak in nfcmrvli2cncisend()

nfcmrvli2cncisend() will be called by nfcmrvlncisend(), and skb should be freed in nfcmrvli2cncisend(). However, nfcmrvlncisend() will only free skb when i2cmastersend() return >=0, which means skb will memleak when i2cmastersend() failed. Free skb no matter whether i2cmastersend() succeeds.

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

ipvs: fix WARNING in ipvscleanupbatch()

During the initialization of ipvsconnnetinit(), if file ipvsconn or ipvsconnsync fails to be created, the initialization is successful by default. Therefore, the ipvsconn or ipvsconnsync file doesn't be found during the remove.

The following is the stack information: name 'ipvsconnsync' WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712 removeprocentry+0x389/0x460 Modules linked in: Workqueue: netns cleanupnet RIP: 0010:removeprocentry+0x389/0x460 Call Trace: <TASK> ipvscleanupbatch+0x7d/0x120 opsexitlist+0x125/0x170 cleanupnet+0x4ea/0xb00 processonework+0x9bf/0x1710 workerthread+0x665/0x1080 kthread+0x2e4/0x3a0 retfromfork+0x1f/0x30 </TASK>

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

rose: Fix NULL pointer dereference in rosesendframe()

The syzkaller reported an issue:

KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387] CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: rcugp srcuinvokecallbacks RIP: 0010:rosesendframe+0x1dd/0x2f0 net/rose/roselink.c:101 Call Trace: <IRQ> rosetransmitclearrequest+0x1d5/0x290 net/rose/roselink.c:255 roserxcallrequest+0x4c0/0x1bc0 net/rose/afrose.c:1009 roseloopbacktimer+0x19e/0x590 net/rose/roseloopback.c:111 calltimerfn+0x1a0/0x6b0 kernel/time/timer.c:1474 expiretimers kernel/time/timer.c:1519 [inline] runtimers.part.0+0x674/0xa80 kernel/time/timer.c:1790 runtimers kernel/time/timer.c:1768 [inline] runtimersoftirq+0xb3/0x1d0 kernel/time/timer.c:1803 dosoftirq+0x1d0/0x9c8 kernel/softirq.c:571 [...] </IRQ>

It triggers NULL pointer dereference when 'neigh->dev->devaddr' is called in the rosesendframe(). It's the first occurrence of the neigh is in roseloopbacktimer() as roseloopbackneigh', and the 'dev' in 'roseloopbackneigh' is initialized sa nullptr.

It had been fixed by commit 3b3fd068c56e3fbea30090859216a368398e39bf ("rose: Fix Null pointer dereference in rosesendframe()") ever. But it's introduced by commit 3c53cd65dece47dd1f9d3a809f32e59d1d87b2b8 ("rose: check NULL roseloopbackneigh->loopback") again.

We fix it by add NULL check in rosetransmitclearrequest(). When the 'dev' in 'neigh' is NULL, we don't reply the request and just clear it.

syzkaller don't provide repro, and I provide a syz repro like: r0 = syzinitnetsocket$btsco(0x1f, 0x5, 0x2) ioctl$sockinetSIOCSIFFLAGS(r0, 0x8914, &(0x7f0000000180)={'rose0\x00', 0x201}) r1 = syzinitnetsocket$rose(0xb, 0x5, 0x0) bind$rose(r1, &(0x7f00000000c0)=@full={0xb, @dev, @null, 0x0, [@null, @null, @netrom, @netrom, @default, @null]}, 0x40) connect$rose(r1, &(0x7f0000000240)=@short={0xb, @dev={0xbb, 0xbb, 0xbb, 0x1, 0x0}, @remote={0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0xcc, 0x1}, 0x1, @netrom={0xbb, 0xbb, 0xbb, 0xbb, 0xbb, 0x0, 0x0}}, 0x1c)

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

mISDN: fix possible memory leak in mISDNregisterdevice()

Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's busid string array"), the name of device is allocated dynamically, add putdevice() to give up the reference, so that the name can be freed in kobjectcleanup() when the refcount is 0.

Set device class before putdevice() to avoid null release() function WARN message in devicerelease().

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

btrfs: fix inode list leak during backref walking at resolveindirectrefs()

During backref walking, at resolveindirectrefs(), if we get an error we jump to the 'out' label and call ulistfree() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the unodes.

Fix this by calling freeleaflist() instead of ulistfree() when we exit from resolveindirectrefs(). The static function freeleaflist() is moved up for this to be possible and it's slightly simplified by removing unnecessary code.

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

btrfs: fix ulist leaks in error paths of qgroup self tests

In the testnosharedqgroup() and testmultiplerefs() qgroup self tests, if we fail to add the tree ref, remove the extent item or remove the extent ref, we are returning from the test function without freeing the "oldroots" ulist that was allocated by the previous calls to btrfsfindallroots(). Fix that by calling ulistfree() before returning.

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

btrfs: fix inode list leak during backref walking at findparentnodes()

During backref walking, at findparentnodes(), if we are dealing with a data extent and we get an error while resolving the indirect backrefs, at resolveindirectrefs(), or in the while loop that iterates over the refs in the direct refs rbtree, we end up leaking the inode lists attached to the direct refs we have in the direct refs rbtree that were not yet added to the refs ulist passed as argument to findparentnodes(). Since they were not yet added to the refs ulist and prelimrelease() does not free the lists, on error the caller can only free the lists attached to the refs that were added to the refs ulist, all the remaining refs get their inode lists never freed, therefore leaking their memory.

Fix this by having prelimrelease() always free any attached inode list to each ref found in the rbtree, and have findparentnodes() set the ref's inode list to NULL once it transfers ownership of the inode list to a ref added to the refs ulist passed to findparentnodes().

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

netfilter: ipset: enforce documented limit to prevent allocating huge memory

Daniel Xu reported that the hash:net,iface type of the ipset subsystem does not limit adding the same network with different interfaces to a set, which can lead to huge memory usage or allocation failure.

The quick reproducer is

$ ipset create ACL.IN.ALLPERMIT hash:net,iface hashsize 1048576 timeout 0 $ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALLPERMIT 0.0.0.0/0,kaf$i timeout 0 -exist; done

The backtrace when vmalloc fails:

[Tue Oct 25 00:13:08 2022] ipset: vmalloc error: size 1073741848, exceeds total pages <...> [Tue Oct 25 00:13:08 2022] Call Trace: [Tue Oct 25 00:13:08 2022] <TASK> [Tue Oct 25 00:13:08 2022] dumpstacklvl+0x48/0x60 [Tue Oct 25 00:13:08 2022] warnalloc+0x155/0x180 [Tue Oct 25 00:13:08 2022] vmallocnoderange+0x72a/0x760 [Tue Oct 25 00:13:08 2022] ? hashnetiface4add+0x7c0/0xb20 [Tue Oct 25 00:13:08 2022] ? kmalloclargenode+0x4a/0x90 [Tue Oct 25 00:13:08 2022] kvmallocnode+0xa6/0xd0 [Tue Oct 25 00:13:08 2022] ? hashnetiface4resize+0x99/0x710 <...>

The fix is to enforce the limit documented in the ipset(8) manpage:

The internal restriction of the hash:net,iface set type is that the same network prefix cannot be stored with more than 64 different interfaces in a single set.

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

Bluetooth: L2CAP: Fix memory leak in vhciwrite

Syzkaller reports a memory leak as follows: ==================================== BUG: memory leak unreferenced object 0xffff88810d81ac00 (size 240): [...] hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff838733d9>] allocskb+0x1f9/0x270 net/core/skbuff.c:418 [<ffffffff833f742f>] allocskb include/linux/skbuff.h:1257 [inline] [<ffffffff833f742f>] btskballoc include/net/bluetooth/bluetooth.h:469 [inline] [<ffffffff833f742f>] vhcigetuser drivers/bluetooth/hcivhci.c:391 [inline] [<ffffffff833f742f>] vhciwrite+0x5f/0x230 drivers/bluetooth/hcivhci.c:511 [<ffffffff815e398d>] callwriteiter include/linux/fs.h:2192 [inline] [<ffffffff815e398d>] newsyncwrite fs/readwrite.c:491 [inline] [<ffffffff815e398d>] vfswrite+0x42d/0x540 fs/readwrite.c:578 [<ffffffff815e3cdd>] ksyswrite+0x9d/0x160 fs/readwrite.c:631 [<ffffffff845e0645>] dosyscallx64 arch/x86/entry/common.c:50 [inline] [<ffffffff845e0645>] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 [<ffffffff84600087>] entrySYSCALL64afterhwframe+0x63/0xcd ====================================

HCI core will uses hcirxwork() to process frame, which is queued to the hdev->rxq tail in hcirecvframe() by HCI driver.

Yet the problem is that, HCI core may not free the skb after handling ACL data packets. To be more specific, when start fragment does not contain the L2CAP length, HCI core just copies skb into conn->rxskb and finishes frame process in l2caprecvacldata(), without freeing the skb, which triggers the above memory leak.

This patch solves it by releasing the relative skb, after processing the above case in l2caprecvacldata().

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

ibmvnic: Free rwi on reset success

Free the rwi structure in the event that the last rwi in the list processed successfully. The logic in commit 4f408e1fa6e1 ("ibmvnic: retry reset if there are no other resets") introduces an issue that results in a 32 byte memory leak whenever the last rwi in the list gets processed.

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

net, neigh: Fix null-ptr-deref in neightableclear()

When IPv6 module gets initialized but hits an error in the middle, kenel panic with:

KASAN: null-ptr-deref in range [0x0000000000000598-0x000000000000059f] CPU: 1 PID: 361 Comm: insmod Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) RIP: 0010:neighifdown.isra.0+0x24b/0x370 RSP: 0018:ffff888012677908 EFLAGS: 00000202 ... Call Trace: <TASK> neightableclear+0x94/0x2d0 ndisccleanup+0x27/0x40 [ipv6] inet6init+0x21c/0x2cb [ipv6] dooneinitcall+0xd3/0x4d0 doinitmodule+0x1ae/0x670 ... Kernel panic - not syncing: Fatal exception

When ipv6 initialization fails, it will try to cleanup and calls:

neightableclear() neighifdown(tbl, NULL) pneighqueuepurge(&tbl->proxyqueue, devnet(dev == NULL)) # devnet(NULL) triggers null-ptr-deref.

Fix it by passing NULL to pneighqueuepurge() in neighifdown() if dev is NULL, to make kernel not panic immediately.

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

ipv6: fix WARNING in ip6routenetexitlate()

During the initialization of ip6routenetinitlate(), if file ipv6route or rt6stats fails to be created, the initialization is successful by default. Therefore, the ipv6route or rt6stats file doesn't be found during the remove in ip6routenetexitlate(). It will cause WRNING.

The following is the stack information: name 'rt6stats' WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 removeprocentry+0x389/0x460 Modules linked in: Workqueue: netns cleanupnet RIP: 0010:removeprocentry+0x389/0x460 PKRU: 55555554 Call Trace: <TASK> opsexitlist+0xb0/0x170 cleanupnet+0x4ea/0xb00 processonework+0x9bf/0x1710 workerthread+0x665/0x1080 kthread+0x2e4/0x3a0 retfromfork+0x1f/0x30 </TASK>

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

block: Fix possible memory leak for rqwb on adddisk failure

kmemleak reported memory leaks in deviceadddisk():

kmemleak: 3 new suspected memory leaks

unreferenced object 0xffff88800f420800 (size 512): comm "modprobe", pid 4275, jiffies 4295639067 (age 223.512s) hex dump (first 32 bytes): 04 00 00 00 08 00 00 00 01 00 00 00 00 00 00 00 ................ 00 e1 f5 05 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000d3662699>] kmalloctrace+0x26/0x60 [<00000000edc7aadc>] wbtinit+0x50/0x6f0 [<0000000069601d16>] wbtenabledefault+0x157/0x1c0 [<0000000028fc393f>] blkregisterqueue+0x2a4/0x420 [<000000007345a042>] deviceadddisk+0x6fd/0xe40 [<0000000060e6aab0>] nbddevadd+0x828/0xbf0 [nbd] ...

It is because the memory allocated in wbtenabledefault() is not released in deviceadddisk() error path. Normally, these memory are freed in:

delgendisk() rqqosexit() rqos->ops->exit(rqos); wbtexit()

So rqqosexit() is called to free the rqwb memory for wbtinit(). However in the error path of deviceadddisk(), only blkunregisterqueue() is called and make rqwb memory leaked.

Add rqqosexit() to the error path to fix it.

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

blk-mq: Fix kmemleak in blkmqinitallocatedqueue

There is a kmemleak caused by modprobe nullblk.ko

unreferenced object 0xffff8881acb1f000 (size 1024): comm "modprobe", pid 836, jiffies 4294971190 (age 27.068s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 .....N.......... ff ff ff ff ff ff ff ff 00 53 99 9e ff ff ff ff .........S...... backtrace: [<000000004a10c249>] kmallocnodetrace+0x22/0x60 [<00000000648f7950>] blkmqallocandinithctx+0x289/0x350 [<00000000af06de0e>] blkmqreallochwctxs+0x2fe/0x3d0 [<00000000e00c1872>] blkmqinitallocatedqueue+0x48c/0x1440 [<00000000d16b4e68>] blkmqallocdisk+0xc8/0x1c0 [<00000000d10c98c3>] 0xffffffffc450d69d [<00000000b9299f48>] 0xffffffffc4538392 [<0000000061c39ed6>] dooneinitcall+0xd0/0x4f0 [<00000000b389383b>] doinitmodule+0x1a4/0x680 [<0000000087cf3542>] loadmodule+0x6249/0x7110 [<00000000beba61b8>] dosysfinitmodule+0x140/0x200 [<00000000fdcfff51>] dosyscall64+0x35/0x80 [<000000003c0f1f71>] entrySYSCALL64afterhwframe+0x46/0xb0

That is because q->maops is set to NULL before blkreleasequeue is called.

blkmqinitqueuedata blkmqinitallocatedqueue blkmqreallochwctxs for (i = 0; i < set->nrhwqueues; i++) { oldhctx = xaload(&q->hctxtable, i); if (!blkmqallocandinithctx(.., i, ..)) [1] if (!oldhctx) break;

xaforeachstart(&q->hctxtable, j, hctx, j) blkmqexithctx(q, set, hctx, j); [2]

if (!q->nrhwqueues) [3] goto errhctxs;

errexit: q->mqops = NULL; [4]

blkputqueue blkreleasequeue if (queueismq(q)) [5] blkmqrelease(q);

[1]: blkmqallocandinithctx failed at i != 0. [2]: The hctxs allocated by [1] are moved to q->unusedhctxlist and will be cleaned up in blkmqrelease. [3]: q->nrhwqueues is 0. [4]: Set q->mqops to NULL. [5]: queueismq returns false due to [4]. And blkmqrelease will not be called. The hctxs in q->unusedhctxlist are leaked.

To fix it, call blkreleasequeue in exception path.

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

cxl/pmem: Fix cxlpmemregion and cxlmemdev leak

When a cxlnvdimm object goes through a ->remove() event (device physically removed, nvdimm-bridge disabled, or nvdimm device disabled), then any associated regions must also be disabled. As highlighted by the cxl-create-region.sh test [1], a single device may host multiple regions, but the driver was only tracking one region at a time. This leads to a situation where only the last enabled region per nvdimm device is cleaned up properly. Other regions are leaked, and this also causes cxlmemdev reference leaks.

Fix the tracking by allowing cxlnvdimm objects to track multiple region associations.

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

cxl/region: Fix region HPA ordering validation

Some regions may not have any address space allocated. Skip them when validating HPA order otherwise a crash like the following may result:

devmcxladdregion: cxlacpi cxlacpi.0: decoder3.4: created region9 BUG: kernel NULL pointer dereference, address: 0000000000000000 [..] RIP: 0010:storetargetN+0x655/0x1740 [cxlcore] [..] Call Trace: <TASK> kernfsfopwriteiter+0x144/0x200 vfswrite+0x24a/0x4d0 ksyswrite+0x69/0xf0 dosyscall64+0x3a/0x90

storetargetN+0x655/0x1740: allocregionref at drivers/cxl/core/region.c:676 (inlined by) cxlportattachregion at drivers/cxl/core/region.c:850 (inlined by) cxlregionattach at drivers/cxl/core/region.c:1290 (inlined by) attachtarget at drivers/cxl/core/region.c:1410 (inlined by) storetargetN at drivers/cxl/core/region.c:1453

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

cxl/region: Fix decoder allocation crash

When an intermediate port's decoders have been exhausted by existing regions, and creating a new region with the port in question in it's hierarchical path is attempted, cxlportattachregion() fails to find a port decoder (as would be expected), and drops into the failure / cleanup path.

However, during cleanup of the region reference, a sanity check attempts to dereference the decoder, which in the above case didn't exist. This causes a NULL pointer dereference BUG.

To fix this, refactor the decoder allocation and de-allocation into helper routines, and in this 'free' routine, check that the decoder, @cxld, is valid before attempting any operations on it.

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

cxl/region: Fix cxlregion leak, cleanup targets at region delete

When a region is deleted any targets that have been previously assigned to that region hold references to it. Trigger those references to drop by detaching all targets at unregisterregion() time.

Otherwise that region object will leak as userspace has lost the ability to detach targets once region sysfs is torn down.

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

tracing: kprobe: Fix memory leak in testgenkprobe/kretprobecmd()

testgenkprobecmd() only free buf in fail path, hence buf will leak when there is no failure. Move kfree(buf) from fail path to common path to prevent the memleak. The same reason and solution in testgenkretprobecmd().

unreferenced object 0xffff888143b14000 (size 2048): comm "insmod", pid 52490, jiffies 4301890980 (age 40.553s) hex dump (first 32 bytes): 70 3a 6b 70 72 6f 62 65 73 2f 67 65 6e 5f 6b 70 p:kprobes/genkp 72 6f 62 65 5f 74 65 73 74 20 64 6f 5f 73 79 73 robetest dosys backtrace: [<000000006d7b836b>] kmalloctrace+0x27/0xa0 [<0000000009528b5b>] 0xffffffffa059006f [<000000008408b580>] dooneinitcall+0x87/0x2a0 [<00000000c4980a7e>] doinitmodule+0xdf/0x320 [<00000000d775aad0>] loadmodule+0x3006/0x3390 [<00000000e9a74b80>] dosysfinitmodule+0x113/0x1b0 [<000000003726480d>] dosyscall64+0x35/0x80 [<000000003441e93b>] entrySYSCALL64afterhwframe+0x46/0xb0

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

capabilities: fix potential memleak on error path from vfsgetxattralloc()

In capinodegetsecurity(), we will use vfsgetxattralloc() to complete the memory allocation of tmpbuf, if we have completed the memory allocation of tmpbuf, but failed to call handler->get(...), there will be a memleak in below logic:

|-- ret = (int)vfsgetxattralloc(mntuserns, ...) | / ^^^ alloc for tmpbuf / |-- value = krealloc(xattrvalue, error + 1, flags) | / ^^^ alloc memory / |-- error = handler->get(handler, ...) | / error! / |-- xattrvalue = value | / xattrvalue is &tmpbuf (memory leak!) /

So we will try to free(tmpbuf) after vfsgetxattralloc() fails to fix it.

[PM: subject line and backtrace tweaks]

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

wifi: cfg80211: fix memory leak in queryregdbfile()

In the function queryregdbfile() the alpha2 parameter is duplicated using kmemdup() and subsequently freed in regdbfwcb(). However, requestfirmwarenowait() can fail without calling regdbfwcb() and thus leak memory.

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

ext4: fix warning in 'ext4dareleasespace'

Syzkaller report issue as follows: EXT4-fs (loop0): Free/Dirty block details EXT4-fs (loop0): freeblocks=0 EXT4-fs (loop0): dirtyblocks=0 EXT4-fs (loop0): Block reservation details EXT4-fs (loop0): ireserveddatablocks=0 EXT4-fs warning (device loop0): ext4dareleasespace:1527: ext4dareleasespace: ino 18, tofree 1 with only 0 reserved data blocks ------------[ cut here ]------------ WARNING: CPU: 0 PID: 92 at fs/ext4/inode.c:1528 ext4dareleasespace+0x25e/0x370 fs/ext4/inode.c:1524 Modules linked in: CPU: 0 PID: 92 Comm: kworker/u4:4 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: writeback wbworkfn (flush-7:0) RIP: 0010:ext4dareleasespace+0x25e/0x370 fs/ext4/inode.c:1528 RSP: 0018:ffffc900015f6c90 EFLAGS: 00010296 RAX: 42215896cd52ea00 RBX: 0000000000000000 RCX: 42215896cd52ea00 RDX: 0000000000000000 RSI: 0000000080000001 RDI: 0000000000000000 RBP: 1ffff1100e907d96 R08: ffffffff816aa79d R09: fffff520002bece5 R10: fffff520002bece5 R11: 1ffff920002bece4 R12: ffff888021fd2000 R13: ffff88807483ecb0 R14: 0000000000000001 R15: ffff88807483e740 FS: 0000000000000000(0000) GS:ffff8880b9a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005555569ba628 CR3: 000000000c88e000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ext4esremoveextent+0x1ab/0x260 fs/ext4/extentsstatus.c:1461 mpagereleaseunusedpages+0x24d/0xef0 fs/ext4/inode.c:1589 ext4writepages+0x12eb/0x3be0 fs/ext4/inode.c:2852 dowritepages+0x3c3/0x680 mm/page-writeback.c:2469 writebacksingleinode+0xd1/0x670 fs/fs-writeback.c:1587 writebacksbinodes+0xb3b/0x18f0 fs/fs-writeback.c:1870 wbwriteback+0x41f/0x7b0 fs/fs-writeback.c:2044 wbdowriteback fs/fs-writeback.c:2187 [inline] wbworkfn+0x3cb/0xef0 fs/fs-writeback.c:2227 processonework+0x877/0xdb0 kernel/workqueue.c:2289 workerthread+0xb14/0x1330 kernel/workqueue.c:2436 kthread+0x266/0x300 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306 </TASK>

Above issue may happens as follows: ext4dawritebegin ext4createinlinedata ext4clearinodeflag(inode, EXT4INODEEXTENTS); ext4setinodeflag(inode, EXT4INODEINLINEDATA); ext4ioctl ext4extmigrate -> will lead to eh->ehentries not zero, and set extent flag ext4dawritebegin ext4daconvertinlinedatatoextent ext4dawriteinlinedatabegin ext4damapblocks ext4insertdelayedblock if (!ext4esscanclu(inode, &ext4esisdelonly, lblk)) if (!ext4esscanclu(inode, &ext4esismapped, lblk)) ext4clumapped(inode, EXT4B2C(sbi, lblk)); -> will return 1 allocated = true; ext4esinsertdelayedblock(inode, lblk, allocated); ext4writepages mpagemapandsubmitextent(handle, &mpd, &giveuponwrite); -> return -ENOSPC mpagereleaseunusedpages(&mpd, giveuponwrite); -> giveuponwrite == 1 ext4esremoveextent ext4dareleasespace(inode, reserved); if (unlikely(tofree > ei->ireserveddatablocks)) -> tofree == 1 but ei->ireserveddatablocks == 0 -> then trigger warning as above

To solve above issue, forbid inode do migrate which has inline data.

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

ext4: fix BUGON() when directory entry has invalid reclen

The reclen field in the directory entry has to be a multiple of 4. A corrupted filesystem image can be used to hit a BUG() in ext4reclentodisk(), called from makeindexeddir().

------------[ cut here ]------------ kernel BUG at fs/ext4/ext4.h:2413! ... RIP: 0010:makeindexeddir+0x53f/0x5f0 ... Call Trace: <TASK> ? adddirenttobuf+0x1b2/0x200 ext4addentry+0x36e/0x480 ext4addnondir+0x2b/0xc0 ext4create+0x163/0x200 pathopenat+0x635/0xe90 dofilpopen+0xb4/0x160 ? createobject.isra.0+0x1de/0x3b0 ? rawspinunlock+0x12/0x30 dosysopenat2+0x91/0x150 x64sysopen+0x6c/0xa0 dosyscall64+0x3c/0x80 entrySYSCALL64afterhwframe+0x46/0xb0

The fix simply adds a call to ext4checkdirentry() to validate the directory entry, returning -EFSCORRUPTED if the entry is invalid.