In the Linux kernel, the following vulnerability has been resolved:
mm/memory: fix spurious warning when unmapping device-private/exclusive pages
Device private and exclusive entries are only supported for anonymous folios. This condition is tested in migratedevicepages() and makedeviceexclusive() using foliotestanon(). However the unmap path tests this assumption using vmaisanonymous().
This is wrong because whilst anonymous VMAs can only contain folios where foliotestanon() is true the opposite relation does not hold. A folio for which foliotestanon() is true does not imply vmaisanonymous() is true. Such a condition can occur if for example a folio is part of a private filebacked mapping.
In this case vmaisanonymous() is false as the mapping is filebacked, but foliotestanon() may be true, thus permitting devices to migrate the folio to device private memory. This can lead to the following spurious warnings during process teardown:
[ 772.737706] ------------[ cut here ]------------ [ 772.739201] WARNING: mm/memory.c:1754 at unmappagerange.cold+0x26/0x18a, CPU#17: hmm-tests/2041 [ 772.742050] Modules linked in: testhmm nvidiauvm(O) nvidia(O) [ 772.743959] CPU: 17 UID: 0 PID: 2041 Comm: hmm-tests Tainted: G W O 7.0.0+ #387 PREEMPT(full) [ 772.747104] Tainted: [W]=WARN, [O]=OOTMODULE [ 772.748509] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org 04/01/2014 [ 772.752117] RIP: 0010:unmappagerange.cold+0x26/0x18a [ 772.753780] Code: 7e fe ff ff 48 89 4c 24 78 4c 89 44 24 38 e8 f2 ff b1 00 48 8b 4c 24 78 4c 8b 44 24 38 48 8b 44 24 18 48 83 78 48 00 74 04 90 <0f> 0b 90 48 89 ca b8 ff ff 37 00 48 c1 ea 03 48 c1 e0 2a 80 3c 02 [ 772.759602] RSP: 0018:ffff888112607550 EFLAGS: 00010286 [ 772.761310] RAX: ffff88811bbf4dc0 RBX: dffffc0000000000 RCX: ffffea03e9bfffd8 [ 772.763583] RDX: 1ffff1102377e9c1 RSI: 0000000000000008 RDI: ffff88811bbf4e08 [ 772.765914] RBP: 0000000000000006 R08: ffff8881059f7448 R09: ffffed10224c0e68 [ 772.768184] R10: ffff888112607347 R11: 0000000000000001 R12: 0000000000000001 [ 772.770461] R13: ffffea03e9bfffc0 R14: ffff888112607908 R15: ffffea03e9bfffc0 [ 772.772782] FS: 00007f327caa2780(0000) GS:ffff888427b7d000(0000) knlGS:0000000000000000 [ 772.775328] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 772.777187] CR2: 00007f327ca89000 CR3: 00000001994d5000 CR4: 00000000000006f0 [ 772.779135] Call Trace: [ 772.779792] <TASK> [ 772.780317] ? dmirrorintervalinvalidate+0x1a3/0x290 [testhmm] [ 772.781873] ? vmnormalpagepud+0x2b0/0x2b0 [ 772.782992] ? rwlockinit+0x150/0x150 [ 772.784006] ? lockrelease+0x216/0x2b0 [ 772.785008] ? mmunotifierinvalidaterangestart+0x505/0x6e0 [ 772.786522] ? lockrelease+0x216/0x2b0 [ 772.787498] ? unmapsinglevma+0xb6/0x210 [ 772.788573] unmapvmas+0x27d/0x520 [ 772.789506] ? unmapsinglevma+0x210/0x210 [ 772.790607] ? masupdategap.part.0+0x620/0x620 [ 772.791834] unmapregion+0x19e/0x350 [ 772.792769] ? removevma+0x130/0x130 [ 772.793684] ? masallocnodes+0x1f2/0x300 [ 772.794730] vmscompletemunmapvmas+0x8c1/0xe20 [ 772.795926] ? unmapregion+0x350/0x350 [ 772.796917] dovmialignmunmap+0x36a/0x4e0 [ 772.798018] ? lockrelease+0x216/0x2b0 [ 772.799024] ? vmashrink+0x620/0x620 [ 772.799983] dovmimunmap+0x150/0x2c0 [ 772.800939] vmmunmap+0x161/0x2c0 [ 772.801872] ? expanddownwards+0xd60/0xd60 [ 772.802948] ? clockeventsprogramevent+0x1ef/0x540 [ 772.804217] ? lockrelease+0x216/0x2b0 [ 772.805158] x64sysmunmap+0x59/0x80 [ 772.805776] dosyscall64+0xfc/0x670 [ 772.806336] ? irqentryexit+0xda/0x580 [ 772.806976] entrySYSCALL64afterhwframe+0x4b/0x53 [ 772.807772] RIP: 0033:0x7f327cbb2717 [ 772.808323] Code: 73 01 c3 48 8b 0d f9 76 0d 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 0b 00 00 00 0f 05 <48> 3d 01 f0 ff ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: always recover the gpu
Previously, in case there was no more work to do, recover worker wouldn't trigger recovery and would instead rely on the gpu going to sleep and then resuming when more work is submitted.
Recoverworker will first increment the fence of the hung ring so, if there's only one job submitted to a ring and that causes an hang, it will early out.
There's no guarantee that the gpu will suspend and resume before more work is submitted and if the gpu is in a hung state it will stay in that state and probably trigger a timeout again.
Just stop checking and always recover the gpu.
Patchwork: https://patchwork.freedesktop.org/patch/704066/
In the Linux kernel, the following vulnerability has been resolved:
fsnotify: fix inode reference leak in fsnotifyrecalcmask()
fsnotifyrecalcmask() fails to handle the return value of fsnotifyrecalcmask(), which may return an inode pointer that needs to be released via fsnotifydropobject() when the connector's HASIREF flag transitions from set to cleared.
This manifests as a hung task with the following call trace:
INFO: task umount:1234 blocked for more than 120 seconds. Call Trace: schedule schedule fsnotifysbdelete genericshutdownsuper killanonsuper cleanupmnt taskworkrun doexit dogroupexit
The race window that triggers the iref leak:
Thread A (adding mark) Thread B (removing mark) ────────────────────── ──────────────────────── fsnotifyaddmarklocked(): fsnotifyaddmarklist(): spinlock(conn->lock) add markB(evictable) to list spinunlock(conn->lock) return
/ ---- gap: no lock held ---- /
fsnotifydetachmark(markA): spinlock(markA->lock) clear ATTACHED flag on markA spinunlock(markA->lock) fsnotifyputmark(markA)
fsnotifyrecalcmask(): spinlock(conn->lock) fsnotifyrecalcmask(): / markA skipped: ATTACHED cleared / / only markB(evictable) remains / wantiref = false hasiref = true / not yet cleared / -> HASIREF transitions true -> false -> returns inode pointer spinunlock(conn->lock) / BUG: return value discarded! iput() and fsnotifyputsbwatchedobjects() are never called /
Fix this by deferring the transition true -> false of HASIREF flag from fsnotifyrecalcmask() (Thread A) to fsnotifyputmark() (thread B).
In the Linux kernel, the following vulnerability has been resolved:
KVM: nSVM: Avoid clearing VMCBLBR in vmcb12
svmcopylbrs() always marks VMCBLBR dirty in the destination VMCB. However, nestedsvmvmexit() uses it to copy LBRs to vmcb12, and clearing clean bits in vmcb12 is not architecturally defined.
Move vmcbmarkdirty() to callers and drop it for vmcb12.
This also facilitates incoming refactoring that does not pass the entire VMCB to svmcopylbrs().
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix transaction abort on file creation due to name hash collision
If we attempt to create several files with names that result in the same hash, we have to pack them in same dir item and that has a limit inherent to the leaf size. However if we reach that limit, we trigger a transaction abort and turns the filesystem into RO mode. This allows for a malicious user to disrupt a system, without the need to have administration privileges/capabilities.
Reproducer:
$ cat exploit-hash-collisions.sh #!/bin/bash
DEV=/dev/sdi MNT=/mnt/sdi
# Use smallest node size to make the test faster and require fewer file # names that result in hash collision. mkfs.btrfs -f --nodesize 4K $DEV mount $DEV $MNT
# List of names that result in the same crc32c hash for btrfs. declare -a names=( 'foobar' '%a8tYkxfGMLWRGr55QSeQc4PBNH9PCLIvR6jZnkDtUUru1t@RouaUeL:@xGkbO3nCwvLNYeK9vhE628gss:T$yZjZ5l-Nbd6CbC$M=hqE-ujhJICXyIxBvYrIU9-TDC' 'AQci3EUB%shMsg-N%frgU:02ByLs=IPJU0OpgiWit5nexSyxZDncY6WB:=zKZuk5Zy0DD$Ua78%MelgBuMqaHGyKsJUFf9s=UW80PcJmKctb46KveLSiUtNmqrMiL9-Y0Il5Fnam04CGIg=8@U:Z' 'CvVqJpJzueKcuA$wqwePfyu7VxuWNN3ho$p0zi2H8QFYK$7YlEqOhhb%:hHgjhIjW5vnqWHKNP4' 'ET:vk@rFU4tsvMB0$Cp=xQHaYZjvoF%-BTc%wkFW8yaDAPcCYoR%x$FH5O:' 'HwTon%v7SGSP4FE08jBwwiu5aot2CFKXHTeEAa@38fUcNGOWvE@Mz6WBeDHVooaZ6AgsXPkVGwy9l@@ZbNXabUU9csiWrrOp0MWUdfi$EZ3w9GkIqtz7IeOsByOkBOO' 'Ij%2VlFGXSuPvxJGf5UWy6O@1svxGha%b@=%wjkq:CIgE6u7eJOjmQY5qTtxE2Rjbis9@us' 'KBkjG5%9R8K9sOG8UTnAYjxLNAvBmvV5vz3IiZaPmKuLYO03-6asI9lJj4@6Xo$KZicaLWJ3Pv8XEwVeUPMwbHYWwbx0pYvNlGMO9F:ZhHAwyctnGy%eujl%WPd4U2BI7qooOSr85J-C2V$LfY' 'NcRfDfuUQ2=zP8K3CCF5dFcpfiOm6mwenShsAbF%n6GAGC7fT2JFFn:c35X-3aYwoq7jNX5$ZJ6hI3wnZs$7KgGi7wjulffhHNUxAT0fRRLF39vJ@NvaEMxsMO' 'Oj42AQAEzRoTxa5OuSKIr=AlwGMy132v4g3Pdq1GvUG9874YseIFQ6QU' 'Ono7avN5GjC:6dBJ' 'WHmN2gnmaN-9dVDy4aWo:yNGFzz8qsJyJhWEWcud7$QzN2D9R0efIWWEdu5kwWr73NZm4=@CoCDxrrZnRITr-kGtUcfW2:%2am' 'WiFnuTEhAG9FEC6zopQmj-A-$LDQ0T3WULz%ox3UZAPybSV6v1Z$b4LXBi4M4BMBtJZpz93r9xafpB77r:lbwvitWRyo$odnAUYlYMmU4RvgnNd--e=I5hiEjGLETTtaScWlQp8mYsBovZwM2k' 'XKyH=OsOAF3p%uziGFZVr$ivrvhVgD@1u%5RtrV-glvqAwHkK@x7YwlxX3qT6WKKQ%PR56NrUBU2dOAOAdzr2=5nJuKPM-T-$ZpQfCL7phxQbUcb:BZOTPaFExc-qK-gDRCDW2' 'd3uUR6OFEwZr%ns1XH@tbxA@cCPmbBRLdyh7p6V45H$P2$F%w0RqrD3M0g8aGvWpoTFMiBdOTJXjD:JF7=h9a43xBywYAP%r$SPZi%zDg%ql-KvkdUCtF9OLaQlxmd' 'ePTpbnit%hyNm@WELlpKzNZYOzOTf8EQ$sEfkMy1VOfIUu3coyvIr13-Y7Sv5v-Ivax2GoGQRFMU1b3362nktT9WOJf3SpT%z8sZmM3gvYQBDgmKI%%RM-G7hyrhgYflOw%z::ZRcv5O:lDCFm' 'evqk743Y@dvZAiG5J05LROFV@$2%rVWJ2%3nxV72-W7$e$-SK3tuSHA2mBt$qloC5jwNx33GmQUjD%akhBPu=VJ5g$xhlZiaFtTrjeeM5x7dt4cHpX0cZkmfImndYzGmvwQG:$euFYmXn$2rA9mKZ' 'gkgUtnihWXsZQTEkrMAWIxir09k3t7jkIK25t1:cy1XWN0GGqC%FrySdcmU7M8MuPOppkLw3=Dfr0UuBAL4%GFk2$Ma10V1jDRGJje%Xx9EV2ERaWKtjpwiZwh0gCSJsj5UL7CR8RtW5opCVFKGGy8Cky' 'hNgsG8lNRik3PvphqPm0yEH3P%%fYG:kQLY=6O-61Wa6nrVWVGR6TLB09vHOv%g4VQRP8Gzx7VXUY1qvZyS' 'isA7JVzN12xCxVPJZqoLm-pTBuhjjHMvV7o=F:EaClfYNyFGlsfw-Kf%uxdqW-kwk1sPl2vhbjyHU1A6$hz' 'kiJfgcdZFDiOptjgH5PN9-PSyLO4fbk:u52tz35lViXiJ6cx7pwjTtKy-XGaQ5IefmpJ4NZqGsqCsKuqOOBgf9LkUdffHet@Wu' 'lvwtxyhE9:%Q3UxeHiViUyNzJsy:fm38pgb6s25JvdhOAT=1s0$pG25x=LZ2rlHTszj=gN6M4zHZYrqrB49i=pA--@WqWLIuX7o1SSfS@2FSiUZN' 'rC24cw3UBDZ=5qJBUMs9e$=S4Y94ni%Z8639vnrGp=0Hv4z3dNFL0fBLmQ40=EYIY:Z=SLc@QLMSt2zsss2ZXrP7j4=' 'uwGl2s-fFrf@GqS=DQqq2I0LJSsOmM%xzTjS:lzXguE3wChdMoHYtLRKPvfaPOZF2fER@j53evbKa7R%A7r4%YEkD=kicJe@SFiGtXHbKe4gCgPAYbnVn' 'UG37U6KKua2bgc:IHzRs7BnB6FD:2Mt5Cc5NdlsW%$1tyvnfz7S27FvNkroXwAW:mBZLA1@qa9WnDbHCDmQmfPMC9z-Eq6QT0jhhPpqyymaD:R02ghwYo%yx7SAaaq-:x33LYpei$5g8DMl3C' 'y2vjek0FE1PDJC0qpfnN:x8k2wCFZ9xiUF2ege=JnP98R%wxjKkdfEiLWvQzmnW' '8-HCSgH5B%K7P8jaVtQhBXpBk:pE-$P7ts58U0J@iR9YZntMPl7j$s62yAJO@9eanFPS54b=UTw$94C-t=HLxT8n6o9P=QnIxq-f1=Ne2dvhe6WbjEQtc' 'YPPh:IFt2mtR6XWSmjHptXLhbSYu8bMw-JP8@PNyaFkdNFsk$M=xfL6LDKCDM-mSyGA2MBwZ8Dr4=R1D%7-mC ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
misc: bcmvk: Fix possible null-pointer dereferences in bcmvkread()
In the function bcmvkread(), the pointer entry is checked, indicating that it can be NULL. If entry is NULL and rc is set to -EMSGSIZE, the following code may cause null-pointer dereferences:
struct vkmsgblk tmpmsg = entry->tohmsg[0]; setmsgid(&tmpmsg, entry->usrmsgid); tmpmsg.size = entry->tohblks - 1;
To prevent these possible null-pointer dereferences, copy tohmsg, usrmsgid, and tohblks from iter into temporary variables, and return these temporary variables to the application instead of accessing them through a potentially NULL entry.
In the Linux kernel, the following vulnerability has been resolved:
net/sched: actskbedit: fix divide-by-zero in tcfskbedithash()
Commit 38a6f0865796 ("net: sched: support hash selecting tx queue") added SKBEDITFTXQSKBHASH support. The inclusive range size is computed as:
mappingmod = queuemappingmax - queuemapping + 1;
The range size can be 65536 when the requested range covers all possible u16 queue IDs (e.g. queuemapping=0 and queuemappingmax=U16MAX). That value cannot be represented in a u16 and previously wrapped to 0, so tcfskbedithash() could trigger a divide-by-zero:
queuemapping += skbgethash(skb) % params->mappingmod;
Compute mappingmod in a wider type and reject ranges larger than U16MAX to prevent params->mappingmod from becoming 0 and avoid the crash.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: lag: Check for LAG device before creating debugfs
mlx5lagdevaddmdev() may return 0 (success) even when an error occurs that is handled gracefully. Consequently, the initialization flow proceeds to call mlx5ldevadddebugfs() even when there is no valid LAG context.
mlx5ldevadddebugfs() blindly created the debugfs directory and attributes. This exposed interfaces (like the members file) that rely on a valid ldev pointer, leading to potential NULL pointer dereferences if accessed when ldev is NULL.
Add a check to verify that mlx5lagdev(dev) returns a valid pointer before attempting to create the debugfs entries.
EDAC/mc: Fix error path ordering in edacmcalloc()
In the Linux kernel, the following vulnerability has been resolved:
arm64/fpsimd: signal: Allocate SSVE storage when restoring ZA
The code to restore a ZA context doesn't attempt to allocate the task's svestate before setting TIFSME. Consequently, restoring a ZA context can place a task into an invalid state where TIFSME is set but the task's svestate is NULL.
In legitimate but uncommon cases where the ZA signal context was NOT created by the kernel in the context of the same task (e.g. if the task is saved/restored with something like CRIU), we have no guarantee that svestate had been allocated previously. In these cases, userspace can enter streaming mode without trapping while svestate is NULL, causing a later NULL pointer dereference when the kernel attempts to store the register state:
| # ./sigreturn-za | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 | Mem abort info: | ESR = 0x0000000096000046 | EC = 0x25: DABT (current EL), IL = 32 bits | SET = 0, FnV = 0 | EA = 0, S1PTW = 0 | FSC = 0x06: level 2 translation fault | Data abort info: | ISV = 0, ISS = 0x00000046, ISS2 = 0x00000000 | CM = 0, WnR = 1, TnD = 0, TagAccess = 0 | GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 | user pgtable: 4k pages, 52-bit VAs, pgdp=0000000101f47c00 | [0000000000000000] pgd=08000001021d8403, p4d=0800000102274403, pud=0800000102275403, pmd=0000000000000000 | Internal error: Oops: 0000000096000046 [#1] SMP | Modules linked in: | CPU: 0 UID: 0 PID: 153 Comm: sigreturn-za Not tainted 6.19.0-rc1 #1 PREEMPT | Hardware name: linux,dummy-virt (DT) | pstate: 214000c9 (nzCv daIF +PAN -UAO -TCO +DIT -SSBS BTYPE=--) | pc : svesavestate+0x4/0xf0 | lr : fpsimdsaveuserstate+0xb0/0x1c0 | sp : ffff80008070bcc0 | x29: ffff80008070bcc0 x28: fff00000c1ca4c40 x27: 63cfa172fb5cf658 | x26: fff00000c1ca5228 x25: 0000000000000000 x24: 0000000000000000 | x23: 0000000000000000 x22: fff00000c1ca4c40 x21: fff00000c1ca4c40 | x20: 0000000000000020 x19: fff00000ff6900f0 x18: 0000000000000000 | x17: fff05e8e0311f000 x16: 0000000000000000 x15: 028fca8f3bdaf21c | x14: 0000000000000212 x13: fff00000c0209f10 x12: 0000000000000020 | x11: 0000000000200b20 x10: 0000000000000000 x9 : fff00000ff69dcc0 | x8 : 00000000000003f2 x7 : 0000000000000001 x6 : fff00000c1ca5b48 | x5 : fff05e8e0311f000 x4 : 0000000008000000 x3 : 0000000000000000 | x2 : 0000000000000001 x1 : fff00000c1ca5970 x0 : 0000000000000440 | Call trace: | svesavestate+0x4/0xf0 (P) | fpsimdthreadswitch+0x48/0x198 | switchto+0x20/0x1c0 | schedule+0x36c/0xce0 | schedule+0x34/0x11c | exittousermodeloop+0x124/0x188 | el0interrupt+0xc8/0xd8 | el0irqhandlercommon+0x18/0x24 | el0t64irqhandler+0x10/0x1c | el0t64irq+0x198/0x19c | Code: 54000040 d51b4408 d65f03c0 d503245f (e5bb5800) | ---[ end trace 0000000000000000 ]---
Fix this by having restorezacontext() ensure that the task's svestate is allocated, matching what we do when taking an SME trap. Any live SVE/SSVE state (which is restored earlier from a separate signal context) must be preserved, and hence this is not zeroed.
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: dw: dmamux: fix OF node leak on route allocation failure
Make sure to drop the reference taken to the DMA master OF node also on late route allocation failures.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: Add missing NULL pointer check for pingpong interface
It is checked almost always in dpuencoderphyswbsetupctl(), but in a single place the check is missing. Also use convenient locals instead of physenc-> where available.
Patchwork: https://patchwork.freedesktop.org/patch/693860/
In the Linux kernel, the following vulnerability has been resolved:
srcu: Delegate work to the boot cpu if using SRCUSIZESMALL
Commit 994f706872e6 ("srcu: Make Tree SRCU able to operate without snpnode array") assumes that cpu 0 is always online. However, there really are situations when some other CPU is the boot CPU, for example, when booting a kdump kernel with the maxcpus=1 boot parameter.
On PowerPC, the kdump kernel can hang as follows: ... [ 1.740036] systemd[1]: Hostname set to <xyz.com> [ 243.686240] INFO: task systemd:1 blocked for more than 122 seconds. [ 243.686264] Not tainted 6.1.0-rc1 #1 [ 243.686272] "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. [ 243.686281] task:systemd state:D stack:0 pid:1 ppid:0 flags:0x00042000 [ 243.686296] Call Trace: [ 243.686301] [c000000016657640] [c000000016657670] 0xc000000016657670 (unreliable) [ 243.686317] [c000000016657830] [c00000001001dec0] switchto+0x130/0x220 [ 243.686333] [c000000016657890] [c000000010f607b8] schedule+0x1f8/0x580 [ 243.686347] [c000000016657940] [c000000010f60bb4] schedule+0x74/0x140 [ 243.686361] [c0000000166579b0] [c000000010f699b8] scheduletimeout+0x168/0x1c0 [ 243.686374] [c000000016657a80] [c000000010f61de8] waitforcommon+0x148/0x360 [ 243.686387] [c000000016657b20] [c000000010176bb0] flushwork.isra.0+0x1c0/0x3d0 [ 243.686401] [c000000016657bb0] [c0000000105f2768] fsnotifywaitmarksdestroyed+0x28/0x40 [ 243.686415] [c000000016657bd0] [c0000000105f21b8] fsnotifydestroygroup+0x68/0x160 [ 243.686428] [c000000016657c40] [c0000000105f6500] inotifyrelease+0x30/0xa0 [ 243.686440] [c000000016657cb0] [c0000000105751a8] fput+0xc8/0x350 [ 243.686452] [c000000016657d00] [c00000001017d524] taskworkrun+0xe4/0x170 [ 243.686464] [c000000016657d50] [c000000010020e94] donotifyresume+0x134/0x140 [ 243.686478] [c000000016657d80] [c00000001002eb18] interruptexituserpreparemain+0x198/0x270 [ 243.686493] [c000000016657de0] [c00000001002ec60] syscallexitprepare+0x70/0x180 [ 243.686505] [c000000016657e10] [c00000001000bf7c] systemcallvectoredcommon+0xfc/0x280 [ 243.686520] --- interrupt: 3000 at 0x7fffa47d5ba4 [ 243.686528] NIP: 00007fffa47d5ba4 LR: 0000000000000000 CTR: 0000000000000000 [ 243.686538] REGS: c000000016657e80 TRAP: 3000 Not tainted (6.1.0-rc1) [ 243.686548] MSR: 800000000000d033 <SF,EE,PR,ME,IR,DR,RI,LE> CR: 42044440 XER: 00000000 [ 243.686572] IRQMASK: 0 [ 243.686572] GPR00: 0000000000000006 00007ffffa606710 00007fffa48e7200 0000000000000000 [ 243.686572] GPR04: 0000000000000002 000000000000000a 0000000000000000 0000000000000001 [ 243.686572] GPR08: 000001000c172dd0 0000000000000000 0000000000000000 0000000000000000 [ 243.686572] GPR12: 0000000000000000 00007fffa4ff4bc0 0000000000000000 0000000000000000 [ 243.686572] GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 [ 243.686572] GPR20: 0000000132dfdc50 000000000000000e 0000000000189375 0000000000000000 [ 243.686572] GPR24: 00007ffffa606ae0 0000000000000005 000001000c185490 000001000c172570 [ 243.686572] GPR28: 000001000c172990 000001000c184850 000001000c172e00 00007fffa4fedd98 [ 243.686683] NIP [00007fffa47d5ba4] 0x7fffa47d5ba4 [ 243.686691] LR [0000000000000000] 0x0 [ 243.686698] --- interrupt: 3000 [ 243.686708] INFO: task kworker/u16:1:24 blocked for more than 122 seconds. [ 243.686717] Not tainted 6.1.0-rc1 #1 [ 243.686724] "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. [ 243.686733] task:kworker/u16:1 state:D stack:0 pid:24 ppid:2 flags:0x00000800 [ 243.686747] Workqueue: eventsunbound fsnotifymarkdestroyworkfn [ 243.686758] Call Trace: [ 243.686762] [c0000000166736e0] [c00000004fd91000] 0xc00000004fd91000 (unreliable) [ 243.686775] [c0000000166738d0] [c00000001001dec0] switchto+0x130/0x220 [ 243.686788] [c000000016673930] [c000000010f607b8] schedule+0x1f8/0x ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
iommu/mediatek: Check return value after calling platformgetresource()
platformgetresource() may return NULL pointer, we need check its return value to avoid null-ptr-deref in resourcesize().
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix deinitialization of firmware resources
Currently, in ath11kahbfwresourcesinit(), iommu domain mapping is done only for the chipsets having fixed firmware memory. Also, for such chipsets, mapping is done only if it does not have TrustZone support.
During deinitialization, only if TrustZone support is not there, iommu is unmapped back. However, for non fixed firmware memory chipsets, TrustZone support is not there and this makes the condition check to true and it tries to unmap the memory which was not mapped during initialization.
This leads to the following trace -
[ 83.198790] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 [ 83.259537] Modules linked in: ath11kahb ath11k qmihelpers .. snip .. [ 83.280286] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 83.287228] pc : iommuunmap+0x30/0x140 [ 83.293907] lr : iommuunmap+0x5c/0xa4 [ 83.298072] sp : ffff80000b3abad0 .. snip .. [ 83.369175] Call trace: [ 83.376282] iommuunmap+0x30/0x140 [ 83.378541] iommuunmap+0x5c/0xa4 [ 83.382360] ath11kahbfwresourcedeinit.part.12+0x2c/0xac [ath11kahb] [ 83.385666] ath11kahbfreeresources+0x140/0x17c [ath11kahb] [ 83.392521] ath11kahbshutdown+0x34/0x40 [ath11kahb] [ 83.398248] platformshutdown+0x20/0x2c [ 83.403455] deviceshutdown+0x16c/0x1c4 [ 83.407621] kernelrestartprepare+0x34/0x3c [ 83.411529] kernelrestart+0x14/0x74 [ 83.415781] dosysreboot+0x1c4/0x22c [ 83.419427] arm64sysreboot+0x1c/0x24 [ 83.423420] invokesyscall+0x44/0xfc [ 83.427326] el0svccommon.constprop.3+0xac/0xe8 [ 83.430974] doel0svc+0xa0/0xa8 [ 83.435659] el0svc+0x1c/0x44 [ 83.438957] el0t64synchandler+0x60/0x144 [ 83.441910] el0t64sync+0x15c/0x160 [ 83.446343] Code: aa0103f4 f9400001 f90027a1 d2800001 (f94006a0) [ 83.449903] ---[ end trace 0000000000000000 ]---
This can be reproduced by probing an AHB chipset which is not having a fixed memory region. During reboot (or rmmod) trace can be seen.
Fix this issue by adding a condition check on firmware fixed memory hwparam as done in the counter initialization function.
Tested-on: IPQ8074 hw2.0 AHB WLAN.HK.2.7.0.1-01744-QCAHKSWPLSILICONZ-1
In the Linux kernel, the following vulnerability has been resolved:
mm/uffd: fix warning without PTEMARKERUFFDWP compiled in
When PTEMARKERUFFDWP not configured, it's still possible to reach pte marker code and trigger an warning. Add a few CONFIGPTEMARKERUFFDWP ifdefs to make sure the code won't be reached when not compiled in.
In the Linux kernel, the following vulnerability has been resolved:
mm: slub: avoid wake up kswapd in settrackprepare
settrackprepare() can incur lock recursion. The issue is that it is called from hrtimerstartrangens holding the percpu(hrtimerbases)[n].lock, but when enabled CONFIGDEBUGOBJECTSTIMERS, may wake up kswapd in settrackprepare, and try to hold the percpu(hrtimerbases)[n].lock.
Avoid deadlock caused by implicitly waking up kswapd by passing in allocation flags, which do not contain GFPKSWAPDRECLAIM in the debugobjectsfillpool() case. Inside stack depot they are processed by gfpnestedmask(). Since slaballoc() has preemption disabled, we mask out GFPDIRECTRECLAIM from the flags there.
The oops looks something like:
BUG: spinlock recursion on CPU#3, swapper/3/0 lock: 0xffffff8a4bf29c80, .magic: dead4ead, .owner: swapper/3/0, .ownercpu: 3 Hardware name: Qualcomm Technologies, Inc. Popsicle based on SM8850 (DT) Call trace: spinbug+0x0 rawspinlockirqsave+0x80 hrtimertrytocancel+0x94 taskcontending+0x10c enqueuedlentity+0x2a4 dlserverstart+0x74 enqueuetaskfair+0x568 enqueuetask+0xac doactivatetask+0x14c ttwudoactivate+0xcc trytowakeup+0x6c8 defaultwakefunction+0x20 autoremovewakefunction+0x1c wakeup+0xac wakeupkswapd+0x19c wakeallkswapds+0x78 allocpagesslowpath+0x1ac allocpagesnoprof+0x298 stackdepotsaveflags+0x6b0 stackdepotsave+0x14 settrackprepare+0x5c slaballoc+0xccc kmalloccachenoprof+0x470 setpageowner+0x2bc postallochook[jt]+0x1b8 prepnewpage+0x28 getpagefromfreelist+0x1edc allocpagesnoprof+0x13c allocslabpage+0x244 allocateslab+0x7c slaballoc+0x8e8 kmemcacheallocnoprof+0x450 debugobjectsfillpool+0x22c debugobjectactivate+0x40 enqueuehrtimer[jt]+0xdc hrtimerstartrangens+0x5f8 ...
In the Linux kernel, the following vulnerability has been resolved:
drm/ttm: fix bulkmove corruption when adding a entry
When the resource is the first in the bulkmove range, adding it again (thus moving it to the tail) will corrupt the list since the first pointer is not moved. This eventually lead to null pointer deref in ttmlrubulkmovedel()
In the Linux kernel, the following vulnerability has been resolved:
net: skbpartialcsumset() fix against transport header magic value
skb->transportheader uses the special 0xFFFF value to mark if the transport header was set or not.
We must prevent callers to accidentaly set skb->transportheader to 0xFFFF. Note that only fuzzers can possibly do this today.
syzbot reported:
WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 skbtransportoffset include/linux/skbuff.h:2956 [inline] WARNING: CPU: 0 PID: 2340 at include/linux/skbuff.h:2847 virtionethdrtoskb+0xbcc/0x10c0 include/linux/virtionet.h:103 Modules linked in: CPU: 0 PID: 2340 Comm: syz-executor.0 Not tainted 6.3.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/14/2023 RIP: 0010:skbtransportheader include/linux/skbuff.h:2847 [inline] RIP: 0010:skbtransportoffset include/linux/skbuff.h:2956 [inline] RIP: 0010:virtionethdrtoskb+0xbcc/0x10c0 include/linux/virtionet.h:103 Code: 41 39 df 0f 82 c3 04 00 00 48 8b 7c 24 10 44 89 e6 e8 08 6e 59 ff 48 85 c0 74 54 e8 ce 36 7e fc e9 37 f8 ff ff e8 c4 36 7e fc <0f> 0b e9 93 f8 ff ff 44 89 f7 44 89 e6 e8 32 38 7e fc 45 39 e6 0f RSP: 0018:ffffc90004497880 EFLAGS: 00010293 RAX: ffffffff84fea55c RBX: 000000000000ffff RCX: ffff888120be2100 RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff RBP: ffffc90004497990 R08: ffffffff84fe9de5 R09: 0000000000000034 R10: ffffea00048ebd80 R11: 0000000000000034 R12: ffff88811dc2d9c8 R13: dffffc0000000000 R14: ffff88811dc2d9ae R15: 1ffff11023b85b35 FS: 00007f9211a59700(0000) GS:ffff8881f6c00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200002c0 CR3: 00000001215a5000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> packetsnd net/packet/afpacket.c:3076 [inline] packetsendmsg+0x4590/0x61a0 net/packet/afpacket.c:3115 socksendmsgnosec net/socket.c:724 [inline] socksendmsg net/socket.c:747 [inline] syssendto+0x472/0x630 net/socket.c:2144 dosyssendto net/socket.c:2156 [inline] sesyssendto net/socket.c:2152 [inline] x64syssendto+0xe5/0x100 net/socket.c:2152 dosyscallx64 arch/x86/entry/common.c:50 [inline] dosyscall64+0x2f/0x50 arch/x86/entry/common.c:80 entrySYSCALL64afterhwframe+0x63/0xcd RIP: 0033:0x7f9210c8c169 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f9211a59168 EFLAGS: 00000246 ORIGRAX: 000000000000002c RAX: ffffffffffffffda RBX: 00007f9210dabf80 RCX: 00007f9210c8c169 RDX: 000000000000ffed RSI: 00000000200000c0 RDI: 0000000000000003 RBP: 00007f9210ce7ca1 R08: 0000000020000540 R09: 0000000000000014 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007ffe135d65cf R14: 00007f9211a59300 R15: 0000000000022000
In the Linux kernel, the following vulnerability has been resolved:
LoongArch: mm: Add p?dleaf() definitions
When I do LTP test, LTP test case ksm06 caused panic at breakksmpmdentry -> pmdleaf (Huge page table but False) -> ptepresent (panic)
The reason is pmdleaf() is not defined, So like commit 501b81046701 ("mips: mm: add p?dleaf() definitions") add p?dleaf() definition for LoongArch.
In the Linux kernel, the following vulnerability has been resolved:
led: qcom-lpg: Fix sleeping in atomic
lpgbrighnessset() function can sleep, while led's brightnessset() callback must be non-blocking. Change LPG driver to use brightnesssetblocking() instead.
BUG: sleeping function called from invalid context at kernel/locking/mutex.c:580 inatomic(): 1, irqsdisabled(): 0, nonblock: 0, pid: 0, name: swapper/0 preemptcount: 101, expected: 0 INFO: lockdep is turned off. CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 6.1.0-rc1-00014-gbe99b089c6fc-dirty #85 Hardware name: Qualcomm Technologies, Inc. DB820c (DT) Call trace: dumpbacktrace.part.0+0xe4/0xf0 showstack+0x18/0x40 dumpstacklvl+0x88/0xb4 dumpstack+0x18/0x34 mightresched+0x170/0x254 mightsleep+0x48/0x9c mutexlock+0x4c/0x400 mutexlocknested+0x2c/0x40 lpgbrightnesssingleset+0x40/0x90 ledsetbrightnessnosleep+0x34/0x60 ledheartbeatfunction+0x80/0x170 calltimerfn+0xb8/0x340 runtimers.part.0+0x20c/0x254 runtimersoftirq+0x3c/0x7c stext+0x14c/0x578 dosoftirq+0x10/0x20 callonirqstack+0x2c/0x5c dosoftirqownstack+0x1c/0x30 irqexitrcu+0x164/0x170 irqexitrcu+0x10/0x40 el1interrupt+0x38/0x50 el1h64irqhandler+0x18/0x2c el1h64irq+0x64/0x68 cpuidleenterstate+0xc8/0x380 cpuidleenter+0x38/0x50 doidle+0x244/0x2d0 cpustartupentry+0x24/0x30 restinit+0x128/0x1a0 archpostacpisubsysinit+0x0/0x18 startkernel+0x6f4/0x734 primaryswitched+0xbc/0xc4
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: fix netdevstartxmit trace event vs skbtransportoffset()
After blamed commit, we must be more careful about using skbtransportoffset(), as reminded us by syzbot:
WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 skbtransportoffset include/linux/skbuff.h:2977 [inline] WARNING: CPU: 0 PID: 10 at include/linux/skbuff.h:2868 perftracenetdevstartxmit+0x89a/0xce0 include/trace/events/net.h:14 Modules linked in: CPU: 0 PID: 10 Comm: kworker/u4:1 Not tainted 6.1.30-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 05/27/2023 Workqueue: batevents batadvivsendoutstandingbatogmpacket RIP: 0010:skbtransportheader include/linux/skbuff.h:2868 [inline] RIP: 0010:skbtransportoffset include/linux/skbuff.h:2977 [inline] RIP: 0010:perftracenetdevstartxmit+0x89a/0xce0 include/trace/events/net.h:14 Code: 8b 04 25 28 00 00 00 48 3b 84 24 c0 00 00 00 0f 85 4e 04 00 00 48 8d 65 d8 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc e8 56 22 01 fd <0f> 0b e9 f6 fc ff ff 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 86 f9 ff RSP: 0018:ffffc900002bf700 EFLAGS: 00010293 RAX: ffffffff8485d8ca RBX: 000000000000ffff RCX: ffff888100914280 RDX: 0000000000000000 RSI: 000000000000ffff RDI: 000000000000ffff RBP: ffffc900002bf818 R08: ffffffff8485d5b6 R09: fffffbfff0f8fb5e R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff110217d8f67 R13: ffff88810bec7b3a R14: dffffc0000000000 R15: dffffc0000000000 FS: 0000000000000000(0000) GS:ffff8881f6a00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f96cf6d52f0 CR3: 000000012224c000 CR4: 0000000000350ef0 Call Trace: <TASK> [<ffffffff84715e35>] tracenetdevstartxmit include/trace/events/net.h:14 [inline] [<ffffffff84715e35>] xmitone net/core/dev.c:3643 [inline] [<ffffffff84715e35>] devhardstartxmit+0x705/0x980 net/core/dev.c:3660 [<ffffffff8471a232>] devqueuexmit+0x16b2/0x3370 net/core/dev.c:4324 [<ffffffff85416493>] devqueuexmit include/linux/netdevice.h:3030 [inline] [<ffffffff85416493>] batadvsendskbpacket+0x3f3/0x680 net/batman-adv/send.c:108 [<ffffffff85416744>] batadvsendbroadcastskb+0x24/0x30 net/batman-adv/send.c:127 [<ffffffff853bc52a>] batadvivogmsendtoif net/batman-adv/bativogm.c:393 [inline] [<ffffffff853bc52a>] batadvivogmemit net/batman-adv/bativogm.c:421 [inline] [<ffffffff853bc52a>] batadvivsendoutstandingbatogmpacket+0x69a/0x840 net/batman-adv/bativogm.c:1701 [<ffffffff8151023c>] processonework+0x8ac/0x1170 kernel/workqueue.c:2289 [<ffffffff81511938>] workerthread+0xaa8/0x12d0 kernel/workqueue.c:2436
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: check for null return of devmkzalloc() in dpuwritebackinit()
Because of the possilble failure of devmkzalloc(), dpuwbconn might be NULL and will cause null pointer dereference later.
Therefore, it might be better to check it and directly return -ENOMEM.
Patchwork: https://patchwork.freedesktop.org/patch/512277/ [DB: fixed typo in commit message]
In the Linux kernel, the following vulnerability has been resolved:
driver: soc: xilinx: fix memory leak in xlnxaddcbfornotifyevent()
The kfree() should be called when memory fails to be allocated for cbdata in xlnxaddcbfornotifyevent(), otherwise there will be a memory leak, so add kfree() to fix it.
In the Linux kernel, the following vulnerability has been resolved:
ovl: fix null pointer dereference in ovlpermission()
Following process: P1 P2 pathlookupat linkpathwalk inodepermission ovlpermission ovlipathreal(inode, &realpath) path->dentry = ovlidentryupper(inode) dropcache dentrykill(ovldentry) iput(ovlinode) ovldestroyinode(ovlinode) dput(oi->upperdentry) dentrykill(upperdentry) dentryunlinkinode upperdentry->dinode = NULL realinode = dinode(realpath.dentry) // return NULL inodepermission(realinode) inode->isb // NULL pointer dereference , will trigger an null pointer dereference at realinode: [ 335.664979] BUG: kernel NULL pointer dereference, address: 0000000000000002 [ 335.668032] CPU: 0 PID: 2592 Comm: ls Not tainted 6.3.0 [ 335.669956] RIP: 0010:inodepermission+0x33/0x2c0 [ 335.678939] Call Trace: [ 335.679165] <TASK> [ 335.679371] ovlpermission+0xde/0x320 [ 335.679723] inodepermission+0x15e/0x2c0 [ 335.680090] linkpathwalk+0x115/0x550 [ 335.680771] pathlookupat.isra.0+0xb2/0x200 [ 335.681170] filenamelookup+0xda/0x240 [ 335.681922] vfsstatx+0xa6/0x1f0 [ 335.682233] vfsfstatat+0x7b/0xb0
Fetch a reproducer in [Link].
Use the helper ovlipathrealinode() to get realinode and then do non-nullptr checking.
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:
driver core: location: Free struct acpipldinfo pld before return false
struct acpipldinfo pld should be freed before the return of allocation failure, to prevent memory leak, add the ACPIFREE() to fix it.
In the Linux kernel, the following vulnerability has been resolved:
drm/i915/bios: fix a memory leak in generatelfpdataptrs
When (size != 0 || ptrs->lvds entries != 3), the program tries to free() the ptrs. However, the ptrs is not created by calling kzmalloc(), but is obtained by pointer offset operation. This may lead to memory leaks or undefined behavior.
Fix this by replacing the arguments of kfree() with ptrsblock.
(cherry picked from commit 7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec)
In the Linux kernel, the following vulnerability has been resolved:
ipc: fix memory leak in initmqueuefs()
When setupmqsysctls() failed in initmqueuefs(), mqueueinodecachep is not released. In order to fix this issue, the release path is reordered.