drm/amdgpu: Fix possible NULL dereference in amdgpurasqueryerrorstatushelper()

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

iommufd: Fix protection fault in iommufdtestsyzconviova

Syzkaller reported the following bug:

general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] Call Trace: lockacquire lockacquire+0x1ce/0x4f0 downread+0x93/0x4a0 iommufdtestsyzconviova+0x56/0x1f0 iommufdtestaccessrw.isra.0+0x2ec/0x390 iommufdtest+0x1058/0x1e30 iommufdfopsioctl+0x381/0x510 vfsioctl dosysioctl sesysioctl x64sysioctl+0x170/0x1e0 dosyscallx64 dosyscall64+0x71/0x140

This is because the new iommufdaccesschangeioas() sets access->ioas to NULL during its process, so the lock might be gone in a concurrent racing context.

Fix this by doing the same access->ioas sanity as iommufdaccessrw() and iommufdaccesspinpages() functions do.

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

memcg: fix soft lockup in the OOM process

A soft lockup issue was found in the product with about 56,000 tasks were in the OOM cgroup, it was traversing them when the soft lockup was triggered.

watchdog: BUG: soft lockup - CPU#2 stuck for 23s! [VM Thread:1503066] CPU: 2 PID: 1503066 Comm: VM Thread Kdump: loaded Tainted: G Hardware name: Huawei Cloud OpenStack Nova, BIOS RIP: 0010:consoleunlock+0x343/0x540 RSP: 0000:ffffb751447db9a0 EFLAGS: 00000247 ORIGRAX: ffffffffffffff13 RAX: 0000000000000001 RBX: 0000000000000000 RCX: 00000000ffffffff RDX: 0000000000000000 RSI: 0000000000000004 RDI: 0000000000000247 RBP: ffffffffafc71f90 R08: 0000000000000000 R09: 0000000000000040 R10: 0000000000000080 R11: 0000000000000000 R12: ffffffffafc74bd0 R13: ffffffffaf60a220 R14: 0000000000000247 R15: 0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f2fe6ad91f0 CR3: 00000004b2076003 CR4: 0000000000360ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: vprintkemit+0x193/0x280 printk+0x52/0x6e dumptask+0x114/0x130 memcgroupscantasks+0x76/0x100 dumpheader+0x1fe/0x210 oomkillprocess+0xd1/0x100 outofmemory+0x125/0x570 memcgroupoutofmemory+0xb5/0xd0 trycharge+0x720/0x770 memcgrouptrycharge+0x86/0x180 memcgrouptrychargedelay+0x1c/0x40 doanonymouspage+0xb5/0x390 handlemmfault+0xc4/0x1f0

This is because thousands of processes are in the OOM cgroup, it takes a long time to traverse all of them. As a result, this lead to soft lockup in the OOM process.

To fix this issue, call 'condresched' in the 'memcgroupscantasks' function per 1000 iterations. For global OOM, call 'touchsoftlockupwatchdog' per 1000 iterations to avoid this issue.

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

ipv4: iptunnel: Fix suspicious RCU usage warning in iptunnelfind()

The per-netns IP tunnel hash table is protected by the RTNL mutex and iptunnelfind() is only called from the control path where the mutex is taken.

Add a lockdep expression to hlistforeachentryrcu() in iptunnelfind() in order to validate that the mutex is held and to silence the suspicious RCU usage warning [1].

[1] WARNING: suspicious RCU usage 6.12.0-rc3-custom-gd95d9a31aceb #139 Not tainted ----------------------------- net/ipv4/iptunnel.c:221 RCU-list traversed in non-reader section!!

other info that might help us debug this:

rcuscheduleractive = 2, debuglocks = 1 1 lock held by ip/362: #0: ffffffff86fc7cb0 (rtnlmutex){+.+.}-{3:3}, at: rtnetlinkrcvmsg+0x377/0xf60

stack backtrace: CPU: 12 UID: 0 PID: 362 Comm: ip Not tainted 6.12.0-rc3-custom-gd95d9a31aceb #139 Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 Call Trace: <TASK> dumpstacklvl+0xba/0x110 lockdeprcususpicious.cold+0x4f/0xd6 iptunnelfind+0x435/0x4d0 iptunnelnewlink+0x517/0x7a0 ipgrenewlink+0x14c/0x170 rtnlnewlink+0x1173/0x19c0 rtnlnewlink+0x6c/0xa0 rtnetlinkrcvmsg+0x3cc/0xf60 netlinkrcvskb+0x171/0x450 netlinkunicast+0x539/0x7f0 netlinksendmsg+0x8c1/0xd80 syssendmsg+0x8f9/0xc20 syssendmsg+0x197/0x1e0 syssendmsg+0x122/0x1f0 dosyscall64+0xbb/0x1d0 entrySYSCALL64afterhwframe+0x77/0x7f

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

