btrfs: zoned: clone zoned device info when cloning a device

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

can: mcan: pci: add missing mcanclassfreedev() in probe/remove methods

In mcanpciremove() and error handling path of mcanpciprobe(), mcanclassfreedev() should be called to free resource allocated by mcanclassallocatedev(), otherwise there will be memleak.

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

can: j1939: j1939sendone(): fix missing CAN header initialization

The read access to struct canxlframe::len inside of a j1939 created skbuff revealed a missing initialization of reserved and later filled elements in struct canframe.

This patch initializes the 8 byte CAN header with zero.

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

netdevsim: Fix memory leak of nsimdev->facookie

kmemleak reports this issue:

unreferenced object 0xffff8881bac872d0 (size 8): comm "sh", pid 58603, jiffies 4481524462 (age 68.065s) hex dump (first 8 bytes): 04 00 00 00 de ad be ef ........ backtrace: [<00000000c80b8577>] kmalloc+0x49/0x150 [<000000005292b8c6>] nsimdevtrapfacookiewrite+0xc1/0x210 [netdevsim] [<0000000093d78e77>] fullproxywrite+0xf3/0x180 [<000000005a662c16>] vfswrite+0x1c5/0xaf0 [<000000007aabf84a>] ksyswrite+0xed/0x1c0 [<000000005f1d2e47>] dosyscall64+0x3b/0x90 [<000000006001c6ec>] entrySYSCALL64afterhwframe+0x63/0xcd

The issue occurs in the following scenarios:

nsimdevtrapfacookiewrite() kmalloc() facookie nsimdev->facookie = facookie .. nsimdrvremove()

The facookie allocked in nsimdevtrapfacookiewrite() is not freed. To fix, add kfree(nsimdev->facookie) to nsimdrvremove().

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

misc/vmwvmci: fix an infoleak in vmcihostdoreceivedatagram()

struct vmcieventqp allocated by qpnotifypeer() contains padding, which may carry uninitialized data to the userspace, as observed by KMSAN:

BUG: KMSAN: kernel-infoleak in instrumentcopytouser ./include/linux/instrumented.h:121 instrumentcopytouser ./include/linux/instrumented.h:121 copytouser+0x5f/0xb0 lib/usercopy.c:33 copytouser ./include/linux/uaccess.h:169 vmcihostdoreceivedatagram drivers/misc/vmwvmci/vmcihost.c:431 vmcihostunlockedioctl+0x33d/0x43d0 drivers/misc/vmwvmci/vmcihost.c:925 vfsioctl fs/ioctl.c:51 ...

Uninit was stored to memory at: kmemdup+0x74/0xb0 mm/util.c:131 dgdispatchashost drivers/misc/vmwvmci/vmcidatagram.c:271 vmcidatagramdispatch+0x4f8/0xfc0 drivers/misc/vmwvmci/vmcidatagram.c:339 qpnotifypeer+0x19a/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1479 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueuepair.c:1750 vmciqpbrokeralloc+0x96/0xd0 drivers/misc/vmwvmci/vmciqueuepair.c:1940 vmcihostdoallocqueuepair drivers/misc/vmwvmci/vmcihost.c:488 vmcihostunlockedioctl+0x24fd/0x43d0 drivers/misc/vmwvmci/vmcihost.c:927 ...

Local variable ev created at: qpnotifypeer+0x54/0x290 drivers/misc/vmwvmci/vmciqueuepair.c:1456 qpbrokerattach drivers/misc/vmwvmci/vmciqueuepair.c:1662 qpbrokeralloc+0x2977/0x2f30 drivers/misc/vmwvmci/vmciqueuepair.c:1750

Bytes 28-31 of 48 are uninitialized Memory access of size 48 starts at ffff888035155e00 Data copied to user address 0000000020000100

Use memset() to prevent the infoleaks.

Also speculatively fix qpnotifypeerlocal(), which may suffer from the same problem.

A NULL pointer dereference flaw was found in the Linux kernel AMD Sensor Fusion Hub driver. This flaw allows a local user to crash the system.

A NULL pointer dereference flaw was found in the Linux kernel's drivers/gpu/drm/msm/msmgemsubmit.c code in the submitlookupcmds function, which fails because it lacks a check of the return value of kmalloc(). This issue allows a local user to crash the system.

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

