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

blk-mq: fix null pointer dereference in blkmqclearrqmapping()

Our syzkaller report a null pointer dereference, root cause is following:

blkmqallocmapandrqs set->tags[hctxidx] = blkmqallocmapandrqs blkmqallocmapandrqs blkmqallocrqs // failed due to oom allocpagesnode // set->tags[hctxidx] is still NULL blkmqfreerqs drvtags = set->tags[hctxidx]; // null pointer dereference is triggered blkmqclearrqmapping(drvtags, ...)

This is because commit 63064be150e4 ("blk-mq: Add blkmqallocmapandrqs()") merged the two steps:

1) set->tags[hctxidx] = blkmqallocrqmap() 2) blkmqallocrqs(..., set->tags[hctxidx])

into one step:

set->tags[hctxidx] = blkmqallocmapandrqs()

Since tags is not initialized yet in this case, fix the problem by checking if tags is NULL pointer in blkmqclearrqmapping().

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

tipc: fix an information leak in tipctopsrvkernsubscr

Use a 8-byte write to initialize sub.usrhandle in tipctopsrvkernsubscr(), otherwise four bytes remain uninitialized when issuing setsockopt(..., SOLTIPC, ...). This resulted in an infoleak reported by KMSAN when the packet was received:

===================================================== BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/ioviter.c:169 instrumentcopytouser ./include/linux/instrumented.h:121 copyout+0xbc/0x100 lib/ioviter.c:169 copytoiter+0x5c0/0x20a0 lib/ioviter.c:527 copytoiter ./include/linux/uio.h:176 simplecopytoiter+0x64/0xa0 net/core/datagram.c:513 skbdatagramiter+0x123/0xdc0 net/core/datagram.c:419 skbcopydatagramiter+0x58/0x200 net/core/datagram.c:527 skbcopydatagrammsg ./include/linux/skbuff.h:3903 packetrecvmsg+0x521/0x1e70 net/packet/afpacket.c:3469 sysrecvmsg+0x2c4/0x810 net/socket.c:? sysrecvmsg+0x217/0x840 net/socket.c:2743 sysrecvmsg net/socket.c:2773 dosysrecvmsg net/socket.c:2783 sesysrecvmsg net/socket.c:2780 x64sysrecvmsg+0x364/0x540 net/socket.c:2780 dosyscallx64 arch/x86/entry/common.c:50 dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd arch/x86/entry/entry64.S:120

...

Uninit was stored to memory at: tipcsubsubscribe+0x42d/0xb50 net/tipc/subscr.c:156 tipcconnrcvsub+0x246/0x620 net/tipc/topsrv.c:375 tipctopsrvkernsubscr+0x2e8/0x400 net/tipc/topsrv.c:579 tipcgroupcreate+0x4e7/0x7d0 net/tipc/group.c:190 tipcskjoin+0x2a8/0x770 net/tipc/socket.c:3084 tipcsetsockopt+0xae5/0xe40 net/tipc/socket.c:3201 syssetsockopt+0x87f/0xdc0 net/socket.c:2252 dosyssetsockopt net/socket.c:2263 sesyssetsockopt net/socket.c:2260 x64syssetsockopt+0xe0/0x160 net/socket.c:2260 dosyscallx64 arch/x86/entry/common.c:50 dosyscall64+0x3d/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd arch/x86/entry/entry64.S:120

Local variable sub created at: tipctopsrvkernsubscr+0x57/0x400 net/tipc/topsrv.c:562 tipcgroupcreate+0x4e7/0x7d0 net/tipc/group.c:190

Bytes 84-87 of 88 are uninitialized Memory access of size 88 starts at ffff88801ed57cd0 Data copied to user address 0000000020000400 ... =====================================================

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

drbd: only clone bio if we have a backing device

Commit c347a787e34cb (drbd: set ->bibdev in drbdreqnew) moved a biosetdev call (which has since been removed) to "earlier", from drbdrequestprepare to drbdreqnew.

