In the Linux kernel, the following vulnerability has been resolved:
ipv4: Fix reference count leak when using error routes with nexthop objects
When a nexthop object is deleted, it is marked as dead and then fibtableflush() is called to flush all the routes that are using the dead nexthop.
The current logic in fibtableflush() is to only flush error routes (e.g., blackhole) when it is called as part of network namespace dismantle (i.e., with flushall=true). Therefore, error routes are not flushed when their nexthop object is deleted:
# ip link add name dummy1 up type dummy # ip nexthop add id 1 dev dummy1 # ip route add 198.51.100.1/32 nhid 1 # ip route add blackhole 198.51.100.2/32 nhid 1 # ip nexthop del id 1 # ip route show blackhole 198.51.100.2 nhid 1 dev dummy1
As such, they keep holding a reference on the nexthop object which in turn holds a reference on the nexthop device, resulting in a reference count leak:
# ip link del dev dummy1 [ 70.516258] unregisternetdevice: waiting for dummy1 to become free. Usage count = 2
Fix by flushing error routes when their nexthop is marked as dead.
IPv6 does not suffer from this problem.
In the Linux kernel, the following vulnerability has been resolved:
net: nfc: fix deadlock between nfcunregisterdevice and rfkillfopwrite
A deadlock can occur between nfcunregisterdevice() and rfkillfopwrite() due to lock ordering inversion between devicelock and rfkillglobalmutex.
The problematic lock order is:
Thread A (rfkillfopwrite): rfkillfopwrite() mutexlock(&rfkillglobalmutex) rfkillsetblock() nfcrfkillsetblock() nfcdevdown() devicelock(&dev->dev) <- waits for devicelock
Thread B (nfcunregisterdevice): nfcunregisterdevice() devicelock(&dev->dev) rfkillunregister() mutexlock(&rfkillglobalmutex) <- waits for rfkillglobalmutex
This creates a classic ABBA deadlock scenario.
Fix this by moving rfkillunregister() and rfkilldestroy() outside the devicelock critical section. Store the rfkill pointer in a local variable before releasing the lock, then call rfkillunregister() after releasing devicelock.
This change is safe because rfkillfopwrite() holds rfkillglobalmutex while calling the rfkill callbacks, and rfkillunregister() also acquires rfkillglobalmutex before cleanup. Therefore, rfkillunregister() will wait for any ongoing callback to complete before proceeding, and devicedel() is only called after rfkillunregister() returns, preventing any use-after-free.
The similar lock ordering in nfcregisterdevice() (devicelock -> rfkillglobalmutex via rfkillregister) is safe because during registration the device is not yet in rfkilllist, so no concurrent rfkill operations can occur on this device.
In the Linux kernel, the following vulnerability has been resolved:
drm/xe/oa: Limit numsyncs to prevent oversized allocations
The OA open parameters did not validate numsyncs, allowing userspace to pass arbitrarily large values, potentially leading to excessive allocations.
Add check to ensure that numsyncs does not exceed DRMXEMAXSYNCS, returning -EINVAL when the limit is violated.
v2: use XEIOCTLDBG() and drop duplicated check. (Ashutosh)
(cherry picked from commit e057b2d2b8d815df3858a87dffafa2af37e5945b)
ASoC: stm32: sai: fix OF node leak on probe
In the Linux kernel, the following vulnerability has been resolved:
RDMA/cm: Fix leaking the multicast GID table reference
If the CM ID is destroyed while the CM event for multicast creating is still queued the cancelworksync() will prevent the work from running which also prevents destroying the ahattr. This leaks a refcount and triggers a WARN:
GID entry ref leak for dev syz1 index 2 ref=573 WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 releasegidtable drivers/infiniband/core/cache.c:806 [inline] WARNING: CPU: 1 PID: 655 at drivers/infiniband/core/cache.c:809 gidtablereleaseone+0x284/0x3cc drivers/infiniband/core/cache.c:886
Destroy the ahattr after canceling the work, it is safe to call this twice.
In the Linux kernel, the following vulnerability has been resolved:
mptcp: fallback earlier on simult connection
Syzkaller reports a simult-connect race leading to inconsistent fallback status:
WARNING: CPU: 3 PID: 33 at net/mptcp/subflow.c:1515 subflowdataready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Modules linked in: CPU: 3 UID: 0 PID: 33 Comm: ksoftirqd/3 Not tainted syzkaller #0 PREEMPT(full) Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 RIP: 0010:subflowdataready+0x40b/0x7c0 net/mptcp/subflow.c:1515 Code: 89 ee e8 78 61 3c f6 40 84 ed 75 21 e8 8e 66 3c f6 44 89 fe bf 07 00 00 00 e8 c1 61 3c f6 41 83 ff 07 74 09 e8 76 66 3c f6 90 <0f> 0b 90 e8 6d 66 3c f6 48 89 df e8 e5 ad ff ff 31 ff 89 c5 89 c6 RSP: 0018:ffffc900006cf338 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888031acd100 RCX: ffffffff8b7f2abf RDX: ffff88801e6ea440 RSI: ffffffff8b7f2aca RDI: 0000000000000005 RBP: 0000000000000000 R08: 0000000000000005 R09: 0000000000000007 R10: 0000000000000004 R11: 0000000000002c10 R12: ffff88802ba69900 R13: 1ffff920000d9e67 R14: ffff888046f81800 R15: 0000000000000004 FS: 0000000000000000(0000) GS:ffff8880d69bc000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000560fc0ca1670 CR3: 0000000032c3a000 CR4: 0000000000352ef0 Call Trace: <TASK> tcpdataqueue+0x13b0/0x4f90 net/ipv4/tcpinput.c:5197 tcprcvstateprocess+0xfdf/0x4ec0 net/ipv4/tcpinput.c:6922 tcpv6dorcv+0x492/0x1740 net/ipv6/tcpipv6.c:1672 tcpv6rcv+0x2976/0x41e0 net/ipv6/tcpipv6.c:1918 ip6protocoldeliverrcu+0x188/0x1520 net/ipv6/ip6input.c:438 ip6inputfinish+0x1e4/0x4b0 net/ipv6/ip6input.c:489 NFHOOK include/linux/netfilter.h:318 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ip6input+0x105/0x2f0 net/ipv6/ip6input.c:500 dstinput include/net/dst.h:471 [inline] ip6rcvfinish net/ipv6/ip6input.c:79 [inline] NFHOOK include/linux/netfilter.h:318 [inline] NFHOOK include/linux/netfilter.h:312 [inline] ipv6rcv+0x264/0x650 net/ipv6/ip6input.c:311 netifreceiveskbonecore+0x12d/0x1e0 net/core/dev.c:5979 netifreceiveskb+0x1d/0x160 net/core/dev.c:6092 processbacklog+0x442/0x15e0 net/core/dev.c:6444 napipoll.constprop.0+0xba/0x550 net/core/dev.c:7494 napipoll net/core/dev.c:7557 [inline] netrxaction+0xa9f/0xfe0 net/core/dev.c:7684 handlesoftirqs+0x216/0x8e0 kernel/softirq.c:579 runksoftirqd kernel/softirq.c:968 [inline] runksoftirqd+0x3a/0x60 kernel/softirq.c:960 smpbootthreadfn+0x3f7/0xae0 kernel/smpboot.c:160 kthread+0x3c2/0x780 kernel/kthread.c:463 retfromfork+0x5d7/0x6f0 arch/x86/kernel/process.c:148 retfromforkasm+0x1a/0x30 arch/x86/entry/entry64.S:245 </TASK>
The TCP subflow can process the simult-connect syn-ack packet after transitioning to TCPFIN1 state, bypassing the MPTCP fallback check, as the skstatechange() callback is not invoked for -> FINWAIT1 transitions.
That will move the msk socket to an inconsistent status and the next incoming data will hit the reported splat.
Close the race moving the simult-fallback check at the earliest possible stage - that is at syn-ack generation time.
About the fixes tags: [2] was supposed to also fix this issue introduced by [3]. [1] is required as a dependence: it was not explicitly marked as a fix, but it is one and it has already been backported before [3]. In other words, this commit should be backported up to [3], including [2] and [1] if that's not already there.
drm/ttm: Avoid NULL pointer deref for evicted BOs
In the Linux kernel, the following vulnerability has been resolved:
tpm: Cap the number of PCR banks
tpm2getpcrallocation() does not cap any upper limit for the number of banks. Cap the limit to eight banks so that out of bounds values coming from external I/O cause on only limited harm.
In the Linux kernel, the following vulnerability has been resolved:
net: usb: asix: validate PHY address before use
The ASIX driver reads the PHY address from the USB device via asixreadphyaddr(). A malicious or faulty device can return an invalid address (>= PHYMAXADDR), which causes a warning in mdiobusgetphy():
addr 207 out of range WARNING: drivers/net/phy/mdiobus.c:76
Validate the PHY address in asixreadphyaddr() and remove the now-redundant check in ax88172a.c.
In the Linux kernel, the following vulnerability has been resolved:
kernel/kexec: fix IMA when allocation happens in CMA area
Bug description
When I tested kexec with the latest kernel, I ran into the following warning:
[ 40.712410] ------------[ cut here ]------------ [ 40.712576] WARNING: CPU: 2 PID: 1562 at kernel/kexeccore.c:1001 kimagemapsegment+0x144/0x198 [...] [ 40.816047] Call trace: [ 40.818498] kimagemapsegment+0x144/0x198 (P) [ 40.823221] imakexecpostload+0x58/0xc0 [ 40.827246] dosyskexecfileload+0x29c/0x368 [...] [ 40.855423] ---[ end trace 0000000000000000 ]---
How to reproduce
This bug is only triggered when the kexec target address is allocated in the CMA area. If no CMA area is reserved in the kernel, use the "cma=" option in the kernel command line to reserve one.
Root cause The commit 07d24902977e ("kexec: enable CMA based contiguous allocation") allocates the kexec target address directly on the CMA area to avoid copying during the jump. In this case, there is no INDSOURCE for the kexec segment. But the current implementation of kimagemapsegment() assumes that INDSOURCE pages exist and map them into a contiguous virtual address by vmap().
Solution If IMA segment is allocated in the CMA area, use its pageaddress() directly.
In the Linux kernel, the following vulnerability has been resolved:
drm/msm/a6xx: move preemptpreparepostamble after error check
Move the call to preemptpreparepostamble() after verifying that preemptpostambleptr is valid. If preemptpostambleptr is NULL, dereferencing it in preemptpreparepostamble() would lead to a crash.
This change avoids calling the preparation function when the postamble allocation has failed, preventing potential NULL pointer dereference and ensuring proper error handling.
Patchwork: https://patchwork.freedesktop.org/patch/687659/
In the Linux kernel, the following vulnerability has been resolved:
parisc: Do not reprogram affinitiy on ASP chip
The ASP chip is a very old variant of the GSP chip and is used e.g. in HP 730 workstations. When trying to reprogram the affinity it will crash with a HPMC as the relevant registers don't seem to be at the usual location. Let's avoid the crash by checking the sversion. Also note, that reprogramming isn't necessary either, as the HP730 is a just a single-CPU machine.
In the Linux kernel, the following vulnerability has been resolved:
cpuset: fix warning when disabling remote partition
A warning was triggered as follows:
WARNING: kernel/cgroup/cpuset.c:1651 at remotepartitiondisable+0xf7/0x110 RIP: 0010:remotepartitiondisable+0xf7/0x110 RSP: 0018:ffffc90001947d88 EFLAGS: 00000206 RAX: 0000000000007fff RBX: ffff888103b6e000 RCX: 0000000000006f40 RDX: 0000000000006f00 RSI: ffffc90001947da8 RDI: ffff888103b6e000 RBP: ffff888103b6e000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000001 R11: ffff88810b2e2728 R12: ffffc90001947da8 R13: 0000000000000000 R14: ffffc90001947da8 R15: ffff8881081f1c00 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f55c8bbe0b2 CR3: 000000010b14c000 CR4: 00000000000006f0 Call Trace: <TASK> updateprstate+0x2d3/0x580 cpusetpartitionwrite+0x94/0xf0 kernfsfopwriteiter+0x147/0x200 vfswrite+0x35d/0x500 ksyswrite+0x66/0xe0 dosyscall64+0x6b/0x390 entrySYSCALL64afterhwframe+0x4b/0x53 RIP: 0033:0x7f55c8cd4887
Reproduction steps (on a 16-CPU machine):
# cd /sys/fs/cgroup/ # mkdir A1 # echo +cpuset > A1/cgroup.subtreecontrol # echo "0-14" > A1/cpuset.cpus.exclusive # mkdir A1/A2 # echo "0-14" > A1/A2/cpuset.cpus.exclusive # echo "root" > A1/A2/cpuset.cpus.partition # echo 0 > /sys/devices/system/cpu/cpu15/online # echo member > A1/A2/cpuset.cpus.partition
When CPU 15 is offlined, subpartitionscpus gets cleared because no CPUs remain available for the topcpuset, forcing partitions to share CPUs with the topcpuset. In this scenario, disabling the remote partition triggers a warning stating that effectivexcpus is not a subset of subpartitionscpus. Partitions should be invalidated in this case to inform users that the partition is now invalid(cpus are shared with topcpuset).
To fix this issue: 1. Only emit the warning only if subpartitionscpus is not empty and the effectivexcpus is not a subset of subpartitionscpus. 2. During the CPU hotplug process, invalidate partitions if subpartitionscpus is empty.
In the Linux kernel, the following vulnerability has been resolved:
block: Remove queue freezing from several sysfs store callbacks
Freezing the request queue from inside sysfs store callbacks may cause a deadlock in combination with the dm-multipath driver and the queueifnopath option. Additionally, freezing the request queue slows down system boot on systems where sysfs attributes are set synchronously.
Fix this by removing the blkmqfreezequeue() / blkmqunfreezequeue() calls from the store callbacks that do not strictly need these callbacks. Add the dataracy annotation to requestqueue.rqtimeout to suppress KCSAN data race reports about the rqtimeout reads.
This patch may cause a small delay in applying the new settings.
For all the attributes affected by this patch, I/O will complete correctly whether the old or the new value of the attribute is used.
This patch affects the following sysfs attributes: iopolldelay iotimeout nomerges readaheadkb rqaffinity
Here is an example of a deadlock triggered by running test srp/002 if this patch is not applied:
task:multipathd Call Trace: <TASK> schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 schedulepreemptdisabled+0x1c/0x30 mutexlock+0xb89/0x1650 mutexlocknested+0x1f/0x30 dmtablesetrestrictions+0x823/0xdf0 bind+0x166/0x590 dmswaptable+0x2a7/0x490 doresume+0x1b1/0x610 devsuspend+0x55/0x1a0 ctlioctl+0x3a5/0x7e0 dmctlioctl+0x12/0x20 x64sysioctl+0x127/0x1a0 x64syscall+0xe2b/0x17d0 dosyscall64+0x96/0x3a0 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK> task:(udev-worker) Call Trace: <TASK> schedule+0x8c1/0x1bf0 schedule+0xdd/0x270 blkmqfreezequeuewait+0xf2/0x140 blkmqfreezequeuenomemsave+0x23/0x30 queuerastore+0x14e/0x290 queueattrstore+0x23e/0x2c0 sysfskfwrite+0xde/0x140 kernfsfopwriteiter+0x3b2/0x630 vfswrite+0x4fd/0x1390 ksyswrite+0xfd/0x230 x64syswrite+0x76/0xc0 x64syscall+0x276/0x17d0 dosyscall64+0x96/0x3a0 entrySYSCALL64afterhwframe+0x4b/0x53 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
drm/tilcdc: Fix removal actions in case of failed probe
The drmkmshelperpollfini() and drmatomichelpershutdown() helpers should only be called when the device has been successfully registered. Currently, these functions are called unconditionally in tilcdcfini(), which causes warnings during probe deferral scenarios.
[ 7.972317] WARNING: CPU: 0 PID: 23 at drivers/gpu/drm/drmatomicstatehelper.c:175 drmatomichelpercrtcduplicatestate+0x60/0x68 ... [ 8.005820] drmatomichelpercrtcduplicatestate from drmatomicgetcrtcstate+0x68/0x108 [ 8.005858] drmatomicgetcrtcstate from drmatomichelperdisableall+0x90/0x1c8 [ 8.005885] drmatomichelperdisableall from drmatomichelpershutdown+0x90/0x144 [ 8.005911] drmatomichelpershutdown from tilcdcfini+0x68/0xf8 [tilcdc] [ 8.005957] tilcdcfini [tilcdc] from tilcdcpdevprobe+0xb0/0x6d4 [tilcdc]
Fix this by rewriting the failed probe cleanup path using the standard goto error handling pattern, which ensures that cleanup functions are only called on successfully initialized resources. Additionally, remove the now-unnecessary isregistered flag.
In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: Handle incorrect numconnectors capability
The UCSI spec states that the numconnectors field is 7 bits, and the 8th bit is reserved and should be set to zero. Some buggy FW has been known to set this bit, and it can lead to a system not booting. Flag that the FW is not behaving correctly, and auto-fix the value so that the system boots correctly.
Found on Lenovo P1 G8 during Linux enablement program. The FW will be fixed, but seemed worth addressing in case it hit platforms that aren't officially Linux supported.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/kexec: Enable SMT before waking offline CPUs
If SMT is disabled or a partial SMT state is enabled, when a new kernel image is loaded for kexec, on reboot the following warning is observed:
kexec: Waking offline cpu 228. WARNING: CPU: 0 PID: 9062 at arch/powerpc/kexec/core64.c:223 kexecpreparecpus+0x1b0/0x1bc [snip] NIP kexecpreparecpus+0x1b0/0x1bc LR kexecpreparecpus+0x1a0/0x1bc Call Trace: kexecpreparecpus+0x1a0/0x1bc (unreliable) defaultmachinekexec+0x160/0x19c machinekexec+0x80/0x88 kernelkexec+0xd0/0x118 dosysreboot+0x210/0x2c4 systemcallexception+0x124/0x320 systemcallvectoredcommon+0x15c/0x2ec
This occurs as addcpu() fails due to cpubootable() returning false for CPUs that fail the cpusmtthreadallowed() check or non primary threads if SMT is disabled.
Fix the issue by enabling SMT and resetting the number of SMT threads to the number of threads per core, before attempting to wake up all present CPUs.
In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Fix VM hard lockup after prolonged inactivity with periodic HV timer
When advancing the target expiration for the guest's APIC timer in periodic mode, set the expiration to "now" if the target expiration is in the past (similar to what is done in updatetargetexpiration()). Blindly adding the period to the previous target expiration can result in KVM generating a practically unbounded number of hrtimer IRQs due to programming an expired timer over and over. In extreme scenarios, e.g. if userspace pauses/suspends a VM for an extended duration, this can even cause hard lockups in the host.
Currently, the bug only affects Intel CPUs when using the hypervisor timer (HV timer), a.k.a. the VMX preemption timer. Unlike the software timer, a.k.a. hrtimer, which KVM keeps running even on exits to userspace, the HV timer only runs while the guest is active. As a result, if the vCPU does not run for an extended duration, there will be a huge gap between the target expiration and the current time the vCPU resumes running. Because the target expiration is incremented by only one period on each timer expiration, this leads to a series of timer expirations occurring rapidly after the vCPU/VM resumes.
More critically, when the vCPU first triggers a periodic HV timer expiration after resuming, advancing the expiration by only one period will result in a target expiration in the past. As a result, the delta may be calculated as a negative value. When the delta is converted into an absolute value (tscdeadline is an unsigned u64), the resulting value can overflow what the HV timer is capable of programming. I.e. the large value will exceed the VMX Preemption Timer's maximum bit width of cpupreemptiontimermulti + 32, and thus cause KVM to switch from the HV timer to the software timer (hrtimers).
After switching to the software timer, periodic timer expiration callbacks may be executed consecutively within a single clock interrupt handler, because hrtimers honors KVM's request for an expiration in the past and immediately re-invokes KVM's callback after reprogramming. And because the interrupt handler runs with IRQs disabled, restarting KVM's hrtimer over and over until the target expiration is advanced to "now" can result in a hard lockup.
E.g. the following hard lockup was triggered in the host when running a Windows VM (only relevant because it used the APIC timer in periodic mode) after resuming the VM from a long suspend (in the host).
NMI watchdog: Watchdog detected hard LOCKUP on cpu 45 ... RIP: 0010:advanceperiodictargetexpiration+0x4d/0x80 [kvm] ... RSP: 0018:ff4f88f5d98d8ef0 EFLAGS: 00000046 RAX: fff0103f91be678e RBX: fff0103f91be678e RCX: 00843a7d9e127bcc RDX: 0000000000000002 RSI: 0052ca4003697505 RDI: ff440d5bfbdbd500 RBP: ff440d5956f99200 R08: ff2ff2a42deb6a84 R09: 000000000002a6c0 R10: 0122d794016332b3 R11: 0000000000000000 R12: ff440db1af39cfc0 R13: ff440db1af39cfc0 R14: ffffffffc0d4a560 R15: ff440db1af39d0f8 FS: 00007f04a6ffd700(0000) GS:ff440db1af380000(0000) knlGS:000000e38a3b8000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000d5651feff8 CR3: 000000684e038002 CR4: 0000000000773ee0 PKRU: 55555554 Call Trace: <IRQ> apictimerfn+0x31/0x50 [kvm] hrtimerrunqueues+0x100/0x280 hrtimerinterrupt+0x100/0x210 ? ttwudowakeup+0x19/0x160 smpapictimerinterrupt+0x6a/0x130 apictimerinterrupt+0xf/0x20 </IRQ>
Moreover, if the suspend duration of the virtual machine is not long enough to trigger a hard lockup in this scenario, since commit 98c25ead5eda ("KVM: VMX: Move preemption timer <=> hrtimer dance to common x86"), KVM will continue using the software timer until the guest reprograms the APIC timer in some way. Since the periodic timer does not require frequent APIC timer register programming, the guest may continue to use the software timer in ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
f2fs: ensure node page reads complete before f2fsputsuper() finishes
Xfstests generic/335, generic/336 sometimes crash with the following message:
F2FS-fs (dm-0): detect filesystem reference count leak during umount, type: 9, count: 1 ------------[ cut here ]------------ kernel BUG at fs/f2fs/super.c:1939! Oops: invalid opcode: 0000 [#1] SMP NOPTI CPU: 1 UID: 0 PID: 609351 Comm: umount Tainted: G W 6.17.0-rc5-xfstests-g9dd1835ecda5 #1 PREEMPT(none) Tainted: [W]=WARN Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:f2fsputsuper+0x3b3/0x3c0 Call Trace: <TASK> genericshutdownsuper+0x7e/0x190 killblocksuper+0x1a/0x40 killf2fssuper+0x9d/0x190 deactivatelockedsuper+0x30/0xb0 cleanupmnt+0xba/0x150 taskworkrun+0x5c/0xa0 exittousermodeloop+0xb7/0xc0 dosyscall64+0x1ae/0x1c0 entrySYSCALL64afterhwframe+0x76/0x7e </TASK> ---[ end trace 0000000000000000 ]---
It appears that sometimes it is possible that f2fsputsuper() is called before all node page reads are completed. Adding a call to f2fswaitonallpages() for F2FSRDNODE fixes the problem.
In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Avoid walking the Namespace if startnode is NULL
Although commit 0c9992315e73 ("ACPICA: Avoid walking the ACPI Namespace if it is not there") fixed the situation when both startnode and acpigblrootnode are NULL, the Linux kernel mainline now still crashed on Honor Magicbook 14 Pro [1].
That happens due to the access to the member of parentnode in acpinsgetnextnode(). The NULL pointer dereference will always happen, no matter whether or not the startnode is equal to ACPIROOTOBJECT, so move the check of startnode being NULL out of the if block.
Unfortunately, all the attempts to contact Honor have failed, they refused to provide any technical support for Linux.
The bad DSDT table's dump could be found on GitHub [2].
DMI: HONOR FMB-P/FMB-P-PCB, BIOS 1.13 05/08/2025
[ rjw: Subject adjustment, changelog edits ]
In the Linux kernel, the following vulnerability has been resolved:
scs: fix a wrong parameter in scsmagic
scsmagic() needs a 'void ' variable, but a 'struct taskstruct ' is given. 'taskscs(tsk)' is the starting address of the task's shadow call stack, and 'scsmagic(taskscs(tsk))' is the end address of the task's shadow call stack. Here should be 'scsmagic(taskscs(tsk))'.
The user-visible effect of this bug is that when CONFIGDEBUGSTACKUSAGE is enabled, the shadow call stack usage checking function (scscheckusage) would scan an incorrect memory range. This could lead
1. Inaccurate stack usage reporting: The function would calculate wrong usage statistics for the shadow call stack, potentially showing incorrect value in kmsg.
2. Potential kernel crash: If the value of scsmagic(tsk)is greater than that of scsmagic(taskscs(tsk)), the for loop may access unmapped memory, potentially causing a kernel panic. However, this scenario is unlikely because taskstruct is allocated via the slab allocator (which typically returns lower addresses), while the shadow call stack returned by taskscs(tsk) is allocated via vmalloc(which typically returns higher addresses).
However, since this is purely a debugging feature (CONFIGDEBUGSTACKUSAGE), normal production systems should be not unaffected. The bug only impacts developers and testers who are actively debugging stack usage with this configuration enabled.
f2fs: use global inlinexattrslab instead of per-sb slab cache
In the Linux kernel, the following vulnerability has been resolved:
tracing: Do not register unsupported perf events
Synthetic events currently do not have a function to register perf events. This leads to calling the tracepoint register functions with a NULL function pointer which triggers:
------------[ cut here ]------------ WARNING: kernel/tracepoint.c:175 at tracepointaddfunc+0x357/0x370, CPU#2: perf/2272 Modules linked in: kvmintel kvm irqbypass CPU: 2 UID: 0 PID: 2272 Comm: perf Not tainted 6.18.0-ftest-11964-ge022764176fc-dirty #323 PREEMPTLAZY Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.17.0-debian-1.17.0-1 04/01/2014 RIP: 0010:tracepointaddfunc+0x357/0x370 Code: 28 9c e8 4c 0b f5 ff eb 0f 4c 89 f7 48 c7 c6 80 4d 28 9c e8 ab 89 f4 ff 31 c0 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc cc <0f> 0b 49 c7 c6 ea ff ff ff e9 ee fe ff ff 0f 0b e9 f9 fe ff ff 0f RSP: 0018:ffffabc0c44d3c40 EFLAGS: 00010246 RAX: 0000000000000001 RBX: ffff9380aa9e4060 RCX: 0000000000000000 RDX: 000000000000000a RSI: ffffffff9e1d4a98 RDI: ffff937fcf5fd6c8 RBP: 0000000000000001 R08: 0000000000000007 R09: ffff937fcf5fc780 R10: 0000000000000003 R11: ffffffff9c193910 R12: 000000000000000a R13: ffffffff9e1e5888 R14: 0000000000000000 R15: ffffabc0c44d3c78 FS: 00007f6202f5f340(0000) GS:ffff93819f00f000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000055d3162281a8 CR3: 0000000106a56003 CR4: 0000000000172ef0 Call Trace: <TASK> tracepointproberegister+0x5d/0x90 syntheventreg+0x3c/0x60 perftraceeventinit+0x204/0x340 perftraceinit+0x85/0xd0 perftpeventinit+0x2e/0x50 perftryinitevent+0x6f/0x230 ? perfeventalloc+0x4bb/0xdc0 perfeventalloc+0x65a/0xdc0 sesysperfeventopen+0x290/0x9f0 dosyscall64+0x93/0x7b0 ? entrySYSCALL64afterhwframe+0x76/0x7e ? tracehardirqsoff+0x53/0xc0 entrySYSCALL64afterhwframe+0x76/0x7e
Instead, have the code return -ENODEV, which doesn't warn and has perf error out with:
# perf record -e synthetic:futexwait Error: The sysperfeventopen() syscall returned with 19 (No such device) for event (synthetic:futexwait). "dmesg | grep -i perf" may provide additional information.
Ideally perf should support synthetic events, but for now just fix the warning. The support can come later.
In the Linux kernel, the following vulnerability has been resolved:
crypto: afalg - zero initialize memory allocated via sockkmalloc
Several crypto user API contexts and requests allocated with sockkmalloc() were left uninitialized, relying on callers to set fields explicitly. This resulted in the use of uninitialized data in certain error paths or when new fields are added in the future.
The ACVP patches also contain two user-space interface files: algifkpp.c and algifakcipher.c. These too rely on proper initialization of their context structures.
A particular issue has been observed with the newly added 'inflight' variable introduced in afalgctx by commit:
67b164a871af ("crypto: afalg - Disallow multiple in-flight AIO requests")
Because the context is not memset to zero after allocation, the inflight variable has contained garbage values. As a result, afalgallocareq() has incorrectly returned -EBUSY randomly when the garbage value was interpreted as true:
https://github.com/gregkh/linux/blame/master/crypto/afalg.c#L1209
The check directly tests ctx->inflight without explicitly comparing against true/false. Since inflight is only ever set to true or false later, an uninitialized value has triggered -EBUSY failures. Zero-initializing memory allocated with sockkmalloc() ensures inflight and other fields start in a known state, removing random issues caused by uninitialized data.
In the Linux kernel, the following vulnerability has been resolved:
viawdt: fix critical boot hang due to unnamed resource allocation
The VIA watchdog driver uses allocateresource() to reserve a MMIO region for the watchdog control register. However, the allocated resource was not given a name, which causes the kernel resource tree to contain an entry marked as "<BAD>" under /proc/iomem on x86 platforms.
During boot, this unnamed resource can lead to a critical hang because subsequent resource lookups and conflict checks fail to handle the invalid entry properly.
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix possible null-pointer dereferences in raid5storegroupthreadcnt()
The variable mddev->private is first assigned to conf and then checked:
conf = mddev->private; if (!conf) ...
If conf is NULL, then mddev->private is also NULL. In this case, null-pointer dereferences can occur when calling raid5quiesce():
raid5quiesce(mddev, true); raid5quiesce(mddev, false);
since mddev->private is assigned to conf again in raid5quiesce(), and conf is dereferenced in several places, for example:
conf->quiesce = 0; wakeup(&conf->waitforquiescent);
To fix this issue, the function should unlock mddev and return before invoking raid5quiesce() when conf is NULL, following the existing pattern in raid5changeconsistencypolicy().
In the Linux kernel, the following vulnerability has been resolved:
um: init cputasks[] earlier
This is currently done in umlfinishsetup(), but e.g. with KCOV enabled we'll crash because some init code can call into e.g. memparse(), which has coverage annotations, and then the checks in checkkcovmode() crash because current is NULL.
Simply initialize the cputasks[] array statically, which fixes the crash. For the later SMP work, it seems to have not really caused any problems yet, but initialize all of the entries anyway.
In the Linux kernel, the following vulnerability has been resolved:
fs: PM: Fix reverse check in filesystemsfreezecallback()
The freezeallptr check in filesystemsfreezecallback() introduced by commit a3f8f8662771 ("power: always freeze efivarfs") is reverse which quite confusingly causes all file systems to be frozen when filesystemfreezeenabled is false.
On my systems it causes the WARNONONCE() in settaskfrozen() to trigger, most likely due to an attempt to freeze a file system that is not ready for that.
Add a logical negation to the check in question to reverse it as appropriate.
In the Linux kernel, the following vulnerability has been resolved:
mm/pagealloc: change all pageblocks migrate type on coalescing
When a page is freed it coalesces with a buddy into a higher order page while possible. When the buddy page migrate type differs, it is expected to be updated to match the one of the page being freed.
However, only the first pageblock of the buddy page is updated, while the rest of the pageblocks are left unchanged.
That causes warnings in later expand() and other code paths (like below), since an inconsistency between migration type of the list containing the page and the page-owned pageblocks migration types is introduced.
[ 308.986589] ------------[ cut here ]------------ [ 308.987227] page type is 0, passed migratetype is 1 (nr=256) [ 308.987275] WARNING: CPU: 1 PID: 5224 at mm/pagealloc.c:812 expand+0x23c/0x270 [ 308.987293] Modules linked in: algifhash(E) afalg(E) nftfibinet(E) nftfibipv4(E) nftfibipv6(E) nftfib(E) nftrejectinet(E) nfrejectipv4(E) nfrejectipv6(E) nftreject(E) nftct(E) nftchainnat(E) nfnat(E) nfconntrack(E) nfdefragipv6(E) nfdefragipv4(E) nftables(E) s390trng(E) vfioccw(E) mdev(E) vfioiommutype1(E) vfio(E) schfqcodel(E) drm(E) i2ccore(E) drmpanelorientationquirks(E) loop(E) nfnetlink(E) vsockloopback(E) vmwvsockvirtiotransportcommon(E) vsock(E) ctcm(E) fsm(E) diag288wdt(E) watchdog(E) zfcp(E) scsitransportfc(E) ghashs390(E) prng(E) aess390(E) desgeneric(E) dess390(E) libdes(E) sha3512s390(E) sha3256s390(E) shacommon(E) paess390(E) cryptoengine(E) pkeycca(E) pkeyep11(E) zcrypt(E) rngcore(E) pkeypckmo(E) pkey(E) autofs4(E) [ 308.987439] Unloaded tainted modules: hmacs390(E):2 [ 308.987650] CPU: 1 UID: 0 PID: 5224 Comm: mempigverify Kdump: loaded Tainted: G E 6.18.0-gcc-bpf-debug #431 PREEMPT [ 308.987657] Tainted: [E]=UNSIGNEDMODULE [ 308.987661] Hardware name: IBM 3906 M04 704 (z/VM 7.3.0) [ 308.987666] Krnl PSW : 0404f00180000000 00000349976fa600 (expand+0x240/0x270) [ 308.987676] R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:3 PM:0 RI:0 EA:3 [ 308.987682] Krnl GPRS: 0000034980000004 0000000000000005 0000000000000030 000003499a0e6d88 [ 308.987688] 0000000000000005 0000034980000005 000002be803ac000 0000023efe6c8300 [ 308.987692] 0000000000000008 0000034998d57290 000002be00000100 0000023e00000008 [ 308.987696] 0000000000000000 0000000000000000 00000349976fa5fc 000002c99b1eb6f0 [ 308.987708] Krnl Code: 00000349976fa5f0: c020008a02f2 larl %r2,000003499883abd4 00000349976fa5f6: c0e5ffe3f4b5 brasl %r14,0000034997378f60 #00000349976fa5fc: af000000 mc 0,0 >00000349976fa600: a7f4ff4c brc 15,00000349976fa498 00000349976fa604: b9040026 lgr %r2,%r6 00000349976fa608: c0300088317f larl %r3,0000034998800906 00000349976fa60e: c0e5fffdb6e1 brasl %r14,00000349976b13d0 00000349976fa614: af000000 mc 0,0 [ 308.987734] Call Trace: [ 308.987738] [<00000349976fa600>] expand+0x240/0x270 [ 308.987744] ([<00000349976fa5fc>] expand+0x23c/0x270) [ 308.987749] [<00000349976ff95e>] rmqueuebulk+0x71e/0x940 [ 308.987754] [<00000349976ffd7e>] rmqueuepcplist+0x1fe/0x2a0 [ 308.987759] [<0000034997700966>] rmqueue.isra.0+0xb46/0xf40 [ 308.987763] [<0000034997703ec8>] getpagefromfreelist+0x198/0x8d0 [ 308.987768] [<0000034997706fa8>] allocfrozenpagesnoprof+0x198/0x400 [ 308.987774] [<00000349977536f8>] allocpagesmpol+0xb8/0x220 [ 308.987781] [<0000034997753bf6>] folioallocmpolnoprof+0x26/0xc0 [ 308.987786] [<0000034997753e4c>] vmaallocfolionoprof+0x6c/0xa0 [ 308.987791] [<0000034997775b22>] vmaallocanonfoliopmd+0x42/0x240 [ 308.987799] [<000003499777bfea>] dohugepmdanonymouspage+0x3a/0x210 [ 308.987804] [<00000349976cb0 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
drm/msm: adreno: fix deferencing ifpcreglist when not declared
On plaforms with an a7xx GPU not supporting IFPC, the ifpcreglist if still deferenced in a7xxpatchpwrupreglist() which causes a kernel crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000008 ... pc : a6xxhwinit+0x155c/0x1e4c [msm] lr : a6xxhwinit+0x9a8/0x1e4c [msm] ... Call trace: a6xxhwinit+0x155c/0x1e4c [msm] (P) msmgpuhwinit+0x58/0x88 [msm] adrenoloadgpu+0x94/0x1fc [msm] msmopen+0xe4/0xf4 [msm] drmfilealloc+0x1a0/0x2e4 [drm] drmclientinit+0x7c/0x104 [drm] drmfbdevclientsetup+0x94/0xcf0 [drmclientlib] drmclientsetup+0xb4/0xd8 [drmclientlib] msmdrmkmspostinit+0x2c/0x3c [msm] msmdrminit+0x1a4/0x228 [msm] msmdrmbind+0x30/0x3c [msm] ...
Check the validity of ifpcreglist before deferencing the table to setup the register values.
Patchwork: https://patchwork.freedesktop.org/patch/688944/