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

netdevsim: fix memory leak in nsimdrvprobe() when nsimdevresourcesregister() failed

If some items in nsimdevresourcesregister() fail, memory leak will occur. The following is the memory leak information.

unreferenced object 0xffff888074c02600 (size 128): comm "echo", pid 8159, jiffies 4294945184 (age 493.530s) hex dump (first 32 bytes): 40 47 ea 89 ff ff ff ff 01 00 00 00 00 00 00 00 @G.............. ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ................ backtrace: [<0000000011a31c98>] kmalloctrace+0x22/0x60 [<0000000027384c69>] devlresourceregister+0x144/0x4e0 [<00000000a16db248>] nsimdrvprobe+0x37a/0x1260 [<000000007d1f448c>] reallyprobe+0x20b/0xb10 [<00000000c416848a>] driverprobedevice+0x1b3/0x4a0 [<00000000077e0351>] driverprobedevice+0x49/0x140 [<0000000054f2465a>] deviceattachdriver+0x18c/0x2a0 [<000000008538f359>] busforeachdrv+0x151/0x1d0 [<0000000038e09747>] deviceattach+0x1c9/0x4e0 [<00000000dd86e533>] busprobedevice+0x1d5/0x280 [<00000000839bea35>] deviceadd+0xae0/0x1cb0 [<000000009c2abf46>] newdevicestore+0x3b6/0x5f0 [<00000000fb823d7f>] busattrstore+0x72/0xa0 [<000000007acc4295>] sysfskfwrite+0x106/0x160 [<000000005f50cb4d>] kernfsfopwriteiter+0x3a8/0x5a0 [<0000000075eb41bf>] vfswrite+0x8f0/0xc80

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

coresight: cti: Fix hang in ctidisablehw()

ctienablehw() and ctidisablehw() are called from an atomic context so shouldn't use runtime PM because it can result in a sleep when communicating with firmware.

Since commit 3c6656337852 ("Revert "firmware: armscmi: Add clock management to the SCMI power domain""), this causes a hang on Juno when running the Perf Coresight tests or running this command:

perf record -e csetm//u -- ls

This was also missed until the revert commit because pmruntimeput() was called with the wrong device until commit 692c9a499b28 ("coresight: cti: Correct the parameter for pmruntimeput")

With lock and scheduler debugging enabled the following is output:

coresight ctisys0: ctienablehw -- dev:ctisys0 parent: 20020000.cti BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1151 inatomic(): 1, irqsdisabled(): 128, nonblock: 0, pid: 330, name: perf-exec preemptcount: 2, expected: 0 RCU nest depth: 0, expected: 0 INFO: lockdep is turned off. irq event stamp: 0 hardirqs last enabled at (0): [<0000000000000000>] 0x0 hardirqs last disabled at (0): [<ffff80000822b394>] copyprocess+0xa0c/0x1948 softirqs last enabled at (0): [<ffff80000822b394>] copyprocess+0xa0c/0x1948 softirqs last disabled at (0): [<0000000000000000>] 0x0 CPU: 3 PID: 330 Comm: perf-exec Not tainted 6.0.0-00053-g042116d99298 #7 Hardware name: ARM LTD ARM Juno Development Platform/ARM Juno Development Platform, BIOS EDK II Sep 13 2022 Call trace: dumpbacktrace+0x134/0x140 showstack+0x20/0x58 dumpstacklvl+0x8c/0xb8 dumpstack+0x18/0x34 mightresched+0x180/0x228 mightsleep+0x50/0x88 pmruntimeresume+0xac/0xb0 ctienable+0x44/0x120 coresightcontrolassocectdev+0xc0/0x150 coresightenablepath+0xb4/0x288 etmeventstart+0x138/0x170 etmeventadd+0x48/0x70 eventschedin.isra.122+0xb4/0x280 mergeschedin+0x1fc/0x3d0 visitgroupsmerge.constprop.137+0x16c/0x4b0 ctxschedin+0x114/0x1f0 perfeventschedin+0x60/0x90 ctxresched+0x68/0xb0 perfeventexec+0x138/0x508 beginnewexec+0x52c/0xd40 loadelfbinary+0x6b8/0x17d0 bprmexecve+0x360/0x7f8 doexecveatcommon.isra.47+0x218/0x238 arm64sysexecve+0x48/0x60 invokesyscall+0x4c/0x110 el0svccommon.constprop.4+0xfc/0x120 doel0svc+0x34/0xc0 el0svc+0x40/0x98 el0t64synchandler+0x98/0xc0 el0t64sync+0x170/0x174