The problem is that this accesses device->ldev->backingbdev, which is not NULL-checked at this point. When we don't have an ldev (i.e. when the DRBD device is diskless), this leads to a null pointer deref.

So, only allocate the privatebio if we actually have a disk. This is also a small optimization, since we don't clone the bio to only to immediately free it again in the diskless case.

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:

iommu/vt-d: Clean up sidomain in the initdmars() error path

A splat from kmemcachedestroy() was seen with a kernel prior to commit ee2653bbe89d ("iommu/vt-d: Remove domain and devinfo mempool") when there was a failure in initdmars(), because the iommudomain cache still had objects. While the mempool code is now gone, there still is a leak of the sidomain memory if initdmars() fails. So clean up sidomain in the initdmars() error path.

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:

cifs: Fix xid leak in cifsflock()

If not flock, before return -ENOLCK, should free the xid, otherwise, the xid will be leaked.

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

net: sched: cake: fix null pointer access issue when cakeinit() fails

When the default qdisc is cake, if the qdisc of devqueue fails to be inited during mqprioinit(), cakereset() is invoked to clear resources. In this case, the tins is NULL, and it will cause gpf issue.

The process is as follows: qdisccreatedflt() cakeinit() q->tins = kvcalloc(...) --->failed, q->tins is NULL ... qdiscput() ... cakereset() ... cakedequeueone() b = &q->tins[...] --->q->tins is NULL

The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] RIP: 0010:cakedequeueone+0xc9/0x3c0 Call Trace: <TASK> cakereset+0xb1/0x140 qdiscreset+0xed/0x6f0 qdiscdestroy+0x82/0x4c0 qdiscput+0x9e/0xb0 qdisccreatedflt+0x2c3/0x4a0 mqprioinit+0xa71/0x1760 qdisccreate+0x3eb/0x1000 tcmodifyqdisc+0x408/0x1720 rtnetlinkrcvmsg+0x38e/0xac0 netlinkrcvskb+0x12d/0x3a0 netlinkunicast+0x4a2/0x740 netlinksendmsg+0x826/0xcc0 socksendmsg+0xc5/0x100 syssendmsg+0x583/0x690 syssendmsg+0xe8/0x160 syssendmsg+0xbf/0x160 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7f89e5122d04 </TASK>

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:

x86/fpu: Fix copyxstatetouabi() to copy init states correctly

When an extended state component is not present in fpstate, but in init state, the function copies from initfpstate via copyfeature().

But, dynamic states are not present in initfpstate because of all-zeros init states. Then retrieving them from initfpstate will explode like this:

BUG: kernel NULL pointer dereference, address: 0000000000000000 ... RIP: 0010:memcpyerms+0x6/0x10 ? copyxstatetouabibuf+0x381/0x870 fpucopyguestfpstatetouabi+0x28/0x80 kvmarchvcpuioctl+0x14c/0x1460 [kvm] ? thiscpupreemptcheck+0x13/0x20 ? vmxvcpuput+0x2e/0x260 [kvmintel] kvmvcpuioctl+0xea/0x6b0 [kvm] ? kvmvcpuioctl+0xea/0x6b0 [kvm] ? fgetlight+0xd4/0x130 x64sysioctl+0xe3/0x910 ? debugsmpprocessorid+0x17/0x20 ? fpregsassertstateconsistent+0x27/0x50 dosyscall64+0x3f/0x90 entrySYSCALL64afterhwframe+0x63/0xcd

Adjust the 'mask' to zero out the userspace buffer for the features that are not available both from fpstate and from initfpstate.

The dynamic features depend on the compacted XSAVE format. Ensure it is enabled before reading XCOMPBV in initfpstate.

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:

cifs: Fix memory leak when build ntlmssp negotiate blob failed

