In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix potential memleak in paprgetattr()
buf is allocated in paprgetattr(), and krealloc() of buf could fail. We need to free the original buf in the case of failure.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
The Linux kernel CVE team has assigned CVE-2024-27014 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024050149-CVE-2024-27014-d2dc@gregkh/T
gfs2: Fix kernel NULL pointer dereference in gfs2rgrpdump
Syzkaller has reported a NULL pointer dereference when accessing rgd->rdrgl in gfs2rgrpdump(). This can happen when creatingrgd->rdgl fails in readrindexentry(). Add a NULL pointer check in gfs2rgrpdump() to prevent that.
In the Linux kernel, the following vulnerability has been resolved:
mm: prevent derefencing NULL ptr in pfnsectionvalid()
Commit 5ec8e8ea8b77 ("mm/sparsemem: fix race in accessing memorysection->usage") changed pfnsectionvalid() to add a READONCE() call around "ms->usage" to fix a race with sectiondeactivate() where ms->usage can be cleared. The READONCE() call, by itself, is not enough to prevent NULL pointer dereference. We need to check its value before dereferencing it.
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---
fs/proc: dotaskstat: use sig->statslock to gather the threads/children stats
A flaw was found in KVM. An improper check in svmsetx2apicmsrinterception() may allow direct access to host x2apic msrs when the guest resets its apic, potentially leading to a denial of service condition.
An issue was discovered in setcon2fbmap in drivers/video/fbdev/core/fbcon.c in the Linux kernel before 6.2.12. Because an assignment occurs only for the first vc, the fbconregisteredfb and fbcondisplay arrays can be desynchronized in fbconmodedeleted (the con2fbmap points at the old fbinfo).
A vulnerability was found in Linux Kernel, where Bluetooth BR/EDR PIN Pairing procedure is vulnerable to an impersonation attack. When an attacker connects to a victim device using the address of the device and the victim initiates a Pairing, the attacker can reflect the encrypted nonce even without knowledge of the key.
In the Linux kernel, the following vulnerability has been resolved:
ipv4: Fix uninit-value access in ipmakeskb()
KMSAN reported uninit-value access in ipmakeskb() [1]. ipmakeskb() tests HDRINCL to know if the skb has icmphdr. However, HDRINCL can cause a race condition. If calling setsockopt(2) with IPHDRINCL changes HDRINCL while ipmakeskb() is running, the function will access icmphdr in the skb even if it is not included. This causes the issue reported by KMSAN.
Check FLOWIFLAGKNOWNNH on fl4->flowi4flags instead of testing HDRINCL on the socket.
Also, fl4->fl4icmptype and fl4->fl4icmpcode are not initialized. These are union in struct flowi4 and are implicitly initialized by flowi4initoutput(), but we should not rely on specific union layout.
Initialize these explicitly in rawsendmsg().
[1] BUG: KMSAN: uninit-value in ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 ipmakeskb+0x2b74/0x2d20 net/ipv4/ipoutput.c:1481 ipfinishskb include/net/ip.h:243 [inline] ippushpendingframes+0x4c/0x5c0 net/ipv4/ipoutput.c:1508 rawsendmsg+0x2381/0x2690 net/ipv4/raw.c:654 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x274/0x3c0 net/socket.c:745 syssendto+0x62c/0x7b0 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x6d/0x75
Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x5f6/0xc50 mm/slub.c:3888 kmallocreserve+0x13c/0x4a0 net/core/skbuff.c:577 allocskb+0x35a/0x7c0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1318 [inline] ipappenddata+0x49ab/0x68c0 net/ipv4/ipoutput.c:1128 ipappenddata+0x1e7/0x260 net/ipv4/ipoutput.c:1365 rawsendmsg+0x22b1/0x2690 net/ipv4/raw.c:648 inetsendmsg+0x27b/0x2a0 net/ipv4/afinet.c:851 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x274/0x3c0 net/socket.c:745 syssendto+0x62c/0x7b0 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x130/0x200 net/socket.c:2199 dosyscall64+0xd8/0x1f0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x6d/0x75
CPU: 1 PID: 15709 Comm: syz-executor.7 Not tainted 6.8.0-11567-gb3603fcb79b1 #25 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
Bluetooth BR/EDR devices with Secure Simple Pairing and Secure Connections pairing in Bluetooth Core Specification 4.2 through 5.4 allow certain man-in-the-middle attacks that force a short key length, and might lead to discovery of the encryption key and live injection, aka BLUFFS.
In the Linux kernel, the following vulnerability has been resolved:
sched/membarrier: reduce the ability to hammer on sysmembarrier
On some systems, sysmembarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine.
In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Stop relying on userspace for info to fault in xsave buffer
Before this change, the expected size of the user space buffer was taken from fxsw->xstatesize. fxsw->xstatesize can be changed from user-space, so it is possible construct a sigreturn frame where:
fxsw->xstatesize is smaller than the size required by valid bits in fxsw->xfeatures. user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible.
In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But faultinreadable succeeds because buf + fxsw->xstatesize is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever.
Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->usersize).
[ dhansen: tweak subject / changelog ]
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrumacltcam: Fix NULL pointer dereference in error path
When calling mlxswspacltcamregiondestroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon 'region->group->tcam' [1].
Fix by retrieving the 'tcam' pointer using mlxswspacltotcam().
[1] BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:mlxswspacltcamregiondestroy+0xa0/0xd0 [...] Call Trace: mlxswspacltcamvchunkget+0x88b/0xa20 mlxswspacltcamventryadd+0x25/0xe0 mlxswspaclruleadd+0x47/0x240 mlxswspflowerreplace+0x1a9/0x1d0 tcsetupcbadd+0xdc/0x1c0 flhwreplacefilter+0x146/0x1f0 flchange+0xc17/0x1360 tcnewtfilter+0x472/0xb90 rtnetlinkrcvmsg+0x313/0x3b0 netlinkrcvskb+0x58/0x100 netlinkunicast+0x244/0x390 netlinksendmsg+0x1e4/0x440 syssendmsg+0x164/0x260 syssendmsg+0x9a/0xe0 syssendmsg+0x7a/0xc0 dosyscall64+0x40/0xe0 entrySYSCALL64afterhwframe+0x63/0x6b
In the Linux kernel, the following vulnerability has been resolved:
phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
If the external phy working together with phy-omap-usb2 does not implement sendsrp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example:
configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup ... Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute ... PC is at 0x0 LR is at musbgadgetwakeup+0x1d4/0x254 [musbhdrc] ... musbgadgetwakeup [musbhdrc] from usbgadgetwakeup+0x1c/0x3c [udccore] usbgadgetwakeup [udccore] from ethstartxmit+0x3b0/0x3d4 [uether] ethstartxmit [uether] from devhardstartxmit+0x94/0x24c devhardstartxmit from schdirectxmit+0x104/0x2e4 schdirectxmit from devqueuexmit+0x334/0xd88 devqueuexmit from arpsolicit+0xf0/0x268 arpsolicit from neighprobe+0x54/0x7c neighprobe from neigheventsend+0x22c/0x47c neigheventsend from neighresolveoutput+0x14c/0x1c0 neighresolveoutput from ipfinishoutput2+0x1c8/0x628 ipfinishoutput2 from ipsendskb+0x40/0xd8 ipsendskb from udpsendskb+0x124/0x340 udpsendskb from udpsendmsg+0x780/0x984 udpsendmsg from syssendto+0xd8/0x158 syssendto from retfastsyscall+0x0/0x58
Let's fix the issue by checking for sendsrp() and setvbus() before calling them. For USB peripheral only cases these both could be NULL.
createemptylvol in drivers/mtd/ubi/vtbl.c in the Linux kernel through 6.7.4 can attempt to allocate zero bytes, and crash, because of a missing check for ubi->lebsize.
In the Linux kernel through 6.7.1, there is a use-after-free in cecqueuemsgfh, related to drivers/media/cec/core/cec-adap.c and drivers/media/cec/core/cec-api.c.
An issue was discovered in the USB subsystem in the Linux kernel through 6.4.2. There is an out-of-bounds and crash in readdescriptors in drivers/usb/core/sysfs.c.
A vulnerability was discovered in the linux kernels implementation of "GTCO tablet/digitizer"s version of parsehidreportdescriptor in drivers.
An attacker with local access could create a malicious USB device which must be inserted into the local usb port to send a crafted USB response that triggers an out-of-bounds write during generation of debugging messages.
It is unlikely that this attack is effective or wide-spread as it requires specific usb hardware and physical access to the hardware to exploit.
Reference: https://patchwork.kernel.org/patch/11040813/
In the Linux kernel, the following vulnerability has been resolved:
x86/bhi: Avoid warning in #DB handler due to BHI mitigation
When BHI mitigation is enabled, if SYSENTER is invoked with the TF flag set then entrySYSENTERcompat() uses CLEARBRANCHHISTORY and calls the clearbhbloop() before the TF flag is cleared. This causes the #DB handler (excdebugkernel()) to issue a warning because single-step is used outside the entrySYSENTERcompat() function.
To address this issue, entrySYSENTERcompat() should use CLEARBRANCHHISTORY after making sure the TF flag is cleared.
The problem can be reproduced with the following sequence:
$ cat sysenterstep.c int main() { asm("pushf; pop %ax; bts $8,%ax; push %ax; popf; sysenter"); }
$ gcc -o sysenterstep sysenterstep.c
$ ./sysenterstep Segmentation fault (core dumped)
The program is expected to crash, and the #DB handler will issue a warning.
Kernel log:
WARNING: CPU: 27 PID: 7000 at arch/x86/kernel/traps.c:1009 excdebugkernel+0xd2/0x160 ... RIP: 0010:excdebugkernel+0xd2/0x160 ... Call Trace: <#DB> ? showregs+0x68/0x80 ? warn+0x8c/0x140 ? excdebugkernel+0xd2/0x160 ? reportbug+0x175/0x1a0 ? handlebug+0x44/0x90 ? excinvalidop+0x1c/0x70 ? asmexcinvalidop+0x1f/0x30 ? excdebugkernel+0xd2/0x160 excdebug+0x43/0x50 asmexcdebug+0x1e/0x40 RIP: 0010:clearbhbloop+0x0/0xb0 ... </#DB> <TASK> ? entrySYSENTERcompatafterhwframe+0x6e/0x8d </TASK>
[ bp: Massage commit message. ]
In the Linux kernel, the following vulnerability has been resolved:
usb: atm: cxacru: fix endpoint checking in cxacrubind()
Syzbot is still reporting quite an old issue [1] that occurs due to incomplete checking of present usb endpoints. As such, wrong endpoints types may be used at urb sumbitting stage which in turn triggers a warning in usbsubmiturb().
Fix the issue by verifying that required endpoint types are present for both in and out endpoints, taking into account cmd endpoint type.
Unfortunately, this patch has not been tested on real hardware.
[1] Syzbot report: usb 1-1: BOGUS urb xfer, pipe 1 != type 3 WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 Modules linked in: CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usbhubwq hubevent RIP: 0010:usbsubmiturb+0xed2/0x18a0 drivers/usb/core/urb.c:502 ... Call Trace: cxacrucm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649 cxacrucardstatus+0x22/0xd0 drivers/usb/atm/cxacru.c:760 cxacrubind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209 usbatmusbprobe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055 cxacruusbprobe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363 usbprobeinterface+0x315/0x7f0 drivers/usb/core/driver.c:396 calldriverprobe drivers/base/dd.c:517 [inline] reallyprobe+0x23c/0xcd0 drivers/base/dd.c:595 driverprobedevice+0x338/0x4d0 drivers/base/dd.c:747 driverprobedevice+0x4c/0x1a0 drivers/base/dd.c:777 deviceattachdriver+0x20b/0x2f0 drivers/base/dd.c:894 busforeachdrv+0x15f/0x1e0 drivers/base/bus.c:427 deviceattach+0x228/0x4a0 drivers/base/dd.c:965 busprobedevice+0x1e4/0x290 drivers/base/bus.c:487 deviceadd+0xc2f/0x2180 drivers/base/core.c:3354 usbsetconfiguration+0x113a/0x1910 drivers/usb/core/message.c:2170 usbgenericdriverprobe+0xba/0x100 drivers/usb/core/generic.c:238 usbprobedevice+0xd9/0x2c0 drivers/usb/core/driver.c:293
In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below) caused by our assumption that the reserved bits in an endpoint descriptor's bEndpointAddress field will always be 0. As a result of the bug, the endpointisduplicate() routine in config.c (and possibly other routines as well) may believe that two descriptors are for distinct endpoints, even though they have the same direction and endpoint number. This can lead to confusion, including the bug identified by syzbot (two descriptors with matching endpoint numbers and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress when we parse the descriptor. (Note that both the USB-2.0 and USB-3.1 specs say these bits are "Reserved, reset to zero".) This requires us to make a copy of the descriptor earlier in usbparseendpoint() and use the copy instead of the original when checking for duplicates.
In the Linux kernel, the following vulnerability has been resolved:
sched/deadline: Fix taskstruct reference leak
During the execution of the following stress test with linux-rt:
stress-ng --cyclic 30 --timeout 30 --minimize --quiet
kmemleak frequently reported a memory leak concerning the taskstruct:
unreferenced object 0xffff8881305b8000 (size 16136): comm "stress-ng", pid 614, jiffies 4294883961 (age 286.412s) object hex dump (first 32 bytes): 02 40 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 ................ debug hex dump (first 16 bytes): 53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00 S............... backtrace: [<00000000046b6790>] duptaskstruct+0x30/0x540 [<00000000c5ca0f0b>] copyprocess+0x3d9/0x50e0 [<00000000ced59777>] kernelclone+0xb0/0x770 [<00000000a50befdc>] dosysclone+0xb6/0xf0 [<000000001dbf2008>] dosyscall64+0x5d/0xf0 [<00000000552900ff>] entrySYSCALL64afterhwframe+0x6e/0x76
The issue occurs in startdltimer(), which increments the taskstruct reference count and sets a timer. The timer callback, dltasktimer, is supposed to decrement the reference count upon expiration. However, if enqueuetaskdl() is called before the timer expires and cancels it, the reference count is not decremented, leading to the leak.
This patch fixes the reference leak by ensuring the taskstruct reference count is properly decremented when the timer is canceled.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Fix deadlock in ieee80211stapsdeliverwakeup()
The ieee80211stapsdeliverwakeup() function takes sta->pslock to synchronizes with ieee80211txhunicastpsbuf() which is called from softirq context. However using only spinlock() to get sta->pslock in ieee80211stapsdeliverwakeup() does not prevent softirq to execute on this same CPU, to run ieee80211txhunicastpsbuf() and try to take this same lock ending in deadlock. Below is an example of rcu stall that arises in such situation.
rcu: INFO: rcusched self-detected stall on CPU rcu: 2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996 rcu: (t=42586894 jiffies g=2057 q=362405 ncpus=4) CPU: 2 PID: 719 Comm: wpasupplicant Tainted: G W 6.4.0-02158-g1b062f552873 #742 Hardware name: RPT (r1) (DT) pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : queuedspinlockslowpath+0x58/0x2d0 lr : invoketxhandlersearly+0x5b4/0x5c0 sp : ffff00001ef64660 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8 Call trace: queuedspinlockslowpath+0x58/0x2d0 ieee80211tx+0x80/0x12c ieee80211txpending+0x110/0x278 taskletactioncommon.constprop.0+0x10c/0x144 taskletaction+0x20/0x28 stext+0x11c/0x284 dosoftirq+0xc/0x14 callonirqstack+0x24/0x34 dosoftirqownstack+0x18/0x20 dosoftirq+0x74/0x7c localbhenableip+0xa0/0xa4 ieee80211waketxqs+0x3b0/0x4b8 ieee80211wakequeue+0x12c/0x168 ieee80211addpendingskbs+0xec/0x138 ieee80211stapsdeliverwakeup+0x2a4/0x480 ieee80211mpsstastatusupdate.part.0+0xd8/0x11c ieee80211mpsstastatusupdate+0x18/0x24 staapplyparameters+0x3bc/0x4c0 ieee80211changestation+0x1b8/0x2dc nl80211setstation+0x444/0x49c genlfamilyrcvmsgdoit.isra.0+0xa4/0xfc genlrcvmsg+0x1b0/0x244 netlinkrcvskb+0x38/0x10c genlrcv+0x34/0x48 netlinkunicast+0x254/0x2bc netlinksendmsg+0x190/0x3b4 syssendmsg+0x1e8/0x218 syssendmsg+0x68/0x8c syssendmsg+0x44/0x84 arm64syssendmsg+0x20/0x28 doel0svc+0x6c/0xe8 el0svc+0x14/0x48 el0t64synchandler+0xb0/0xb4 el0t64sync+0x14c/0x150
Using spinlockbh()/spinunlockbh() instead prevents softirq to raise on the same CPU that is holding the lock.
In the Linux kernel, the following vulnerability has been resolved:
md/raid5: fix deadlock that raid5d() wait for itself to clear MDSBCHANGEPENDING
Xiao reported that lvm2 test lvconvert-raid-takeover.sh can hang with small possibility, the root cause is exactly the same as commit bed9e27baf52 ("Revert "md/raid5: Wait for MDSBCHANGEPENDING in raid5d"")
However, Dan reported another hang after that, and junxiao investigated the problem and found out that this is caused by plugged bio can't issue from raid5d().
Current implementation in raid5d() has a weird dependence:
1) mdcheckrecovery() from raid5d() must hold 'reconfigmutex' to clear MDSBCHANGEPENDING; 2) raid5d() handles IO in a deadloop, until all IO are issued; 3) IO from raid5d() must wait for MDSBCHANGEPENDING to be cleared;
This behaviour is introduce before v2.6, and for consequence, if other context hold 'reconfigmutex', and mdcheckrecovery() can't update superblock, then raid5d() will waste one cpu 100% by the deadloop, until 'reconfigmutex' is released.
Refer to the implementation from raid1 and raid10, fix this problem by skipping issue IO if MDSBCHANGEPENDING is still set after mdcheckrecovery(), daemon thread will be woken up when 'reconfigmutex' is released. Meanwhile, the hang problem will be fixed as well.
In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mbcacheentry's erefcnt leak in ext4xattrblockcachefind()
Syzbot reports a warning as follows:
============================================ WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mbcachedestroy+0x224/0x290 Modules linked in: CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7 RIP: 0010:mbcachedestroy+0x224/0x290 fs/mbcache.c:419 Call Trace: ext4putsuper+0x6d4/0xcd0 fs/ext4/super.c:1375 genericshutdownsuper+0x136/0x2d0 fs/super.c:641 killblocksuper+0x44/0x90 fs/super.c:1675 ext4killsb+0x68/0xa0 fs/ext4/super.c:7327 [...] ============================================
This is because when finding an entry in ext4xattrblockcachefind(), if ext4sbbread() returns -ENOMEM, the ce's erefcnt, which has already grown in the entryfind(), won't be put away, and eventually trigger the above issue in mbcachedestroy() due to reference count leakage.
So call mbcacheentryput() on the -ENOMEM error branch as a quick fix.
In the Linux kernel, the following vulnerability has been resolved:
md: fix resync softlockup when bitmap size is less than array size
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will trigger following softlockup:
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdXresync:6976] CPU: 7 PID: 3588 Comm: mdXresync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1 RIP: 0010:rawspinunlockirq+0x13/0x30 Call Trace: <TASK> mdbitmapstartsync+0x6b/0xf0 raid10syncrequest+0x25c/0x1b40 [raid10] mddosync+0x64b/0x1020 mdthread+0xa7/0x170 kthread+0xcf/0x100 retfromfork+0x30/0x50 retfromforkasm+0x1a/0x30
And the detailed process is as follows:
mddosync j = mddev->resyncmin while (j < maxsectors) sectors = raid10syncrequest(mddev, j, &skipped) if (!mdbitmapstartsync(..., &syncblocks)) // mdbitmapstartsync set syncblocks to 0 return syncblocks + sectorsskippe; // sectors = 0; j += sectors; // j never change
Root cause is that commit 301867b1c168 ("md/raid10: check slab-out-of-bounds in mdbitmapgetcounter") return early from mdbitmapgetcounter(), without setting returned blocks.
Fix this problem by always set returned blocks from mdbitmapgetcounter"(), as it used to be.
Noted that this patch just fix the softlockup problem in kernel, the case that bitmap size doesn't match array size still need to be fixed.
In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: pcie: handle randbuf allocation failure
The kzalloc() in brcmfpciedownloadfwnvram() will return null if the physical memory has run out. As a result, if we use getrandombytes() to generate random bytes in the randbuf, the null pointer dereference bug will happen.
In order to prevent allocation failure, this patch adds a separate function using buffer on kernel stack to generate random bytes in the randbuf, which could prevent the kernel stack from overflow.
In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a possible memleak in tipcbufappend
skblinearize() doesn't free the skb when it fails, so move 'buf = NULL' after skblinearize(), so that the skb can be freed on the err path.