RDMA/bnxtre: Avoid CPU lockups due fifo occupancy check loop

Driver waits indefinitely for the fifo occupancy to go below a threshold as soon as the pacing interrupt is received. This can cause soft lockup on one of the processors, if the rate of DB is very high.

Add a loop count for FPGA and exit the waitforfifooccupancybelowth if the loop is taking more time. Pacing will be continuing until the occupancy is below the threshold. This is ensured by the checks in bnxtrepacingtimerexp and further scheduling the work for pacing based on the fifo occupancy.

drm/amd/display: Add NULL pointer check for kzalloc

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

virtionet: Fix napiskbcacheput warning

After the commit bdacf3e34945 ("net: Use nested-BH locking for napialloccache.") was merged, the following warning began to appear:

WARNING: CPU: 5 PID: 1 at net/core/skbuff.c:1451 napiskbcacheput+0x82/0x4b0

warn+0x12f/0x340 napiskbcacheput+0x82/0x4b0 napiskbcacheput+0x82/0x4b0 reportbug+0x165/0x370 handlebug+0x3d/0x80 excinvalidop+0x1a/0x50 asmexcinvalidop+0x1a/0x20 freeoldxmit+0x1c8/0x510 napiskbcacheput+0x82/0x4b0 freeoldxmit+0x1c8/0x510 freeoldxmit+0x1c8/0x510 pfxfreeoldxmit+0x10/0x10

The issue arises because virtio is assuming it's running in NAPI context even when it's not, such as in the netpoll case.

To resolve this, modify virtnetpolltx() to only set NAPI when budget is available. Same for virtnetpollcleantx(), which always assumed that it was in a NAPI context.

blk-mq: fix IO hang from sbitmap wakeup race

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

tracing: Ensure visibility when inserting an element into tracingmap

Running the following two commands in parallel on a multi-processor AArch64 machine can sporadically produce an unexpected warning about duplicate histogram entries:

$ while true; do echo hist:key=id.syscall:val=hitcount > \ /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/trigger cat /sys/kernel/debug/tracing/events/rawsyscalls/sysenter/hist sleep 0.001 done $ stress-ng --sysbadaddr $(nproc)

The warning looks as follows:

[ 2911.172474] ------------[ cut here ]------------ [ 2911.173111] Duplicates detected: 1 [ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracingmap.c:983 tracingmapsortentries+0x3e0/0x408 [ 2911.174702] Modules linked in: iscsiibft(E) iscsibootsysfs(E) rfkill(E) afpacket(E) nlsiso88591(E) nlscp437(E) vfat(E) fat(E) ena(E) tinypowerbutton(E) qemufwcfg(E) button(E) fuse(E) efipstore(E) iptables(E) xtables(E) xfs(E) libcrc32c(E) aesceblk(E) aescecipher(E) crct10difce(E) polyvalce(E) polyvalgeneric(E) ghashce(E) gf128mul(E) sm4cegcm(E) sm4ceccm(E) sm4ce(E) sm4cecipher(E) sm4(E) sm3ce(E) sm3(E) sha3ce(E) sha512ce(E) sha512arm64(E) sha2ce(E) sha256arm64(E) nvme(E) sha1ce(E) nvmecore(E) nvmeauth(E) t10pi(E) sg(E) scsimod(E) scsicommon(E) efivarfs(E) [ 2911.174738] Unloaded tainted modules: cppccpufreq(E):1 [ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G E 6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01 [ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018 [ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--) [ 2911.184038] pc : tracingmapsortentries+0x3e0/0x408 [ 2911.184667] lr : tracingmapsortentries+0x3e0/0x408 [ 2911.185310] sp : ffff8000a1513900 [ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001 [ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008 [ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180 [ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff [ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8 [ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731 [ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c [ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8 [ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000 [ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480 [ 2911.194259] Call trace: [ 2911.194626] tracingmapsortentries+0x3e0/0x408 [ 2911.195220] histshow+0x124/0x800 [ 2911.195692] seqreaditer+0x1d4/0x4e8 [ 2911.196193] seqread+0xe8/0x138 [ 2911.196638] vfsread+0xc8/0x300 [ 2911.197078] ksysread+0x70/0x108 [ 2911.197534] arm64sysread+0x24/0x38 [ 2911.198046] invokesyscall+0x78/0x108 [ 2911.198553] el0svccommon.constprop.0+0xd0/0xf8 [ 2911.199157] doel0svc+0x28/0x40 [ 2911.199613] el0svc+0x40/0x178 [ 2911.200048] el0t64synchandler+0x13c/0x158 [ 2911.200621] el0t64sync+0x1a8/0x1b0 [ 2911.201115] ---[ end trace 0000000000000000 ]---

The problem appears to be caused by CPU reordering of writes issued from tracingmapinsert().

The check for the presence of an element with a given key in this function is:

val = READONCE(entry->val); if (val && keysmatch(key, val->key, map->keysize)) ...

The write of a new entry is:

elt = getfreeelt(map); memcpy(elt->key, key, map->keysize); entry->val = elt;

The "memcpy(elt->key, key, map->keysize);" and "entry->val = elt;" stores may become visible in the reversed order on another CPU. This second CPU might then incorrectly determine that a new key doesn't match an already present val->key and subse ---truncated---

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

md: fix kmemleak of rdev->serial

If kobjectadd() is fail in bindrdevtoarray(), 'rdev->serial' will be alloc not be freed, and kmemleak occurs.

unreferenced object 0xffff88815a350000 (size 49152): comm "mdadm", pid 789, jiffies 4294716910 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 (crc f773277a): [<0000000058b0a453>] kmemleakalloc+0x61/0xe0 [<00000000366adf14>] kmalloclargenode+0x15e/0x270 [<000000002e82961b>] kmallocnode.cold+0x11/0x7f [<00000000f206d60a>] kvmallocnode+0x74/0x150 [<0000000034bf3363>] rdevinitserial+0x67/0x170 [<0000000010e08fe9>] mddevcreateserialpool+0x62/0x220 [<00000000c3837bf0>] bindrdevtoarray+0x2af/0x630 [<0000000073c28560>] mdaddnewdisk+0x400/0x9f0 [<00000000770e30ff>] mdioctl+0x15bf/0x1c10 [<000000006cfab718>] blkdevioctl+0x191/0x3f0 [<0000000085086a11>] vfsioctl+0x22/0x60 [<0000000018b656fe>] x64sysioctl+0xba/0xe0 [<00000000e54e675e>] dosyscall64+0x71/0x150 [<000000008b0ad622>] entrySYSCALL64afterhwframe+0x6c/0x74

fs/proc: dotaskstat: use sig->statslock to gather the threads/children stats

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

ipvs: fix uninit-value for saddr in dooutputroute4

syzbot reports for uninit-value for the saddr argument [1]. commit 4754957f04f5 ("ipvs: do not use random local source address for tunnels") already implies that the input value of saddr should be ignored but the code is still reading it which can prevent to connect the route. Fix it by changing the argument to retsaddr.

[1] BUG: KMSAN: uninit-value in dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 dooutputroute4+0x42c/0x4d0 net/netfilter/ipvs/ipvsxmit.c:147 ipvsgetoutrt+0x403/0x21d0 net/netfilter/ipvs/ipvsxmit.c:330 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e

Uninit was created at: slabpostallochook mm/slub.c:4167 [inline] slaballocnode mm/slub.c:4210 [inline] kmalloccachenoprof+0x8fa/0xe00 mm/slub.c:4367 kmallocnoprof include/linux/slab.h:905 [inline] ipvsdestdstalloc net/netfilter/ipvs/ipvsxmit.c:61 [inline] ipvsgetoutrt+0x35d/0x21d0 net/netfilter/ipvs/ipvsxmit.c:323 ipvstunnelxmit+0x205/0x2380 net/netfilter/ipvs/ipvsxmit.c:1136 ipvsinhook+0x1aa5/0x35b0 net/netfilter/ipvs/ipvscore.c:2063 nfhookentryhookfn include/linux/netfilter.h:154 [inline] nfhookslow+0xf7/0x400 net/netfilter/core.c:626 nfhook include/linux/netfilter.h:269 [inline] iplocalout+0x758/0x7e0 net/ipv4/ipoutput.c:118 iplocalout net/ipv4/ipoutput.c:127 [inline] ipsendskb+0x6a/0x3c0 net/ipv4/ipoutput.c:1501 udpsendskb+0xfda/0x1b70 net/ipv4/udp.c:1195 udpsendmsg+0x2fe3/0x33c0 net/ipv4/udp.c:1483 inetsendmsg+0x1fc/0x280 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x267/0x380 net/socket.c:727 syssendmsg+0x91b/0xda0 net/socket.c:2566 syssendmsg+0x28d/0x3c0 net/socket.c:2620 syssendmmsg+0x41d/0x880 net/socket.c:2702 compatsyssendmmsg net/compat.c:360 [inline] docompatsyssendmmsg net/compat.c:367 [inline] secompatsyssendmmsg net/compat.c:364 [inline] ia32compatsyssendmmsg+0xc8/0x140 net/compat.c:364 ia32syscall+0x3ffa/0x41f0 arch/x86/include/generated/asm/syscalls32.h:346 dosyscall32irqson arch/x86/entry/syscall32.c:83 [inline] dofastsyscall32+0xb0/0x110 arch/x86/entry/syscall32.c:306 dofastsyscall32+0x38/0x80 arch/x86/entry/syscall32.c:331 doSYSENTER32+0x1f/0x30 arch/x86/entry/syscall32.c:369 entrySYSENTERcompatafterhwframe+0x84/0x8e

CPU: 0 UID: 0 PID: 22408 Comm: syz.4.5165 Not tainted 6.15.0-rc3-syzkaller-00019-gbc3372351d0c #0 PREEMPT(undef) Hardware name: Google Google Compute Engi ---truncated---

drm/amdkfd: debugfs hanghws skip GPU with MES

drm/amdgpu: handle amdgpucgscreatedevice() errors in amdpowerplaycreate()

block: fix resource leak in blkregisterqueue() error path

bpf: Fix deadlock between rcutaskstrace and eventmutex.

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

perf/core: Fix WARNON(!ctx) in freeevent() for partial init

Move the getctx(childctx) call and the childevent->ctx assignment to occur immediately after the child event is allocated. Ensure that childevent->ctx is non-NULL before any subsequent error path within inheritevent calls freeevent(), satisfying the assumptions of the cleanup code.

Details:

There's no clear Fixes tag, because this bug is a side-effect of multiple interacting commits over time (up to 15 years old), not a single regression.

The code initially incremented refcount then assigned context immediately after the childevent was created. Later, an early validity check for childevent was added before the refcount/assignment. Even later, a WARNONONCE() cleanup check was added, assuming event->ctx is valid if the pmuctx is valid. The problem is that the WARNONONCE() could trigger after the initial check passed but before childevent->ctx was assigned, violating its precondition. The solution is to assign childevent->ctx right after its initial validation. This ensures the context exists for any subsequent checks or cleanup routines, resolving the WARNONONCE().

To resolve it, defer the refcount update and childevent->ctx assignment directly after childevent->pmuctx is set but before checking if the parent event is orphaned. The cleanup routine depends on event->pmuctx being non-NULL before it verifies event->ctx is non-NULL. This also maintains the author's original intent of passing in childctx to findgetpmucontext before its refcount/assignment.

[ mingo: Expanded the changelog from another email by Gabriel Shahrouzi. ]

drm/amd/display: Add NULL check for clkmgr and clkmgr->funcs in dcn30inithw

drm/amd/display: Add NULL check for clkmgr in dcn32inithw

drm/amd/display: Pass non-null to dcn20validateapplypipesplitflags

drm/amd/display: Add NULL check for function pointer in dcn32setoutputtransferfunc

drm/amd/display: Add NULL check for function pointer in dcn20setoutputtransferfunc

drm/amd/display: Check null-initialized variables

erofs: handle overlapped pclusters out of crafted images properly

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

rcu-tasks: Fix access non-existent percpu rtpcp variable in rcutasksneedgpcb()

For kernels built with CONFIGFORCENRCPUS=y, the nrcpuids is defined as NRCPUS instead of the number of possible cpus, this will cause the following system panic:

smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setuppercpu: NRCPUS:512 nrcpumaskbits:512 nrcpuids:512 nrnodeids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcutaskstrace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcutasksneedgpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: <TASK> ? die+0x23/0x80 ? pagefaultoops+0xa4/0x180 ? excpagefault+0x152/0x180 ? asmexcpagefault+0x26/0x40 ? rcutasksneedgpcb+0x25d/0x2c0 ? pfxrcutaskskthread+0x40/0x40 rcutasksonegp+0x69/0x180 rcutaskskthread+0x94/0xc0 kthread+0xe8/0x140 ? pfxkthread+0x40/0x40 retfromfork+0x34/0x80 ? pfxkthread+0x40/0x40 retfromforkasm+0x1b/0x80 </TASK>

Considering that there may be holes in the CPU numbers, use the maximum possible cpu number, instead of nrcpuids, for configuring enqueue and dequeue limits.

[ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]

drm/amd/display: Check phantomstream before it is used

cpufreq: amd-pstate: add check for cpufreqcpuget's return value

Bluetooth: MGMT: Add error handling to pairdevice()

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

Input: mtk-pmic-keys - fix possible null pointer dereference

In mtkpmickeysprobe, the regs parameter is only set if the button is parsed in the device tree. However, on hardware where the button is left floating, that node will most likely be removed not to enable that input. In that case the code will try to dereference a null pointer.

Let's use the regs struct instead as it is defined for all supported platforms. Note that it is ok setting the key reg even if that latter is disabled as the interrupt won't be enabled anyway.

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

net: lan743x: Fix memleak issue when GSO enabled

Always map the skb to the LS descriptor. Previously skb was mapped to EXT descriptor when the number of fragments is zero with GSO enabled. Mapping the skb to EXT descriptor prevents it from being freed, leading to a memory leak