A use-after-free flaw was found in reconnsetipaddrfromhostname in fs/cifs/connect.c in the Linux kernel. The issue occurs when it forgets to set the free pointer server->hostname to NULL, leading to an invalid pointer request.

A flaw in the Linux Kernel found. If napi frags enabled and patch 363a5328f4b0 ("net: tun: fix bugs for oversize packet when napi frags enabled") not applied, then when local user try to send too large IPV6 packet (with big packet length), it can lead to out of bounds memory bug.

Reference: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=363a5328f4b0

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.

A use-after-free flaw was found in qdiscgraft in net/sched/schapi.c in the Linux Kernel due to a race problem leading to a denial-of-service problem.

Reference: https://lore.kernel.org/all/20221018203258.2793282-1-edumazet@google.com/

Crash: BUG: KASAN: use-after-free in tcfqdiscfind.part.0+0xa3a/0xac0 net/sched/clsapi.c:1066 Read of size 4 at addr ffff88802065e038 by task syz-executor.4/21027 CPU: 0 PID: 21027 Comm: syz-executor.4 Not tainted 6.0.0-rc3-syzkaller-00363-g7726d4c3e60b #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022 Call Trace: <TASK> dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0xcd/0x134 lib/dumpstack.c:106 printaddressdescription mm/kasan/report.c:317 [inline] printreport.cold+0x2ba/0x719 mm/kasan/report.c:433 kasanreport+0xb1/0x1e0 mm/kasan/report.c:495 tcfqdiscfind.part.0+0xa3a/0xac0 net/sched/clsapi.c:1066 tcfqdiscfind net/sched/clsapi.c:1051 [inline] tcnewtfilter+0x34f/0x2200 net/sched/clsapi.c:2018 rtnetlinkrcvmsg+0x955/0xca0 net/core/rtnetlink.c:6081 netlinkrcvskb+0x153/0x420 net/netlink/afnetlink.c:2501 netlinkunicastkernel net/netlink/afnetlink.c:1319 [inline] netlinkunicast+0x543/0x7f0 net/netlink/afnetlink.c:1345 netlinksendmsg+0x917/0xe10 net/netlink/afnetlink.c:1921 socksendmsgnosec net/socket.c:714 [inline] socksendmsg+0xcf/0x120 net/socket.c:734 syssendmsg+0x6eb/0x810 net/socket.c:2482 syssendmsg+0x110/0x1b0 net/socket.c:2536 syssendmsg+0xf3/0x1c0 net/socket.c:2565 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x35/0xb0 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7f5efaa89279

A data race flaw was found in the Linux kernel, between where con is allocated and con->sock is set. This issue leads to a NULL pointer dereference when accessing con->sock->sk in net/tipc/topsrv.c in the tipc protocol in the Linux kernel.

A known cache speculation vulnerability, known as Branch History Injection (BHI) or Spectre-BHB, becomes actual again for the new hw AmpereOne. Spectre-BHB is similar to Spectre v2, except that malicious code uses the shared branch history (stored in the CPU Branch History Buffer, or BHB) to influence mispredicted branches within the victim's hardware context. Once that occurs, speculation caused by the mispredicted branches can cause cache allocation. This issue leads to obtaining information that should not be accessible.

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:

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:

xhci: Remove device endpoints from bandwidth list when freeing the device

Endpoints are normally deleted from the bandwidth list when they are dropped, before the virt device is freed.

If xHC host is dying or being removed then the endpoints aren't dropped cleanly due to functions returning early to avoid interacting with a non-accessible host controller.

So check and delete endpoints that are still on the bandwidth list when freeing the virt device.

Solves a listdel corruption kernel crash when unbinding xhci-pci, caused by xhcimemcleanup() when it later tried to delete already freed endpoints from the bandwidth list.

This only affects hosts that use software bandwidth checking, which currenty is only the xHC in intel Panther Point PCH (Ivy Bridge)

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

tipc: fix a null-ptr-deref in tipctopsrvaccept

syzbot found a crash in tipctopsrvaccept:

KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f] Workqueue: tipcrcv tipctopsrvaccept RIP: 0010:kernelaccept+0x22d/0x350 net/socket.c:3487 Call Trace: <TASK> tipctopsrvaccept+0x197/0x280 net/tipc/topsrv.c:460 processonework+0x991/0x1610 kernel/workqueue.c:2289 workerthread+0x665/0x1080 kernel/workqueue.c:2436 kthread+0x2e4/0x3a0 kernel/kthread.c:376 retfromfork+0x1f/0x30 arch/x86/entry/entry64.S:306

It was caused by srv->listener that might be set to null by tipctopsrvstop() in net .exit whereas it's still used in tipctopsrvaccept() worker.

srv->listener is protected by srv->idrlock in tipctopsrvstop(), so add a check for srv->listener under srv->idrlock in tipctopsrvaccept() to avoid the null-ptr-deref. To ensure the lsock is not released during the tipctopsrvaccept(), move sockrelease() after tipctopsrvworkstop() where it's waiting until the tipctopsrvaccept worker to be done.

Note that skcallbacklock is used to protect sk->skuserdata instead of srv->listener, and it should check srv in tipctopsrvlistenerdataready() instead. This also ensures that no more tipctopsrvaccept worker will be started after tipcconnclose() is called in tipctopsrvstop() where it sets sk->skuserdata to null.

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:

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:

drm/msm/dsi: fix memory corruption with too many bridges

Add the missing sanity check on the bridge counter to avoid corrupting data beyond the fixed-sized bridge array in case there are ever more than eight bridges.

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

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:

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:

drm/msm: fix use-after-free on probe deferral

The bridge counter was never reset when tearing down the DRM device so that stale pointers to deallocated structures would be accessed on the next tear down (e.g. after a second late bind deferral).

Given enough bridges and a few probe deferrals this could currently also lead to data beyond the bridge array being corrupted.

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

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:

ata: ahci: Match EMMAXSLOTS with SATAPMPMAXPORTS

UBSAN complains about array-index-out-of-bounds: [ 1.980703] kernel: UBSAN: array-index-out-of-bounds in /build/linux-9H675w/linux-5.15.0/drivers/ata/libahci.c:968:41 [ 1.980709] kernel: index 15 is out of range for type 'ahciempriv [8]' [ 1.980713] kernel: CPU: 0 PID: 209 Comm: scsieh8 Not tainted 5.15.0-25-generic #25-Ubuntu [ 1.980716] kernel: Hardware name: System manufacturer System Product Name/P5Q3, BIOS 1102 06/11/2010 [ 1.980718] kernel: Call Trace: [ 1.980721] kernel: <TASK> [ 1.980723] kernel: showstack+0x52/0x58 [ 1.980729] kernel: dumpstacklvl+0x4a/0x5f [ 1.980734] kernel: dumpstack+0x10/0x12 [ 1.980736] kernel: ubsanepilogue+0x9/0x45 [ 1.980739] kernel: ubsanhandleoutofbounds.cold+0x44/0x49 [ 1.980742] kernel: ahciqcissue+0x166/0x170 [libahci] [ 1.980748] kernel: ataqcissue+0x135/0x240 [ 1.980752] kernel: ataexecinternalsg+0x2c4/0x580 [ 1.980754] kernel: ? vprintkdefault+0x1d/0x20 [ 1.980759] kernel: ataexecinternal+0x67/0xa0 [ 1.980762] kernel: satapmpread+0x8d/0xc0 [ 1.980765] kernel: satapmpreadgscr+0x3c/0x90 [ 1.980768] kernel: satapmpattach+0x8b/0x310 [ 1.980771] kernel: ataehrevalidateandattach+0x28c/0x4b0 [ 1.980775] kernel: ataehrecover+0x6b6/0xb30 [ 1.980778] kernel: ? ahcidohardreset+0x180/0x180 [libahci] [ 1.980783] kernel: ? ahcistopengine+0xb0/0xb0 [libahci] [ 1.980787] kernel: ? ahcidosoftreset+0x290/0x290 [libahci] [ 1.980792] kernel: ? traceeventraweventataehlinkautopsyqc+0xe0/0xe0 [ 1.980795] kernel: satapmpehrecover.isra.0+0x214/0x560 [ 1.980799] kernel: satapmperrorhandler+0x23/0x40 [ 1.980802] kernel: ahcierrorhandler+0x43/0x80 [libahci] [ 1.980806] kernel: atascsiporterrorhandler+0x2b1/0x600 [ 1.980810] kernel: atascsierror+0x9c/0xd0 [ 1.980813] kernel: scsierrorhandler+0xa1/0x180 [ 1.980817] kernel: ? scsiunjamhost+0x1c0/0x1c0 [ 1.980820] kernel: kthread+0x12a/0x150 [ 1.980823] kernel: ? setkthreadstruct+0x50/0x50 [ 1.980826] kernel: retfromfork+0x22/0x30 [ 1.980831] kernel: </TASK>

This happens because satapmpinitlinks() initialize link->pmp up to SATAPMPMAXPORTS while empriv is declared as 8 elements array.

I can't find the maximum Enclosure Management ports specified in AHCI spec v1.3.1, but "12.2.1 LED message type" states that "Port Multiplier Information" can utilize 4 bits, which implies it can support up to 16 ports. Hence, use SATAPMPMAXPORTS as EMMAXSLOTS to resolve the issue.

BugLink: https://bugs.launchpad.net/bugs/1970074

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

media: atomisp: prevent integer overflow in shcsssetblackframe()

The "height" and "width" values come from the user so the "height width" multiplication can overflow.

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:

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:

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:

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:

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:

s390/cio: fix out-of-bounds access on cioignore free

The channel-subsystem-driver scans for newly available devices whenever device-IDs are removed from the cioignore list using a command such as:

echo free >/proc/cioignore

Since an I/O device scan might interfer with running I/Os, commit 172da89ed0ea ("s390/cio: avoid excessive path-verification requests") introduced an optimization to exclude online devices from the scan.

The newly added check for online devices incorrectly assumes that an I/O-subchannel's drvdata points to a struct iosubchannelprivate. For devices that are bound to a non-default I/O subchannel driver, such as the vfioccw driver, this results in an out-of-bounds read access during each scan.

Fix this by changing the scan logic to rely on a driver-independent online indication. For this we can use struct subchannel->config.ena, which is the driver's requested subchannel-enabled state. Since I/Os can only be started on enabled subchannels, this matches the intent of the original optimization of not scanning devices where I/O might be running.

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:

cifs: Fix xid leak in cifscreate()

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