cifs: Fix connections leak when tlink setup failed

If the tlink setup failed, lost to put the connections, then the module refcnt leak since the cifsd kthread not exit.

Also leak the fscache info, and for next mount with fsc, it will print the follow errors: CIFS: Cache volume key already in use (cifs,127.0.0.1:445,TEST)

Let's check the result of tlink setup, and do some cleanup.

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:

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:

bpf, sockmap: Fix the sk->skforwardalloc warning of skstreamkillqueues

When running testsockmap selftests, the following warning appears:

WARNING: CPU: 2 PID: 197 at net/core/stream.c:205 skstreamkillqueues+0xd3/0xf0 Call Trace: <TASK> inetcskdestroysock+0x55/0x110 tcprcvstateprocess+0xd28/0x1380 ? tcpv4dorcv+0x77/0x2c0 tcpv4dorcv+0x77/0x2c0 releasesock+0x106/0x130 tcpclose+0x1a7/0x4e0 tcpclose+0x20/0x70 inetrelease+0x3c/0x80 sockrelease+0x3a/0xb0 sockclose+0x14/0x20 fput+0xa3/0x260 taskworkrun+0x59/0xb0 exittousermodeprepare+0x1b3/0x1c0 syscallexittousermode+0x19/0x50 dosyscall64+0x48/0x90 entrySYSCALL64afterhwframe+0x44/0xae

The root case is in commit 84472b436e76 ("bpf, sockmap: Fix more uncharged while msg has moredata"), where I used msg->sg.size to replace the tosend, causing breakage:

if (msg->applybytes && msg->applybytes < tosend) tosend = psock->applybytes;

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

tipc: fix the msg->req tlv len check in tipcnlcompatnametabledumpheader

This is a follow-up for commit 974cb0e3e7c9 ("tipc: fix uninit-value in tipcnlcompatnametabledump") where it should have type casted sizeof(..) to int to work when TLVGETDATALEN() returns a negative value.

syzbot reported a call trace because of it:

BUG: KMSAN: uninit-value in ... tipcnlcompatnametabledump+0x841/0xea0 net/tipc/netlinkcompat.c:934 tipcnlcompatdumpit+0xab2/0x1320 net/tipc/netlinkcompat.c:238 tipcnlcompatdumpit+0x991/0xb50 net/tipc/netlinkcompat.c:321 tipcnlcompatrecv+0xb6e/0x1640 net/tipc/netlinkcompat.c:1324 genlfamilyrcvmsgdoit net/netlink/genetlink.c:731 [inline] genlfamilyrcvmsg net/netlink/genetlink.c:775 [inline] genlrcvmsg+0x103f/0x1260 net/netlink/genetlink.c:792 netlinkrcvskb+0x3a5/0x6c0 net/netlink/afnetlink.c:2501 genlrcv+0x3c/0x50 net/netlink/genetlink.c:803 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0xf3b/0x1270 net/netlink/afnetlink.c:1345 netlinksendmsg+0x1288/0x1440 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg net/socket.c:734 [inline]

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

dmaengine: mvxorv2: Fix a resource leak in mvxorv2remove()

A clkprepareenable() call in the probe is not balanced by a corresponding clkdisableunprepare() in the remove function.

Add the missing call.

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

btrfs: fix match incorrectly in devargsmatchdevice

syzkaller found a failed assertion:

assertion failed: (args->devid != (u64)-1) || args->missing, in fs/btrfs/volumes.c:6921

This can be triggered when we set devid to (u64)-1 by ioctl. In this case, the match of devid will be skipped and the match of device may succeed incorrectly.

Patch 562d7b1512f7 introduced this function which is used to match device. This function contains two matching scenarios, we can distinguish them by checking the value of args->missing rather than check whether args->devid and args->uuid is default value.

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

net/x25: Fix skb leak in x25lapbreceiveframe()

x25lapbreceiveframe() using skbcopy() to get a private copy of skb, the new skb should be freed in the undersized/fragmented skb error handling path. Otherwise there is a memory leak.

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

tracing: Fix memory leak in tracingreadpipe()

kmemleak reports this issue:

unreferenced object 0xffff888105a18900 (size 128): comm "testprogs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] kmallocnodetrackcaller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] traceiterexpandformat+0x99/0x150 [<000000005a53bdb6>] tracecheckvprintf+0x1e0/0x11d0 [<0000000065629d9d>] traceeventprintf+0xb6/0xf0 [<000000009a690dc7>] tracerawoutputbpftraceprintk+0x89/0xc0 [<00000000d22db172>] printtraceline+0x73c/0x1480 [<00000000cdba76ba>] tracingreadpipe+0x45c/0x9f0 [<0000000015b58459>] vfsread+0x17b/0x7c0 [<000000004aeee8ed>] ksysread+0xed/0x1c0 [<0000000063d3d898>] dosyscall64+0x3b/0x90 [<00000000a06dda7f>] entrySYSCALL64afterhwframe+0x63/0xcd

iter->fmt alloced in tracingreadpipe() -> .. ->traceiterexpandformat(), but not freed, to fix, add free in tracingreleasepipe()

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

Input: i8042 - fix leaking of platform device on module removal

Avoid resetting the module-wide i8042platformdevice pointer in i8042probe() or i8042remove(), so that the device can be properly destroyed by i8042exit() on module unload.

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

mptcp: fix sleep in atomic at close time

Matt reported a splat at msk close time:

BUG: sleeping function called from invalid context at net/mptcp/protocol.c:2877 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 155, name: packetdrill preemptcount: 201, expected: 0 RCU nest depth: 0, expected: 0 4 locks held by packetdrill/155: #0: ffff888001536990 (&sb->stype->imutexkey#6){+.+.}-{3:3}, at: sockrelease (net/socket.c:650) #1: ffff88800b498130 (sklock-AFINET){+.+.}-{0:0}, at: mptcpclose (net/mptcp/protocol.c:2973) #2: ffff88800b49a130 (sklock-AFINET/1){+.+.}-{0:0}, at: mptcpclosessk (net/mptcp/protocol.c:2363) #3: ffff88800b49a0b0 (slock-AFINET){+...}-{2:2}, at: locksockfast (include/net/sock.h:1820) Preemption disabled at: 0x0 CPU: 1 PID: 155 Comm: packetdrill Not tainted 6.1.0-rc5 #365 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Call Trace: <TASK> dumpstacklvl (lib/dumpstack.c:107 (discriminator 4)) mightresched.cold (kernel/sched/core.c:9891) mptcpdestroysock (include/linux/kernel.h:110) mptcpclose (net/mptcp/protocol.c:2959) mptcpsubflowqueueclean (include/net/sock.h:1777) mptcpclosessk (net/mptcp/protocol.c:2363) mptcpdestroycommon (net/mptcp/protocol.c:3170) mptcpdestroy (include/net/sock.h:1495) mptcpdestroysock (net/mptcp/protocol.c:2886) mptcpclose (net/mptcp/protocol.c:2959) mptcpclose (net/mptcp/protocol.c:2974) inetrelease (net/ipv4/afinet.c:432) sockrelease (net/socket.c:651) sockclose (net/socket.c:1367) fput (fs/filetable.c:320) taskworkrun (kernel/taskwork.c:181 (discriminator 1)) exittousermodeprepare (include/linux/resumeusermode.h:49) syscallexittousermode (kernel/entry/common.c:130) dosyscall64 (arch/x86/entry/common.c:87) entrySYSCALL64afterhwframe (arch/x86/entry/entry64.S:120)

We can't call mptcpclose under the 'fast' socket lock variant, replace it with a socklocknested() as the relevant code is already under the listening msk socket lock protection.

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

ASoC: ops: Fix bounds check for sx controls

For sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in sndsocputvolswsx() needs to just check against the maximum value.

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

can: afcan: fix NULL pointer dereference in canrcvfilter

Analogue to commit 8aa59e355949 ("can: afcan: fix NULL pointer dereference in canrxregister()") we need to check for a missing initialization of mlpriv in the receive path of CAN frames.

Since commit 4e096a18867a ("net: introduce CAN specific pointer in the struct netdevice") the check for dev->type to be ARPHRDCAN is not sufficient anymore since bonding or tun netdevices claim to be CAN devices but do not initialize mlpriv accordingly.

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:

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: 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:

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:

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().