Fix the issue by removing the runtime PM calls completely. They are not needed here because it must have already been done when building the path for a trace.

[ Fix build warnings ]

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

fs/binfmtelf: Fix memory leak in loadelfbinary()

There is a memory leak reported by kmemleak:

unreferenced object 0xffff88817104ef80 (size 224): comm "xfsadmin", pid 47165, jiffies 4298708825 (age 1333.476s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 60 a8 b3 00 81 88 ff ff a8 10 5a 00 81 88 ff ff .........Z..... backtrace: [<ffffffff819171e1>] allocfile+0x21/0x250 [<ffffffff81918061>] allocemptyfile+0x41/0xf0 [<ffffffff81948cda>] pathopenat+0xea/0x3d30 [<ffffffff8194ec89>] dofilpopen+0x1b9/0x290 [<ffffffff8192660e>] doopenexecat+0xce/0x5b0 [<ffffffff81926b17>] openexec+0x27/0x50 [<ffffffff81a69250>] loadelfbinary+0x510/0x3ed0 [<ffffffff81927759>] bprmexecve+0x599/0x1240 [<ffffffff8192a997>] doexecveatcommon.isra.0+0x4c7/0x680 [<ffffffff8192b078>] x64sysexecve+0x88/0xb0 [<ffffffff83bbf0a5>] dosyscall64+0x35/0x80

If "interpelfex" fails to allocate memory in loadelfbinary(), the program will take the "outfreeph" error handing path, resulting in "interpreter" file resource is not released.

Fix it by adding an error handing path "outfreefile", which will release the file resource when "interpelfex" failed to allocate memory.

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

net: hinic: fix memory leak when reading function table

When the input parameter idx meets the expected case option in hinicdbggetfunctable(), readdata is not released. Fix it.

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

ALSA: aoa: i2sbus: fix possible memory leak in i2sbusadddev()

devsetname() in soundbusaddone() allocates memory for name, it need be freed when ofdeviceregister() fails, call soundbusdevput() to give up the reference that hold in deviceinitialize(), so that it can be freed in kobjectcleanup() when the refcount hit to 0. And other resources are also freed in i2sbusreleasedev(), so it can return 0 directly.

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

ALSA: ac97: fix possible memory leak in sndac97devregister()

If deviceregister() fails in sndac97devregister(), it should call putdevice() to give up reference, or the name allocated in devsetname() is leaked.

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

drm/msm/dp: add atomiccheck to bridge ops

DRM committails() will disable downstream crtc/encoder/bridge if both disable crtc is required and crtc->active is set before pushing a new frame downstream.

There is a rare case that user space display manager issue an extra screen update immediately followed by close DRM device while down stream display interface is disabled. This extra screen update will timeout due to the downstream interface is disabled but will cause crtc->active be set. Hence the followed committails() called by drmrelease() will pass the disable downstream crtc/encoder/bridge conditions checking even downstream interface is disabled. This cause the crash to happen at dpbridgedisable() due to it trying to access the main link register to push the idle pattern out while main link clocks is disabled.

This patch adds atomiccheck to prevent the extra frame will not be pushed down if display interface is down so that crtc->active will not be set neither. This will fail the conditions checking of disabling down stream crtc/encoder/bridge which prevent drmrelease() from calling dpbridgedisable() so that crash at dpbridgedisable() prevented.

There is no protection in the DRM framework to check if the display pipeline has been already disabled before trying again. The only check is the crtcstate->active but this is controlled by usermode using UAPI. Hence if the usermode sets this and then crashes, the driver needs to protect against double disable.

SError Interrupt on CPU7, code 0x00000000be000411 -- SError CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) pstate: a04000c9 (NzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : cmpxchgcaseacq32+0x14/0x2c lr : dorawspinlock+0xa4/0xdc sp : ffffffc01092b6a0 x29: ffffffc01092b6a0 x28: 0000000000000028 x27: 0000000000000038 x26: 0000000000000004 x25: ffffffd2973dce48 x24: 0000000000000000 x23: 00000000ffffffff x22: 00000000ffffffff x21: ffffffd2978d0008 x20: ffffffd2978d0008 x19: ffffff80ff759fc0 x18: 0000000000000000 x17: 004800a501260460 x16: 0441043b04600438 x15: 04380000089807d0 x14: 07b0089807800780 x13: 0000000000000000 x12: 0000000000000000 x11: 0000000000000438 x10: 00000000000007d0 x9 : ffffffd2973e09e4 x8 : ffffff8092d53300 x7 : ffffff808902e8b8 x6 : 0000000000000001 x5 : ffffff808902e880 x4 : 0000000000000000 x3 : ffffff80ff759fc0 x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffffff80ff759fc0 Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 3878 Comm: Xorg Not tainted 5.19.0-stb-cbq #19 Hardware name: Google Lazor (rev3 - 8) (DT) Call trace: dumpbacktrace.part.0+0xbc/0xe4 showstack+0x24/0x70 dumpstacklvl+0x68/0x84 dumpstack+0x18/0x34 panic+0x14c/0x32c nmipanic+0x58/0x7c arm64serrorpanic+0x78/0x84 doserror+0x40/0x64 el1h64errorhandler+0x30/0x48 el1h64error+0x68/0x6c cmpxchgcaseacq32+0x14/0x2c rawspinlockirqsave+0x38/0x4c locktimerbase+0x40/0x78 modtimer+0xf4/0x25c scheduletimeout+0xd4/0xfc waitforcommon+0xac/0x140 waitforcompletiontimeout+0x2c/0x54 dpctrlpushidle+0x40/0x88 dpbridgedisable+0x24/0x30 drmatomicbridgechaindisable+0x90/0xbc drmatomichelpercommitmodesetdisables+0x198/0x444 msmatomiccommittail+0x1d0/0x374 committail+0x80/0x108 drmatomichelpercommit+0x118/0x11c drmatomiccommit+0xb4/0xe0 drmclientmodesetcommitatomic+0x184/0x224 drmclientmodesetcommitlocked+0x58/0x160 drmclientmodesetcommit+0x3c/0x64 drmfbhelperrestorefbdevmodeunlocked+0x98/0xac drmfbhelpersetpar+0x74/0x80 drmfbhelperhotplugevent+0xdc/0xe0 drmfbhelperrestorefbdevmodeunlocked+0x7c/0xac drmfbhelperrestorefbdevmodeunlocked+0x20/0x2c drmfbhelperlastclose+0x20/0x2c drmlastclose+0x44/0x6c drmrelease+0x88/0xd4 fput+0x104/0x220 fput+0x1c/0x28 taskworkrun+0x8c/0x100 d ---truncated---

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

net: hinic: fix the issue of CMDQ memory leaks

When hinicsetcmdqdepth() fails in hinicinitcmdqs(), the cmdq memory is not released correctly. Fix it.

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

drm/msm/dp: fix aux-bus EP lifetime

Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred.

This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made.

For the DP aux-bus, an attempt to populate the bus a second time will simply fail ("DP AUX EP device already populated").

Fix this by tying the lifetime of the EP device to the DRM device rather than DP controller platform device.

Patchwork: https://patchwork.freedesktop.org/patch/502672/

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

net: do not sense pfmemalloc status in skbappendpagefrags()

skbappendpagefrags() is used by afunix and udp sendpage() implementation so far.

In commit 326140063946 ("tcp: TX zerocopy should not sense pfmemalloc status") we explained why we should not sense pfmemalloc status for pages owned by user space.

We should also use skbfillpagedescnoacc() in skbappendpagefrags() to avoid following KCSAN report:

BUG: KCSAN: data-race in lruaddfn / skbappendpagefrags

write to 0xffffea00058fc1c8 of 8 bytes by task 17319 on cpu 0: listadd include/linux/list.h:73 [inline] listadd include/linux/list.h:88 [inline] lruvecaddfolio include/linux/mminline.h:323 [inline] lruaddfn+0x327/0x410 mm/swap.c:228 foliobatchmovelru+0x1e1/0x2a0 mm/swap.c:246 lruadddraincpu+0x73/0x250 mm/swap.c:669 lruadddrain+0x21/0x60 mm/swap.c:773 freepagesandswapcache+0x16/0x70 mm/swapstate.c:311 tlbbatchpagesflush mm/mmugather.c:59 [inline] tlbflushmmufree mm/mmugather.c:256 [inline] tlbflushmmu+0x5b2/0x640 mm/mmugather.c:263 tlbfinishmmu+0x86/0x100 mm/mmugather.c:363 exitmmap+0x190/0x4d0 mm/mmap.c:3098 mmput+0x27/0x1b0 kernel/fork.c:1185 mmput+0x3d/0x50 kernel/fork.c:1207 copyprocess+0x19fc/0x2100 kernel/fork.c:2518 kernelclone+0x166/0x550 kernel/fork.c:2671 dosysclone kernel/fork.c:2812 [inline] sesysclone kernel/fork.c:2796 [inline] x64sysclone+0xc3/0xf0 kernel/fork.c:2796 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

read to 0xffffea00058fc1c8 of 8 bytes by task 17325 on cpu 1: pageispfmemalloc include/linux/mm.h:1817 [inline] skbfillpagedesc include/linux/skbuff.h:2432 [inline] skbfillpagedesc include/linux/skbuff.h:2453 [inline] skbappendpagefrags+0x210/0x600 net/core/skbuff.c:3974 unixstreamsendpage+0x45e/0x990 net/unix/afunix.c:2338 kernelsendpage+0x184/0x300 net/socket.c:3561 socksendpage+0x5a/0x70 net/socket.c:1054 pipetosendpage+0x128/0x160 fs/splice.c:361 splicefrompipefeed fs/splice.c:415 [inline] splicefrompipe+0x222/0x4d0 fs/splice.c:559 splicefrompipe fs/splice.c:594 [inline] genericsplicesendpage+0x89/0xc0 fs/splice.c:743 dosplicefrom fs/splice.c:764 [inline] directspliceactor+0x80/0xa0 fs/splice.c:931 splicedirecttoactor+0x305/0x620 fs/splice.c:886 dosplicedirect+0xfb/0x180 fs/splice.c:974 dosendfile+0x3bf/0x910 fs/readwrite.c:1255 dosyssendfile64 fs/readwrite.c:1323 [inline] sesyssendfile64 fs/readwrite.c:1309 [inline] x64syssendfile64+0x10c/0x150 fs/readwrite.c:1309 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

value changed: 0x0000000000000000 -> 0xffffea00058fc188

Reported by Kernel Concurrency Sanitizer on: CPU: 1 PID: 17325 Comm: syz-executor.0 Not tainted 6.1.0-rc1-syzkaller-00158-g440b7895c990-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/11/2022

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

drm/msm/dp: fix bridge lifetime

Device-managed resources allocated post component bind must be tied to the lifetime of the aggregate DRM device or they will not necessarily be released when binding of the aggregate device is deferred.

This can lead resource leaks or failure to bind the aggregate device when binding is later retried and a second attempt to allocate the resources is made.

For the DP bridges, previously allocated bridges will leak on probe deferral.

Fix this by amending the DP parser interface and tying the lifetime of the bridge device to the DRM device rather than DP platform device.

Patchwork: https://patchwork.freedesktop.org/patch/502667/

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

kcm: annotate data-races around kcm->rxpsock

kcm->rxpsock can be read locklessly in kcmrfree(). Annotate the read and writes accordingly.

We do the same for kcm->rxwait in the following patch.

syzbot reported: BUG: KCSAN: data-race in kcmrfree / unreserverxkcm

write to 0xffff888123d827b8 of 8 bytes by task 2758 on cpu 1: unreserverxkcm+0x72/0x1f0 net/kcm/kcmsock.c:313 kcmrcvstrparser+0x2b5/0x3a0 net/kcm/kcmsock.c:373 strprecv+0x64c/0xd20 net/strparser/strparser.c:301 strprecv+0x6d/0x80 net/strparser/strparser.c:335 tcpreadsock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strpreadsock net/strparser/strparser.c:358 [inline] dostrpwork net/strparser/strparser.c:406 [inline] strpwork+0xe8/0x180 net/strparser/strparser.c:415 processonework+0x3d3/0x720 kernel/workqueue.c:2289 workerthread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306

read to 0xffff888123d827b8 of 8 bytes by task 5859 on cpu 0: kcmrfree+0x14c/0x220 net/kcm/kcmsock.c:181 skbreleaseheadstate+0x8e/0x160 net/core/skbuff.c:841 skbreleaseall net/core/skbuff.c:852 [inline] kfreeskb net/core/skbuff.c:868 [inline] kfreeskbreason+0x5c/0x260 net/core/skbuff.c:891 kfreeskb include/linux/skbuff.h:1216 [inline] kcmrecvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 sysrecvmsg+0x16c/0x2e0 sysrecvmsg net/socket.c:2743 [inline] dorecvmmsg+0x2f1/0x710 net/socket.c:2837 sysrecvmmsg net/socket.c:2916 [inline] dosysrecvmmsg net/socket.c:2939 [inline] sesysrecvmmsg net/socket.c:2932 [inline] x64sysrecvmmsg+0xde/0x160 net/socket.c:2932 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

value changed: 0xffff88812971ce00 -> 0x0000000000000000

Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 5859 Comm: syz-executor.3 Not tainted 6.0.0-syzkaller-12189-g19d17ab7c68b-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

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

kcm: annotate data-races around kcm->rxwait

kcm->rxpsock can be read locklessly in kcmrfree(). Annotate the read and writes accordingly.

syzbot reported:

BUG: KCSAN: data-race in kcmrcvstrparser / kcmrfree

write to 0xffff88810784e3d0 of 1 bytes by task 1823 on cpu 1: reserverxkcm net/kcm/kcmsock.c:283 [inline] kcmrcvstrparser+0x250/0x3a0 net/kcm/kcmsock.c:363 strprecv+0x64c/0xd20 net/strparser/strparser.c:301 strprecv+0x6d/0x80 net/strparser/strparser.c:335 tcpreadsock+0x13e/0x5a0 net/ipv4/tcp.c:1703 strpreadsock net/strparser/strparser.c:358 [inline] dostrpwork net/strparser/strparser.c:406 [inline] strpwork+0xe8/0x180 net/strparser/strparser.c:415 processonework+0x3d3/0x720 kernel/workqueue.c:2289 workerthread+0x618/0xa70 kernel/workqueue.c:2436 kthread+0x1a9/0x1e0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306

read to 0xffff88810784e3d0 of 1 bytes by task 17869 on cpu 0: kcmrfree+0x121/0x220 net/kcm/kcmsock.c:181 skbreleaseheadstate+0x8e/0x160 net/core/skbuff.c:841 skbreleaseall net/core/skbuff.c:852 [inline] kfreeskb net/core/skbuff.c:868 [inline] kfreeskbreason+0x5c/0x260 net/core/skbuff.c:891 kfreeskb include/linux/skbuff.h:1216 [inline] kcmrecvmsg+0x226/0x2b0 net/kcm/kcmsock.c:1161 sysrecvmsg+0x16c/0x2e0 sysrecvmsg net/socket.c:2743 [inline] dorecvmmsg+0x2f1/0x710 net/socket.c:2837 sysrecvmmsg net/socket.c:2916 [inline] dosysrecvmmsg net/socket.c:2939 [inline] sesysrecvmmsg net/socket.c:2932 [inline] x64sysrecvmmsg+0xde/0x160 net/socket.c:2932 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2b/0x70 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd

value changed: 0x01 -> 0x00

Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 17869 Comm: syz-executor.2 Not tainted 6.1.0-rc1-syzkaller-00010-gbb1a1146467a-dirty #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022

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.