gpio: xilinx: Convert gpiolock to raw spinlock
bus: mhi: host: pcigeneric: Use pcitryresetfunction() to avoid deadlock
In the Linux kernel, the following vulnerability has been resolved:
net: tap: NULL pointer derefence in devparseheaderprotocol when skb->dev is null
Fixes a NULL pointer derefence bug triggered from tap driver. When tapgetuser calls virtionethdrtoskb the skb->dev is null (in tap.c skb->dev is set after the call to virtionethdrtoskb) virtionethdrtoskb calls devparseheaderprotocol which needs skb->dev field to be valid.
The line that trigers the bug is in devparseheaderprotocol (dev is at offset 0x10 from skb and is stored in RAX register) if (!dev->headerops || !dev->headerops->parseprotocol) 22e1: mov 0x10(%rbx),%rax 22e5: mov 0x230(%rax),%rax
Setting skb->dev before the call in tap.c fixes the issue.
BUG: kernel NULL pointer dereference, address: 0000000000000230 RIP: 0010:virtionethdrtoskb.constprop.0+0x335/0x410 [tap] Code: c0 0f 85 b7 fd ff ff eb d4 41 39 c6 77 cf 29 c6 48 89 df 44 01 f6 e8 7a 79 83 c1 48 85 c0 0f 85 d9 fd ff ff eb b7 48 8b 43 10 <48> 8b 80 30 02 00 00 48 85 c0 74 55 48 8b 40 28 48 85 c0 74 4c 48 RSP: 0018:ffffc90005c27c38 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888298f25300 RCX: 0000000000000010 RDX: 0000000000000005 RSI: ffffc90005c27cb6 RDI: ffff888298f25300 RBP: ffffc90005c27c80 R08: 00000000ffffffea R09: 00000000000007e8 R10: ffff88858ec77458 R11: 0000000000000000 R12: 0000000000000001 R13: 0000000000000014 R14: ffffc90005c27e08 R15: ffffc90005c27cb6 FS: 0000000000000000(0000) GS:ffff88858ec40000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000230 CR3: 0000000281408006 CR4: 00000000003706e0 Call Trace: tapgetuser+0x3f1/0x540 [tap] tapsendmsg+0x56/0x362 [tap] ? gettxbufs+0xc2/0x1e0 [vhostnet] handletxcopy+0x114/0x670 [vhostnet] handletx+0xb0/0xe0 [vhostnet] handletxkick+0x15/0x20 [vhostnet] vhostworker+0x7b/0xc0 [vhost] ? vhostvringcallreset+0x40/0x40 [vhost] kthread+0xfa/0x120 ? kthreadcompleteandexit+0x20/0x20 retfromfork+0x1f/0x30
In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: guard flow control update with globaltxfc in buffer switching
mvpp2bmswitchbuffers() unconditionally calls mvpp2bmpoolupdateprivfc() when switching between per-cpu and shared buffer pool modes. This function programs CM3 flow control registers via mvpp2cm3read()/mvpp2cm3write(), which dereference priv->cm3base without any NULL check.
When the CM3 SRAM resource is not present in the device tree (the third reg entry added by commit 60523583b07c ("dts: marvell: add CM3 SRAM memory to cp11x ethernet device tree")), priv->cm3base remains NULL and priv->globaltxfc is false. Any operation that triggers mvpp2bmswitchbuffers(), for example an MTU change that crosses the jumbo frame threshold, will crash:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Mem abort info: ESR = 0x0000000096000006 EC = 0x25: DABT (current EL), IL = 32 bits pc : readl+0x0/0x18 lr : mvpp2cm3read.isra.0+0x14/0x20 Call trace: readl+0x0/0x18 mvpp2bmpoolupdatefc+0x40/0x12c mvpp2bmpoolupdateprivfc+0x94/0xd8 mvpp2bmswitchbuffers.isra.0+0x80/0x1c0 mvpp2changemtu+0x140/0x380 devsetmtu+0x1c/0x38 devsetmtuext+0x78/0x118 devsetmtu+0x48/0xa8 devifsioc+0x21c/0x43c devioctl+0x2d8/0x42c sockioctl+0x314/0x378
Every other flow control call site in the driver already guards hardware access with either priv->globaltxfc or port->txfc. mvpp2bmswitchbuffers() is the only place that omits this check.
Add the missing priv->globaltxfc guard to both the disable and re-enable calls in mvpp2bmswitchbuffers(), consistent with the rest of the driver.
In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: Add missing NULL check for allocworkqueue()
allocworkqueue() can return NULL on memory allocation failure. Without proper error checking, this may lead to a NULL pointer dereference when queuework() is later called with the NULL workqueue pointer in epfntbepcinit().
Add a NULL check immediately after allocworkqueue() and return -ENOMEM on failure to prevent the driver from loading with an invalid workqueue pointer.
In the Linux kernel, the following vulnerability has been resolved:
iouring/io-wq: check IOWQBITEXIT inside work run loop
Currently this is checked before running the pending work. Normally this is quite fine, as work items either end up blocking (which will create a new worker for other items), or they complete fairly quickly. But syzbot reports an issue where io-wq takes seemingly forever to exit, and with a bit of debugging, this turns out to be because it queues a bunch of big (2GB - 4096b) reads with a /dev/msr file. Since this file type doesn't support ->readiter(), looprwiter() ends up handling them. Each read returns 16MB of data read, which takes 20 (!!) seconds. With a bunch of these pending, processing the whole chain can take a long time. Easily longer than the syzbot uninterruptible sleep timeout of 140 seconds. This then triggers a complaint off the io-wq exit path:
INFO: task syz.4.135:6326 blocked for more than 143 seconds. Not tainted syzkaller #0 Blocked by coredump. "echo 0 > /proc/sys/kernel/hungtasktimeoutsecs" disables this message. task:syz.4.135 state:D stack:26824 pid:6326 tgid:6324 ppid:5957 taskflags:0x400548 flags:0x00080000 Call Trace: <TASK> contextswitch kernel/sched/core.c:5256 [inline] schedule+0x1139/0x6150 kernel/sched/core.c:6863 scheduleloop kernel/sched/core.c:6945 [inline] schedule+0xe7/0x3a0 kernel/sched/core.c:6960 scheduletimeout+0x257/0x290 kernel/time/sleeptimeout.c:75 dowaitforcommon kernel/sched/completion.c:100 [inline] waitforcommon+0x2fc/0x4e0 kernel/sched/completion.c:121 iowqexitworkers iouring/io-wq.c:1328 [inline] iowqputandexit+0x271/0x8a0 iouring/io-wq.c:1356 iouringcleantctx+0x10d/0x190 iouring/tctx.c:203 iouringcancelgeneric+0x69c/0x9a0 iouring/cancel.c:651 iouringfilescancel include/linux/iouring.h:19 [inline] doexit+0x2ce/0x2bd0 kernel/exit.c:911 dogroupexit+0xd3/0x2a0 kernel/exit.c:1112 getsignal+0x2671/0x26d0 kernel/signal.c:3034 archdosignalorrestart+0x8f/0x7e0 arch/x86/kernel/signal.c:337 exittousermodeloop kernel/entry/common.c:41 [inline] exittousermodeloop+0x8c/0x540 kernel/entry/common.c:75 exittousermodeprepare include/linux/irq-entry-common.h:226 [inline] syscallexittousermodeprepare include/linux/irq-entry-common.h:256 [inline] syscallexittousermodework include/linux/entry-common.h:159 [inline] syscallexittousermode include/linux/entry-common.h:194 [inline] dosyscall64+0x4ee/0xf80 arch/x86/entry/syscall64.c:100 entrySYSCALL64afterhwframe+0x77/0x7f RIP: 0033:0x7fa02738f749 RSP: 002b:00007fa0281ae0e8 EFLAGS: 00000246 ORIGRAX: 00000000000000ca RAX: fffffffffffffe00 RBX: 00007fa0275e6098 RCX: 00007fa02738f749 RDX: 0000000000000000 RSI: 0000000000000080 RDI: 00007fa0275e6098 RBP: 00007fa0275e6090 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fa0275e6128 R14: 00007fff14e4fcb0 R15: 00007fff14e4fd98
There's really nothing wrong here, outside of processing these reads will take a LONG time. However, we can speed up the exit by checking the IOWQBITEXIT inside the ioworkerhandlework() loop, as syzbot will exit the ring after queueing up all of these reads. Then once the first item is processed, io-wq will simply cancel the rest. That should avoid syzbot running into this complaint again.
In the Linux kernel, the following vulnerability has been resolved:
net: mscc: ocelot: Fix crash when adding interface under a lag
Commit 15faa1f67ab4 ("lan966x: Fix crash when adding interface under a lag") fixed a similar issue in the lan966x driver caused by a NULL pointer dereference. The ocelotsetaggrpgids() function in the ocelot driver has similar logic and is susceptible to the same crash.
This issue specifically affects the ocelotvsc7514.c frontend, which leaves unused ports as NULL pointers. The felixvsc9959.c frontend is unaffected as it uses the DSA framework which registers all ports.
Fix this by checking if the port pointer is valid before accessing it.
In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921: Place upper limit on station AID
Any station configured with an AID over 20 causes a firmware crash. This situation occurred in our testing using an AP interface on 7922 hardware, with a modified hostapd, sourced from Mediatek's OpenWRT feeds.
In stock hostapd, station AIDs begin counting at 1, and this configuration is prevented with an upper limit on associated stations. However, the modified hostapd began allocation at 65, which caused the firmware to crash. This fix does not allow these AIDs to work, but will prevent the firmware crash.
This crash was only seen on IFTYPEAP interfaces, and the fix does not appear to have an effect on IFTYPESTATION behavior.
cifs: Fix integer overflow while processing acdirmax mount option
cifs: Fix integer overflow while processing acregmax mount option
In the Linux kernel, the following vulnerability has been resolved:
HID: playstation: Add missing check for inputffcreatememless
The psgamepadcreate() function calls inputffcreatememless() without verifying its return value, which can lead to incorrect behavior or potential crashes when FF effects are triggered.
Add a check for the return value of inputffcreatememless().
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:
net: missing check virtio
Two missing check in virtionethdrtoskb() allowed syzbot to crash kernels again
1. After the skbsegment function the buffer may become non-linear (nrfrags != 0), but since the SKBTXSHAREDFRAG flag is not set anywhere the skblinearize function will not be executed, then the buffer will remain non-linear. Then the condition (offset >= skbheadlen(skb)) becomes true, which causes WARNONONCE in skbchecksumhelp.
2. The struct skbuff and struct virtionethdr members must be mathematically related. (gsosize) must be greater than (needed) otherwise WARNONONCE. (remainder) must be greater than (needed) otherwise WARNONONCE. (remainder) may be 0 if division is without remainder.
offset+2 (4191) > skbheadlen() (1116) WARNING: CPU: 1 PID: 5084 at net/core/dev.c:3303 skbchecksumhelp+0x5e2/0x740 net/core/dev.c:3303 Modules linked in: CPU: 1 PID: 5084 Comm: syz-executor336 Not tainted 6.7.0-rc3-syzkaller-00014-gdf60cee26a2e #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023 RIP: 0010:skbchecksumhelp+0x5e2/0x740 net/core/dev.c:3303 Code: 89 e8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 52 01 00 00 44 89 e2 2b 53 74 4c 89 ee 48 c7 c7 40 57 e9 8b e8 af 8f dd f8 90 <0f> 0b 90 90 e9 87 fe ff ff e8 40 0f 6e f9 e9 4b fa ff ff 48 89 ef RSP: 0018:ffffc90003a9f338 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff888025125780 RCX: ffffffff814db209 RDX: ffff888015393b80 RSI: ffffffff814db216 RDI: 0000000000000001 RBP: ffff8880251257f4 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: 000000000000045c R13: 000000000000105f R14: ffff8880251257f0 R15: 000000000000105d FS: 0000555555c24380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000002000f000 CR3: 0000000023151000 CR4: 00000000003506f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> ipdofragment+0xa1b/0x18b0 net/ipv4/ipoutput.c:777 ipfragment.constprop.0+0x161/0x230 net/ipv4/ipoutput.c:584 ipfinishoutputgso net/ipv4/ipoutput.c:286 [inline] ipfinishoutput net/ipv4/ipoutput.c:308 [inline] ipfinishoutput+0x49c/0x650 net/ipv4/ipoutput.c:295 ipfinishoutput+0x31/0x310 net/ipv4/ipoutput.c:323 NFHOOKCOND include/linux/netfilter.h:303 [inline] ipoutput+0x13b/0x2a0 net/ipv4/ipoutput.c:433 dstoutput include/net/dst.h:451 [inline] iplocalout+0xaf/0x1a0 net/ipv4/ipoutput.c:129 iptunnelxmit+0x5b4/0x9b0 net/ipv4/iptunnelcore.c:82 ipip6tunnelxmit net/ipv6/sit.c:1034 [inline] sittunnelxmit+0xed2/0x28f0 net/ipv6/sit.c:1076 netdevstartxmit include/linux/netdevice.h:4940 [inline] netdevstartxmit include/linux/netdevice.h:4954 [inline] xmitone net/core/dev.c:3545 [inline] devhardstartxmit+0x13d/0x6d0 net/core/dev.c:3561 devqueuexmit+0x7c1/0x3d60 net/core/dev.c:4346 devqueuexmit include/linux/netdevice.h:3134 [inline] packetxmit+0x257/0x380 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3087 [inline] packetsendmsg+0x24ca/0x5240 net/packet/afpacket.c:3119 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0xd5/0x180 net/socket.c:745 syssendto+0x255/0x340 net/socket.c:2190 dosyssendto net/socket.c:2202 [inline] sesyssendto net/socket.c:2198 [inline] x64syssendto+0xe0/0x1b0 net/socket.c:2198 dosyscallx64 arch/x86/entry/common.c:51 [inline] dosyscall64+0x40/0x110 arch/x86/entry/common.c:82 entrySYSCALL64afterhwframe+0x63/0x6b
Found by Linux Verification Center (linuxtesting.org) with Syzkaller
bpf: Fix memleak due to fentry attach failure
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Fix reference count leak in hswephaslimitsbox()
pcigetdevice() will increase the reference count for the returned 'dev'. We need to call pcidevput() to decrease the reference count. Since 'dev' is only used in pcireadconfigdword(), let's add pcidevput() right after it.
In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix memory leak in tracingreadpipe()
kmemleak reports this issue:
unreferenced object 0xffff888105a18900 (size 128): comm "testprogs", pid 18933, jiffies 4336275356 (age 22801.766s) hex dump (first 32 bytes): 25 73 00 90 81 88 ff ff 26 05 00 00 42 01 58 04 %s......&...B.X. 03 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<00000000560143a1>] kmallocnodetrackcaller+0x4a/0x140 [<000000006af00822>] krealloc+0x8d/0xf0 [<00000000c309be6a>] traceiterexpandformat+0x99/0x150 [<000000005a53bdb6>] tracecheckvprintf+0x1e0/0x11d0 [<0000000065629d9d>] traceeventprintf+0xb6/0xf0 [<000000009a690dc7>] tracerawoutputbpftraceprintk+0x89/0xc0 [<00000000d22db172>] printtraceline+0x73c/0x1480 [<00000000cdba76ba>] tracingreadpipe+0x45c/0x9f0 [<0000000015b58459>] vfsread+0x17b/0x7c0 [<000000004aeee8ed>] ksysread+0xed/0x1c0 [<0000000063d3d898>] dosyscall64+0x3b/0x90 [<00000000a06dda7f>] entrySYSCALL64afterhwframe+0x63/0xcd
iter->fmt alloced in tracingreadpipe() -> .. ->traceiterexpandformat(), but not freed, to fix, add free in tracingreleasepipe()
In the Linux kernel, the following vulnerability has been resolved:
drm/meson: fix shutdown crash when component not probed
When main component is not probed, by example when the dw-hdmi module is not loaded yet or in probe defer, the following crash appears on shutdown:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000038 ... pc : mesondrvshutdown+0x24/0x50 lr : platformdrvshutdown+0x20/0x30 ... Call trace: mesondrvshutdown+0x24/0x50 platformdrvshutdown+0x20/0x30 deviceshutdown+0x158/0x360 kernelrestartprepare+0x38/0x48 kernelrestart+0x18/0x68 dosysreboot+0x224/0x250 arm64sysreboot+0x24/0x30 ...
Simply check if the priv struct has been allocated before using it.
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: free queued packets when closing socket
As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b ("vsock/virtio: free packets during the socket release"), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work.
To avoid future issues, let's use the new virtiotransportremovesock() to drain the RX queue before removing the socket from the afvsock lists calling vsockremovesock().
[1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7615: fix memleak when mt7615unregisterdevice()
mt7615txtokenput() should get call before mt76freependingtxwi().
In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: fix memleak when mt7915unregisterdevice()
mt7915txtokenput() should get call before mt76freependingtxwi().
In the Linux kernel, the following vulnerability has been resolved:
bnxten: Fix RX consumer index logic in the error path.
In bnxtrxpkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxtdiscardrx() is not correct. We should be passing the current index (tmprawcons) instead of the old index (rawcons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this:
#0 [ffff9bbcdf5c39a8] machinekexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] crashkexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oopsend at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] nocontext at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] badareanosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] badareanosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] dopagefault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] dopagefault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] pagefault at ffffffff9bc015c5 [exception RIP: bnxtrxpkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIGRAX: ffffffffffffffff CS: 0010 SS: 0018
In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix memory leak on object td
Two error return paths are neglecting to free allocated object td, causing a memory leak. Fix this by returning via the error return path that securely kfree's td.
Fixes clang scan-build warning: security/keys/trusted-keys/trustedtpm1.c:496:10: warning: Potential memory leak [unix.Malloc]
In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix potential null dereference on pointer status
There are calls to idxdcmdexec that pass a null status pointer however a recent commit has added an assignment to status that can end up with a null pointer dereference. The function expects a null status pointer sometimes as there is a later assignment to status where status is first null checked. Fix the issue by null checking status before making the assignment.
Addresses-Coverity: ("Explicit null dereferenced")
In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix null pointer dereference in svcrqstfree()
When allocpagesnode() returns null in svcrqstalloc(), the null rqscratchpage pointer will be dereferenced when calling putpage() in svcrqstfree(). Fix it by adding a null check.
Addresses-Coverity: ("Dereference after null check")
In the Linux kernel, the following vulnerability has been resolved:
powerpc/64s: Fix crashes when toggling entry flush barrier
The entry flush mitigation can be enabled/disabled at runtime via a debugfs file (entryflush), which causes the kernel to patch itself to enable/disable the relevant mitigations.
However depending on which mitigation we're using, it may not be safe to do that patching while other CPUs are active. For example the following crash:
sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20
Shows that we returned to userspace with a corrupted LR that points into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed the LR restore).
Fix it by doing the patching under stop machine. The CPUs that aren't doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock when cloning inline extents and using qgroups
There are a few exceptional cases where cloning an inline extent needs to copy the inline extent data into a page of the destination inode.
When this happens, we end up starting a transaction while having a dirty page for the destination inode and while having the range locked in the destination's inode iotree too. Because when reserving metadata space for a transaction we may need to flush existing delalloc in case there is not enough free space, we have a mechanism in place to prevent a deadlock, which was introduced in commit 3d45f221ce627d ("btrfs: fix deadlock when cloning inline extent and low on free metadata space").
However when using qgroups, a transaction also reserves metadata qgroup space, which can also result in flushing delalloc in case there is not enough available space at the moment. When this happens we deadlock, since flushing delalloc requires locking the file range in the inode's iotree and the range was already locked at the very beginning of the clone operation, before attempting to start the transaction.
When this issue happens, stack traces like the following are reported:
[72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wbworkfn (flush-btrfs-1142) [72747.556271] Call Trace: [72747.556273] schedule+0x296/0x760 [72747.556277] schedule+0x3c/0xa0 [72747.556279] ioschedule+0x12/0x40 [72747.556284] lockpage+0x13c/0x280 [72747.556287] ? genericfilereadonlymmap+0x70/0x70 [72747.556325] extentwritecachepages+0x22a/0x440 [btrfs] [72747.556331] ? setpagedirtynobuffers+0xe7/0x160 [72747.556358] ? setextentbufferdirty+0x5e/0x80 [btrfs] [72747.556362] ? updategroupcapacity+0x25/0x210 [72747.556366] ? cpumasknextand+0x1a/0x20 [72747.556391] extentwritepages+0x44/0xa0 [btrfs] [72747.556394] dowritepages+0x41/0xd0 [72747.556398] writebacksingleinode+0x39/0x2a0 [72747.556403] writebacksbinodes+0x1ea/0x440 [72747.556407] writebackinodeswb+0x5f/0xc0 [72747.556410] wbwriteback+0x235/0x2b0 [72747.556414] ? getnrinodes+0x35/0x50 [72747.556417] wbworkfn+0x354/0x490 [72747.556420] ? newidlebalance+0x2c5/0x3e0 [72747.556424] processonework+0x1aa/0x340 [72747.556426] workerthread+0x30/0x390 [72747.556429] ? createworker+0x1a0/0x1a0 [72747.556432] kthread+0x116/0x130 [72747.556435] ? kthreadpark+0x80/0x80 [72747.556438] retfromfork+0x1f/0x30
[72747.566958] Workqueue: btrfs-flushdelalloc btrfsworkhelper [btrfs] [72747.566961] Call Trace: [72747.566964] schedule+0x296/0x760 [72747.566968] ? finishwait+0x80/0x80 [72747.566970] schedule+0x3c/0xa0 [72747.566995] waitextentbit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999] ? finishwait+0x80/0x80 [72747.567024] lockextentbits+0x37/0x90 [btrfs] [72747.567047] btrfsinvalidatepage+0x299/0x2c0 [btrfs] [72747.567051] ? findgetpagesrangetag+0x2cd/0x380 [72747.567076] extentwritepage+0x203/0x320 [btrfs] [72747.567102] extentwritecachepages+0x2bb/0x440 [btrfs] [72747.567106] ? updateloadavg+0x7e/0x5f0 [72747.567109] ? enqueueentity+0xf4/0x6f0 [72747.567134] extentwritepages+0x44/0xa0 [btrfs] [72747.567137] ? enqueuetaskfair+0x93/0x6f0 [72747.567140] dowritepages+0x41/0xd0 [72747.567144] filemapfdatawriterange+0xc7/0x100 [72747.567167] btrfsrundelallocwork+0x17/0x40 [btrfs] [72747.567195] btrfsworkhelper+0xc2/0x300 [btrfs] [72747.567200] processonework+0x1aa/0x340 [72747.567202] workerthread+0x30/0x390 [72747.567205] ? createworker+0x1a0/0x1a0 [72747.567208] kthread+0x116/0x130 [72747.567211] ? kthreadpark+0x80/0x80 [72747.567214] retfromfork+0x1f/0x30
[72747.569686] task:fsstress state:D stack: ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
ACPI: scan: Fix a memory leak in an error handling path
If 'acpidevicesetname()' fails, we must free 'acpidevicebusid->busid' or there is a (potential) memory leak.
In the Linux kernel, the following vulnerability has been resolved:
nbd: Fix NULL pointer in flushworkqueue
Open /dev/nbdX first, the configrefs will be 1 and the pointers in nbddevice are still null. Disconnect /dev/nbdX, then reference a null recvworkq. The protection by configrefs in nbdgenldisconnect is useless.
[ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: errorcode(0x0002) - not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutexlock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 <f0> 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flushworkqueue+0x92/0x6c0 [ 656.385395] nbddisconnectandput+0x81/0xd0 [ 656.385716] nbdgenldisconnect+0x125/0x2a0 [ 656.386034] genlfamilyrcvmsgdoit.isra.0+0x102/0x1b0 [ 656.386422] genlrcvmsg+0xfc/0x2b0 [ 656.386685] ? nbdioctl+0x490/0x490 [ 656.386954] ? genlfamilyrcvmsgdoit.isra.0+0x1b0/0x1b0 [ 656.387354] netlinkrcvskb+0x62/0x180 [ 656.387638] genlrcv+0x34/0x60 [ 656.387874] netlinkunicast+0x26d/0x590 [ 656.388162] netlinksendmsg+0x398/0x6c0 [ 656.388451] ? netlinkrcvskb+0x180/0x180 [ 656.388750] syssendmsg+0x1da/0x320 [ 656.389038] ? sysrecvmsg+0x130/0x220 [ 656.389334] syssendmsg+0x8e/0xf0 [ 656.389605] ? sysrecvmsg+0xa2/0xf0 [ 656.389889] ? handlemmfault+0x1671/0x21d0 [ 656.390201] syssendmsg+0x6d/0xe0 [ 656.390464] x64syssendmsg+0x23/0x30 [ 656.390751] dosyscall64+0x45/0x70 [ 656.391017] entrySYSCALL64afterhwframe+0x44/0xa9
To fix it, just add if (nbd->recvworkq) to nbddisconnectandput().
In the Linux kernel, the following vulnerability has been resolved:
net: hso: fix NULL-deref on disconnect regression
Commit 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device unregistration") fixed the racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on every disconnect instead.
Specifically, the serial device table must no longer be accessed after the minor has been released by hsoserialttyunregister().
In the Linux kernel, the following vulnerability has been resolved:
perf/x86/intel/uncore: Fix die ID init and look up bugs
In snbeppci2phymapinit(), in the nrnodeids > 8 path, uncoredevicetodie() may return -1 when all CPUs associated with the UBOX device are offline.
Remove the WARNONONCE(dieid == -1) check for two reasons:
- The current code breaks out of the loop. This is incorrect because pcigetdevice() does not guarantee iteration in domain or bus order, so additional UBOX devices may be skipped during the scan.
- Returning -EINVAL is incorrect, since marking offline buses with dieid == -1 is expected and should not be treated as an error.
Separately, when NUMA is disabled on a NUMA-capable platform, pcibustonode() returns NUMANONODE, causing uncoredevicetodie() to return -1 for all PCI devices. As a result, sprupdatedevicelocation(), used on Intel SPR and EMR, ignores the corresponding PMON units and does not add them to the RB tree.
Fix this by using uncorepcibustodieid(), which retrieves topology from the UBOX GIDNIDMAP register and works regardless of whether NUMA is enabled in Linux. This requires snbeppci2phymapinit() to be added in spruncorepciinit().
Keep uncoredevicetodie() only for the nrnodeids > 8 case, where NUMA is expected to be enabled.