There is a memory leak when mount cifs: unreferenced object 0xffff888166059600 (size 448): comm "mount.cifs", pid 51391, jiffies 4295596373 (age 330.596s) hex dump (first 32 bytes): fe 53 4d 42 40 00 00 00 00 00 00 00 01 00 82 00 .SMB@........... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000060609a61>] mempoolalloc+0xe1/0x260 [<00000000adfa6c63>] cifssmallbufget+0x24/0x60 [<00000000ebb404c7>] smb2plainreqinit+0x32/0x460 [<00000000bcf875b4>] SMB2sessallocbuffer+0xa4/0x3f0 [<00000000753a2987>] SMB2sessauthrawntlmsspnegotiate+0xf5/0x480 [<00000000f0c1f4f9>] SMB2sesssetup+0x253/0x410 [<00000000a8b83303>] cifssetupsession+0x18f/0x4c0 [<00000000854bd16d>] cifsgetsmbses+0xae7/0x13c0 [<000000006cbc43d9>] mountgetconns+0x7a/0x730 [<000000005922d816>] cifsmount+0x103/0xd10 [<00000000e33def3b>] cifssmb3domount+0x1dd/0xc90 [<0000000078034979>] smb3gettree+0x1d5/0x300 [<000000004371f980>] vfsgettree+0x41/0xf0 [<00000000b670d8a7>] pathmount+0x9b3/0xdd0 [<000000005e839a7d>] x64sysmount+0x190/0x1d0 [<000000009404c3b9>] dosyscall64+0x35/0x80

When build ntlmssp negotiate blob failed, the session setup request should be freed.

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: sched: sfb: fix null pointer access issue when sfbinit() fails

When the default qdisc is sfb, if the qdisc of devqueue fails to be inited during mqprioinit(), sfbreset() is invoked to clear resources. In this case, the q->qdisc is NULL, and it will cause gpf issue.

The process is as follows: qdisccreatedflt() sfbinit() tcfblockget() --->failed, q->qdisc is NULL ... qdiscput() ... sfbreset() qdiscreset(q->qdisc) --->q->qdisc is NULL ops = qdisc->ops

The following is the Call Trace information: general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f] RIP: 0010:qdiscreset+0x2b/0x6f0 Call Trace: <TASK> sfbreset+0x37/0xd0 qdiscreset+0xed/0x6f0 qdiscdestroy+0x82/0x4c0 qdiscput+0x9e/0xb0 qdisccreatedflt+0x2c3/0x4a0 mqprioinit+0xa71/0x1760 qdisccreate+0x3eb/0x1000 tcmodifyqdisc+0x408/0x1720 rtnetlinkrcvmsg+0x38e/0xac0 netlinkrcvskb+0x12d/0x3a0 netlinkunicast+0x4a2/0x740 netlinksendmsg+0x826/0xcc0 socksendmsg+0xc5/0x100 syssendmsg+0x583/0x690 syssendmsg+0xe8/0x160 syssendmsg+0xbf/0x160 dosyscall64+0x35/0x80 entrySYSCALL64afterhwframe+0x46/0xb0 RIP: 0033:0x7f2164122d04 </TASK>

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

net: hns: fix possible memory leak in hnaeaeregister()

Inject fault while probing module, if deviceregister() fails, but the refcount of kobject is not decreased to 0, the name allocated in devsetname() is leaked. Fix this by calling putdevice(), so that name can be freed in callback function kobjectcleanup().

unreferenced object 0xffff00c01aba2100 (size 128): comm "systemd-udevd", pid 1259, jiffies 4294903284 (age 294.152s) hex dump (first 32 bytes): 68 6e 61 65 30 00 00 00 18 21 ba 1a c0 00 ff ff hnae0....!...... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<0000000034783f26>] slabpostallochook+0xa0/0x3e0 [<00000000748188f2>] kmemcacheallocnode+0x164/0x2b0 [<00000000ab0743e8>] kmallocnodetrackcaller+0x6c/0x390 [<000000006c0ffb13>] kvasprintf+0x8c/0x118 [<00000000fa27bfe1>] kvasprintfconst+0x60/0xc8 [<0000000083e10ed7>] kobjectsetnamevargs+0x3c/0xc0 [<000000000b87affc>] devsetname+0x7c/0xa0 [<000000003fd8fe26>] hnaeaeregister+0xcc/0x190 [hnae] [<00000000fe97edc9>] hnsdsafaeinit+0x9c/0x108 [hnsdsaf] [<00000000c36ff1eb>] hnsdsafprobe+0x548/0x748 [hnsdsaf]

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

cifs: Fix xid leak in cifscreate()

If the cifs already shutdown, we should free the xid before return, otherwise, the xid will be leaked.

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

wwanhwsim: fix possible memory leak in wwanhwsimdevnew()

Inject fault while probing module, if deviceregister() fails, but the refcount of kobject is not decreased to 0, the name allocated in devsetname() is leaked. Fix this by calling putdevice(), so that name can be freed in callback function kobjectcleanup().

unreferenced object 0xffff88810152ad20 (size 8): comm "modprobe", pid 252, jiffies 4294849206 (age 22.713s) hex dump (first 8 bytes): 68 77 73 69 6d 30 00 ff hwsim0.. backtrace: [<000000009c3504ed>] kmallocnodetrackcaller+0x44/0x1b0 [<00000000c0228a5e>] kvasprintf+0xb5/0x140 [<00000000cff8c21f>] kvasprintfconst+0x55/0x180 [<0000000055a1e073>] kobjectsetnamevargs+0x56/0x150 [<000000000a80b139>] devsetname+0xab/0xe0

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:

iouring/msgring: Fix NULL pointer dereference in iomsgsendfd()

Syzkaller produced the below call trace:

BUG: KASAN: null-ptr-deref in iomsgring+0x3cb/0x9f0 Write of size 8 at addr 0000000000000070 by task repro/16399

CPU: 0 PID: 16399 Comm: repro Not tainted 6.1.0-rc1 #28 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 Call Trace: <TASK> dumpstacklvl+0xcd/0x134 ? iomsgring+0x3cb/0x9f0 kasanreport+0xbc/0xf0 ? iomsgring+0x3cb/0x9f0 kasancheckrange+0x140/0x190 iomsgring+0x3cb/0x9f0 ? iomsgringprep+0x300/0x300 ioissuesqe+0x698/0xca0 iosubmitsqes+0x92f/0x1c30 dosysiouringenter+0xae4/0x24b0 .... RIP: 0033:0x7f2eaf8f8289 RSP: 002b:00007fff40939718 EFLAGS: 00000246 ORIGRAX: 00000000000001aa RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f2eaf8f8289 RDX: 0000000000000000 RSI: 0000000000006f71 RDI: 0000000000000004 RBP: 00007fff409397a0 R08: 0000000000000000 R09: 0000000000000039 R10: 0000000000000000 R11: 0000000000000246 R12: 00000000004006d0 R13: 00007fff40939880 R14: 0000000000000000 R15: 0000000000000000 </TASK> Kernel panic - not syncing: paniconwarn set ...

We don't have a NULL check on fileptr in iomsgsendfd() function, so when fileptr is NUL srcfile is also NULL and getfile() dereferences a NULL pointer and leads to above crash.

Add a NULL check to fix this issue.

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:

mm,hugetlb: take hugetlblock before decrementing h->resvhugepages

The h->hugepages counters are protected by the hugetlblock, but allochugepage has a corner case where it can decrement the counter outside of the lock.

This could lead to a corrupted value of h->resvhugepages, which we have observed on our systems.

Take the hugetlblock before decrementing h->resvhugepages to avoid a potential race.

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:

media: ov8865: Fix an error handling path in ov8865probe()

The commit in Fixes also introduced some new error handling which should goto the existing error handling path. Otherwise some resources leak.

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