In the Linux kernel, the following vulnerability has been resolved:
net: veth: clear GRO when clearing XDP even when down
The Linux kernel CVE team has assigned CVE-2024-26803 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040404-CVE-2024-26803-9985@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
iommufd: Fix protection fault in iommufdtestsyzconviova
Syzkaller reported the following bug:
general protection fault, probably for non-canonical address 0xdffffc0000000038: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000001c0-0x00000000000001c7] Call Trace: lockacquire lockacquire+0x1ce/0x4f0 downread+0x93/0x4a0 iommufdtestsyzconviova+0x56/0x1f0 iommufdtestaccessrw.isra.0+0x2ec/0x390 iommufdtest+0x1058/0x1e30 iommufdfopsioctl+0x381/0x510 vfsioctl dosysioctl sesysioctl x64sysioctl+0x170/0x1e0 dosyscallx64 dosyscall64+0x71/0x140
This is because the new iommufdaccesschangeioas() sets access->ioas to NULL during its process, so the lock might be gone in a concurrent racing context.
Fix this by doing the same access->ioas sanity as iommufdaccessrw() and iommufdaccesspinpages() functions do.
In the Linux kernel, the following vulnerability has been resolved:
xen/events: close evtchn after mapping cleanup
shutdownpirq and startuppirq are not taking the irqmappingupdatelock because they can't due to lock inversion. Both are called with the irqdesc->lock being taking. The lock order, however, is first irqmappingupdatelock and then irqdesc->lock.
This opens multiple races: - shutdownpirq can be interrupted by a function that allocates an event channel:
CPU0 CPU1 shutdownpirq { xenevtchnclose(e) startuppirq { EVTCHNOPbindpirq -> returns just freed evtchn e setevtchntoirq(e, irq) } xenirqinfocleanup() { setevtchntoirq(e, -1) } }
Assume here event channel e refers here to the same event channel number. After this race the evtchntoirq mapping for e is invalid (-1).
- startuppirq races with unbindfromirq in a similar way. Because startuppirq doesn't take irqmappingupdatelock it can grab the evtchn that unbindfromirq is currently freeing and cleaning up. In this case even though the event channel is allocated, its mapping can be unset in evtchntoirq.
The fix is to first cleanup the mappings and then close the event channel. In this way, when an event channel gets allocated it's potential previous evtchntoirq mappings are guaranteed to be unset already. This is also the reverse order of the allocation where first the event channel is allocated and then the mappings are setup.
On a 5.10 kernel prior to commit 3fcdaf3d7634 ("xen/events: modify internal [un]bind interfaces"), we hit a BUG like the following during probing of NVMe devices. The issue is that during nvmesetupioqueues, pcifreeirq is called for every device which results in a call to shutdownpirq. With many nvme devices it's therefore likely to hit this race during boot because there will be multiple calls to shutdownpirq and startuppirq are running potentially in parallel.
------------[ cut here ]------------ blkfront: xvda: barrier or flush: disabled; persistent grants: enabled; indirect descriptors: enabled; bounce buffer: enabled kernel BUG at drivers/xen/events/eventsbase.c:499! invalid opcode: 0000 [#1] SMP PTI CPU: 44 PID: 375 Comm: kworker/u257:23 Not tainted 5.10.201-191.748.amzn2.x8664 #1 Hardware name: Xen HVM domU, BIOS 4.11.amazon 08/24/2006 Workqueue: nvme-reset-wq nvmeresetwork RIP: 0010:bindevtchntocpu+0xdf/0xf0 Code: 5d 41 5e c3 cc cc cc cc 44 89 f7 e8 2b 55 ad ff 49 89 c5 48 85 c0 0f 84 64 ff ff ff 4c 8b 68 30 41 83 fe ff 0f 85 60 ff ff ff <0f> 0b 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 0f 1f 44 00 00 RSP: 0000:ffffc9000d533b08 EFLAGS: 00010046 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000006 RDX: 0000000000000028 RSI: 00000000ffffffff RDI: 00000000ffffffff RBP: ffff888107419680 R08: 0000000000000000 R09: ffffffff82d72b00 R10: 0000000000000000 R11: 0000000000000000 R12: 00000000000001ed R13: 0000000000000000 R14: 00000000ffffffff R15: 0000000000000002 FS: 0000000000000000(0000) GS:ffff88bc8b500000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 0000000002610001 CR4: 00000000001706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? showtraceloglvl+0x1c1/0x2d9 ? showtraceloglvl+0x1c1/0x2d9 ? setaffinityirq+0xdc/0x1c0 ? diebody.cold+0x8/0xd ? die+0x2b/0x50 ? dotrap+0x90/0x110 ? bindevtchntocpu+0xdf/0xf0 ? doerrortrap+0x65/0x80 ? bindevtchntocpu+0xdf/0xf0 ? excinvalidop+0x4e/0x70 ? bindevtchntocpu+0xdf/0xf0 ? asmexcinvalidop+0x12/0x20 ? bindevtchntocpu+0xdf/0x ---truncated---
fs/proc: dotaskstat: use sig->statslock to gather the threads/children stats
A flaw in the Linux Kernel found in the Open vSwitch Kernel module.
The Netlink copy code in the ovs kernel module attempts to make an in-kernel copy of the actions required. That means that when recursive operations, like sample(), clone(), decttl(), etc include additional actions, the code pushes a new stack frame and recursively calls into the code block.
Unfortunately, OVS module doesn't validate the stack depth, and will push too many frames causing a stack overflow which can lead to crash.
Reference: https://lore.kernel.org/all/20240207132416.1488485-1-aconole@redhat.com/
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: reject immediate NFQUEUE verdict
nftqueue is always used from userspace nftables to deliver the NFQUEUE verdict. Immediately emitting an NFQUEUE verdict is never used by the userspace nft tools, so reject immediate NFQUEUE verdicts.
The arp family does not provide queue support, but such an immediate verdict is still reachable. Globally reject NFQUEUE immediate verdicts to address this issue.
In the Linux kernel, the following vulnerability has been resolved:
mm/vmscan: fix a bug calling wakeupkswapd() with a wrong zone index
The Linux kernel CVE team has assigned CVE-2024-26783 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024040458-CVE-2024-26783-68c8@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ncm: Fix handling of zero block length packets
While connecting to a Linux host with CDCNCMNTBDEFSIZETX set to 65536, it has been observed that we receive short packets, which come at interval of 5-10 seconds sometimes and have block length zero but still contain 1-2 valid datagrams present.
According to the NCM spec:
"If wBlockLength = 0x0000, the block is terminated by a short packet. In this case, the USB transfer must still be shorter than dwNtbInMaxSize or dwNtbOutMaxSize. If exactly dwNtbInMaxSize or dwNtbOutMaxSize bytes are sent, and the size is a multiple of wMaxPacketSize for the given pipe, then no ZLP shall be sent.
wBlockLength= 0x0000 must be used with extreme care, because of the possibility that the host and device may get out of sync, and because of test issues.
wBlockLength = 0x0000 allows the sender to reduce latency by starting to send a very large NTB, and then shortening it when the sender discovers that there’s not sufficient data to justify sending a large NTB"
However, there is a potential issue with the current implementation, as it checks for the occurrence of multiple NTBs in a single giveback by verifying if the leftover bytes to be processed is zero or not. If the block length reads zero, we would process the same NTB infintely because the leftover bytes is never zero and it leads to a crash. Fix this by bailing out if block length reads zero.
In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures is not enough for a 64-bit physaddrt:
drivers/firmware/efi/capsule-loader.c: In function 'eficapsuleopen': drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'physaddrt' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size] 295 | capinfo->phys = kzalloc(sizeof(void ), GFPKERNEL); | ^
Use the correct type instead here.
In the Linux kernel, the following vulnerability has been resolved:
power: supply: bq27xxx-i2c: Do not free non existing IRQ
The bq27xxx i2c-client may not have an IRQ, in which case client->irq will be 0. bq27xxxbatteryi2cprobe() already has an if (client->irq) check wrapping the requestthreadedirq().
But bq27xxxbatteryi2cremove() unconditionally calls freeirq(client->irq) leading to:
[ 190.310742] ------------[ cut here ]------------ [ 190.310843] Trying to free already-free IRQ 0 [ 190.310861] WARNING: CPU: 2 PID: 1304 at kernel/irq/manage.c:1893 freeirq+0x1b8/0x310
Followed by a backtrace when unbinding the driver. Add an if (client->irq) to bq27xxxbatteryi2cremove() mirroring probe() to fix this.
In the Linux kernel, the following vulnerability has been resolved:
tracing/trigger: Fix to return error if failed to alloc snapshot
Fix registersnapshottrigger() to return error code if it failed to allocate a snapshot instead of 0 (success). Unless that, it will register snapshot trigger without an error.
In the Linux kernel, the following vulnerability has been resolved:
scsi: Revert "scsi: fcoe: Fix potential deadlock on &fip->ctlrlock"
This reverts commit 1a1975551943f681772720f639ff42fbaa746212.
This commit causes interrupts to be lost for FCoE devices, since it changed sping locks from "bh" to "irqsave".
Instead, a work queue should be used, and will be addressed in a separate commit.
In the Linux kernel, the following vulnerability has been resolved:
Revert "drm/amd: flush any delayed gfxoff on suspend entry"
commit ab4750332dbe ("drm/amdgpu/sdma5.2: add begin/enduse ring callbacks") caused GFXOFF control to be used more heavily and the codepath that was removed from commit 0dee72639533 ("drm/amd: flush any delayed gfxoff on suspend entry") now can be exercised at suspend again.
Users report that by using GNOME to suspend the lockscreen trigger will cause SDMA traffic and the system can deadlock.
This reverts commit 0dee726395333fea833eaaf838bc80962df886c8.
In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Use a memory barrier to enforce PTP WQ xmit submission tracking occurs after populating the metadatamap
Just simply reordering the functions mlx5eptpmetadatamapput and mlx5eptpsqtrackmetadata in the mlx5etxwqecomplete context is not good enough since both the compiler and CPU are free to reorder these two functions. If reordering does occur, the issue that was supposedly fixed by 7e3f3ba97e6c ("net/mlx5e: Track xmit submission to PTP WQ after populating metadata map") will be seen. This will lead to NULL pointer dereferences in mlx5eptpsqmarktscqesundelivered in the NAPI polling context due to the tracking list being populated before the metadata map.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: set dormant flag on hook register failure
The Linux kernel CVE team has assigned CVE-2024-26835 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024041714-CVE-2024-26835-083d@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
mm: zswap: fix missing folio cleanup in writeback race path
In zswapwritebackentry(), after we get a folio from readswapcacheasync(), we grab the tree lock again to check that the swap entry was not invalidated and recycled. If it was, we delete the folio we just added to the swap cache and exit.
However, readswapcacheasync() returns the folio locked when it is newly allocated, which is always true for this path, and the folio is ref'd. Make sure to unlock and put the folio before returning.
This was discovered by code inspection, probably because this path handles a race condition that should not happen often, and the bug would not crash the system, it will only strand the folio indefinitely.
In the Linux kernel, the following vulnerability has been resolved:
net/handshake: Fix handshakereqdestroytest1
Recently, handshakereqdestroytest1 started failing:
Expected handshakereqdestroytest == req, but handshakereqdestroytest == 0000000000000000 req == 0000000060f99b40 not ok 11 reqdestroy works
This is because "sockrelease(sock)" was replaced with "fput(filp)" to address a memory leak. Note that sockrelease() is synchronous but fput() usually delays the final close and clean-up.
The delay is not consequential in the other cases that were changed but handshakereqdestroytest1 is testing that handshakereqcancel() followed by closing the file actually does call the ->hpdestroy method. Thus the PTREQ test at the end has to be sure that the final close is complete before it checks the pointer.
We cannot use a completion here because if ->hpdestroy is never called (ie, there is an API bug) then the test will hang.
Reported by: Guenter Roeck <linux@roeck-us.net>
In the Linux kernel, the following vulnerability has been resolved:
media: irtoy: fix a memleak in irtoytx
When irtoycommand fails, buf should be freed since it is allocated by irtoytx, or there is a memleak.
In the Linux kernel, the following vulnerability has been resolved:
hvnetvsc: Register VF in netvscprobe if NETDEVICEREGISTER missed
If hvnetvsc driver is unloaded and reloaded, the NETDEVICEREGISTER handler cannot perform VF register successfully as the register call is received before netvscprobe is finished. This is because we register registernetdevicenotifier() very early( even before vmbusdriverregister()). To fix this, we try to register each such matching VF( if it is visible as a netdevice) at the end of netvscprobe.
In the Linux kernel, the following vulnerability has been resolved:
netlink: Fix kernel-infoleak-after-free in skbdatagramiter
syzbot reported the following uninit-value access issue [1]:
netlinktofullskb() creates a new skb and puts the skb->data passed as a 1st arg of netlinktofullskb() onto new skb. The data size is specified as len and passed to skbputdata(). This len is based on skb->end that is not data offset but buffer offset. The skb->end contains data and tailroom. Since the tailroom is not initialized when the new skb created, KMSAN detects uninitialized memory area when copying the data.
This patch resolved this issue by correct the len from skb->end to skb->len, which is the actual data offset.
BUG: KMSAN: kernel-infoleak-after-free in instrumentcopytouser include/linux/instrumented.h:114 [inline] BUG: KMSAN: kernel-infoleak-after-free in copytouseriter lib/ioviter.c:24 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateubuf include/linux/ioviter.h:29 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateandadvance2 include/linux/ioviter.h:245 [inline] BUG: KMSAN: kernel-infoleak-after-free in iterateandadvance include/linux/ioviter.h:271 [inline] BUG: KMSAN: kernel-infoleak-after-free in copytoiter+0x364/0x2520 lib/ioviter.c:186 instrumentcopytouser include/linux/instrumented.h:114 [inline] copytouseriter lib/ioviter.c:24 [inline] iterateubuf include/linux/ioviter.h:29 [inline] iterateandadvance2 include/linux/ioviter.h:245 [inline] iterateandadvance include/linux/ioviter.h:271 [inline] copytoiter+0x364/0x2520 lib/ioviter.c:186 copytoiter include/linux/uio.h:197 [inline] simplecopytoiter+0x68/0xa0 net/core/datagram.c:532 skbdatagramiter+0x123/0xdc0 net/core/datagram.c:420 skbcopydatagramiter+0x5c/0x200 net/core/datagram.c:546 skbcopydatagrammsg include/linux/skbuff.h:3960 [inline] packetrecvmsg+0xd9c/0x2000 net/packet/afpacket.c:3482 sockrecvmsgnosec net/socket.c:1044 [inline] sockrecvmsg net/socket.c:1066 [inline] sockreaditer+0x467/0x580 net/socket.c:1136 callreaditer include/linux/fs.h:2014 [inline] newsyncread fs/readwrite.c:389 [inline] vfsread+0x8f6/0xe00 fs/readwrite.c:470 ksysread+0x20f/0x4c0 fs/readwrite.c:613 dosysread fs/readwrite.c:623 [inline] sesysread fs/readwrite.c:621 [inline] x64sysread+0x93/0xd0 fs/readwrite.c:621 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
Uninit was stored to memory at: skbputdata include/linux/skbuff.h:2622 [inline] netlinktofullskb net/netlink/afnetlink.c:181 [inline] netlinkdelivertapskb net/netlink/afnetlink.c:298 [inline] netlinkdelivertap+0x5be/0xc90 net/netlink/afnetlink.c:325 netlinkdelivertap net/netlink/afnetlink.c:338 [inline] netlinkdelivertapkernel net/netlink/afnetlink.c:347 [inline] netlinkunicastkernel net/netlink/afnetlink.c:1341 [inline] netlinkunicast+0x10f1/0x1250 net/netlink/afnetlink.c:1368 netlinksendmsg+0x1238/0x13d0 net/netlink/afnetlink.c:1910 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendmsg+0x9c2/0xd60 net/socket.c:2584 syssendmsg+0x28d/0x3c0 net/socket.c:2638 syssendmsg net/socket.c:2667 [inline] dosyssendmsg net/socket.c:2676 [inline] sesyssendmsg net/socket.c:2674 [inline] x64syssendmsg+0x307/0x490 net/socket.c:2674 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0x44/0x110 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
Uninit was created at: freepagesprepare mm/pagealloc.c:1087 [inline] freeunrefpageprepare+0xb0/0xa40 mm/pagealloc.c:2347 freeunrefpagelist+0xeb/0x1100 mm/pagealloc.c:2533 releasepages+0x23d3/0x2410 mm/swap.c:1042 freepagesandswapcache+0xd9/0xf0 mm/swapstate.c:316 tlbbatchpages ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
fbcon: always restore the old font data in fbcondosetfont()
Commit a5a923038d70 (fbdev: fbcon: Properly revert changes when vcresize() failed) started restoring old font data upon failure (of vcresize()). But it performs so only for user fonts. It means that the "system"/internal fonts are not restored at all. So in result, the very first call to fbcondosetfont() performs no restore at all upon failing vcresize().
This can be reproduced by Syzkaller to crash the system on the next invocation of fontget(). It's rather hard to hit the allocation failure in vcresize() on the first fontset(), but not impossible. Esp. if fault injection is used to aid the execution/failure. It was demonstrated by Sirius: BUG: unable to handle page fault for address: fffffffffffffff8 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD cb7b067 P4D cb7b067 PUD cb7d067 PMD 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8007 Comm: poc Not tainted 6.7.0-g9d1694dc91ce #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:fbcongetfont+0x229/0x800 drivers/video/fbdev/core/fbcon.c:2286 Call Trace: <TASK> confontget drivers/tty/vt/vt.c:4558 [inline] confontop+0x1fc/0xf20 drivers/tty/vt/vt.c:4673 vtkioctl drivers/tty/vt/vtioctl.c:474 [inline] vtioctl+0x632/0x2ec0 drivers/tty/vt/vtioctl.c:752 ttyioctl+0x6f8/0x1570 drivers/tty/ttyio.c:2803 vfsioctl fs/ioctl.c:51 [inline] ...
So restore the font data in any case, not only for user fonts. Note the later 'if' is now protected by 'olduserfont' and not 'olddata' as the latter is always set now. (And it is supposed to be non-NULL. Otherwise we would see the bug above again.)
In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid dividing by 0 in mbupdateavgfragmentsize() when block bitmap corrupt
Determine if bbfragments is 0 instead of determining bbfree to eliminate the risk of dividing by zero when the block bitmap is corrupted.
In the Linux kernel, the following vulnerability has been resolved:
l2tp: pass correct message length to ip6appenddata
l2tpip6sendmsg needs to avoid accounting for the transport header twice when splicing more data into an already partially-occupied skbuff.
To manage this, we check whether the skbuff contains data using skbqueueempty when deciding how much data to append using ip6appenddata.
However, the code which performed the calculation was incorrect:
ulen = len + skbqueueempty(&sk->skwritequeue) ? transhdrlen : 0;
...due to C operator precedence, this ends up setting ulen to transhdrlen for messages with a non-zero length, which results in corrupted packets on the wire.
Add parentheses to correct the calculation in line with the original intent.
In the Linux kernel, the following vulnerability has been resolved:
usb: roles: fix NULL pointer issue when put module's reference
In current design, usb role class driver will get usbroleswitch parent's module reference after the user get usbroleswitch device and put the reference after the user put the usbroleswitch device. However, the parent device of usbroleswitch may be removed before the user put the usbroleswitch. If so, then, NULL pointer issue will be met when the user put the parent module's reference.
This will save the module pointer in structure of usbroleswitch. Then, we don't need to find module by iterating long relations.
In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/iommu: IOMMU table is not initialized for kdump over SR-IOV
When kdump kernel tries to copy dump data over SR-IOV, LPAR panics due to NULL pointer exception:
Kernel attempted to read user page (0) - exploit attempt? (uid: 0) BUG: Kernel NULL pointer dereference on read at 0x00000000 Faulting instruction address: 0xc000000020847ad4 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGESIZE=64K MMU=Radix SMP NRCPUS=2048 NUMA pSeries Modules linked in: mlx5core(+) vmxcrypto pserieswdt paprscm libnvdimm mlxfw tls psample sunrpc fuse overlay squashfs loop CPU: 12 PID: 315 Comm: systemd-udevd Not tainted 6.4.0-Test102+ #12 Hardware name: IBM,9080-HEX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NH1060008) hv:phyp pSeries NIP: c000000020847ad4 LR: c00000002083b2dc CTR: 00000000006cd18c REGS: c000000029162ca0 TRAP: 0300 Not tainted (6.4.0-Test102+) MSR: 800000000280b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 48288244 XER: 00000008 CFAR: c00000002083b2d8 DAR: 0000000000000000 DSISR: 40000000 IRQMASK: 1 ... NIP findnextzerobit+0x24/0x110 LR bitmapfindnextzeroareaoff+0x5c/0xe0 Call Trace: devprintkemit+0x38/0x48 (unreliable) iommuareaalloc+0xc4/0x180 iommurangealloc+0x1e8/0x580 iommualloc+0x60/0x130 iommualloccoherent+0x158/0x2b0 dmaiommualloccoherent+0x3c/0x50 dmaallocattrs+0x170/0x1f0 mlx5cmdinit+0xc0/0x760 [mlx5core] mlx5functionsetup+0xf0/0x510 [mlx5core] mlx5initone+0x84/0x210 [mlx5core] probeone+0x118/0x2c0 [mlx5core] localpciprobe+0x68/0x110 pcicallprobe+0x68/0x200 pcideviceprobe+0xbc/0x1a0 reallyprobe+0x104/0x540 driverprobedevice+0xb4/0x230 driverprobedevice+0x54/0x130 driverattach+0x158/0x2b0 busforeachdev+0xa8/0x130 driverattach+0x34/0x50 busadddriver+0x16c/0x300 driverregister+0xa4/0x1b0 pciregisterdriver+0x68/0x80 mlx5init+0xb8/0x100 [mlx5core] dooneinitcall+0x60/0x300 doinitmodule+0x7c/0x2b0
At the time of LPAR dump, before kexec hands over control to kdump kernel, DDWs (Dynamic DMA Windows) are scanned and added to the FDT. For the SR-IOV case, default DMA window "ibm,dma-window" is removed from the FDT and DDW added, for the device.
Now, kexec hands over control to the kdump kernel.
When the kdump kernel initializes, PCI busses are scanned and IOMMU group/tables created, in pcidmabussetuppSeriesLP(). For the SR-IOV case, there is no "ibm,dma-window". The original commit: b1fc44eaa9ba, fixes the path where memory is pre-mapped (direct mapped) to the DDW. When TCEs are direct mapped, there is no need to initialize IOMMU tables.
iommutablesetparmslpar() only considers "ibm,dma-window" property when initiallizing IOMMU table. In the scenario where TCEs are dynamically allocated for SR-IOV, newly created IOMMU table is not initialized. Later, when the device driver tries to enter TCEs for the SR-IOV device, NULL pointer execption is thrown from iommuareaalloc().
The fix is to initialize the IOMMU table with DDW property stored in the FDT. There are 2 points to remember:
1. For the dedicated adapter, kdump kernel would encounter both default and DDW in FDT. In this case, DDW property is used to initialize the IOMMU table.
2. A DDW could be direct or dynamic mapped. kdump kernel would initialize IOMMU table and mark the existing DDW as "dynamic". This works fine since, at the time of table initialization, iommutableclear() makes some space in the DDW, for some predefined number of TCEs which are needed for kdump to succeed.
In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Fix NULL pointer dereference in skpsockverdictdataready()
syzbot reported the following NULL pointer dereference issue [1]:
BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:0x0 [...] Call Trace: <TASK> skpsockverdictdataready+0x232/0x340 net/core/skmsg.c:1230 unixstreamsendmsg+0x9b4/0x1230 net/unix/afunix.c:2293 socksendmsgnosec net/socket.c:730 [inline] socksendmsg+0x221/0x270 net/socket.c:745 syssendmsg+0x525/0x7d0 net/socket.c:2584 syssendmsg net/socket.c:2638 [inline] syssendmsg+0x2b0/0x3a0 net/socket.c:2667 dosyscall64+0xf9/0x240 entrySYSCALL64afterhwframe+0x6f/0x77
If skpsockverdictdataready() and skpsockstopverdict() are called concurrently, psock->saveddataready can be NULL, causing the above issue.
This patch fixes this issue by calling the appropriate data ready function using the skpsockdataready() helper and protecting it from concurrency with sk->skcallbacklock.
In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not ASSERT() if the newly created subvolume already got read
[BUG] There is a syzbot crash, triggered by the ASSERT() during subvolume creation:
assertion failed: !anondev, in fs/btrfs/disk-io.c:1319 ------------[ cut here ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfsgetrootref.part.0+0x9aa/0xa60 <TASK> btrfsgetnewfsroot+0xd3/0xf0 createsubvol+0xd02/0x1650 btrfsmksubvol+0xe95/0x12b0 btrfsioctlsnapcreate+0x2f9/0x4f0 btrfsioctlsnapcreate+0x16b/0x200 btrfsioctl+0x35f0/0x5cf0 x64sysioctl+0x19d/0x210 dosyscall64+0x3f/0xe0 entrySYSCALL64afterhwframe+0x63/0x6b ---[ end trace 0000000000000000 ]---
[CAUSE] During createsubvol(), after inserting root item for the newly created subvolume, we would trigger btrfsgetnewfsroot() to get the btrfsroot of that subvolume.
The idea here is, we have preallocated an anonymous device number for the subvolume, thus we can assign it to the new subvolume.
But there is really nothing preventing things like backref walk to read the new subvolume. If that happens before we call btrfsgetnewfsroot(), the subvolume would be read out, with a new anonymous device number assigned already.
In that case, we would trigger ASSERT(), as we really expect no one to read out that subvolume (which is not yet accessible from the fs). But things like backref walk is still possible to trigger the read on the subvolume.
Thus our assumption on the ASSERT() is not correct in the first place.
[FIX] Fix it by removing the ASSERT(), and just free the @anondev, reset it to 0, and continue.
If the subvolume tree is read out by something else, it should have already get a new anondev assigned thus we only need to free the preallocated one.
In the Linux kernel, the following vulnerability has been resolved:
ASoC: rt5645: Fix deadlock in rt5645jackdetectwork()
There is a path in rt5645jackdetectwork(), where rt5645->jdmutex is left locked forever. That may lead to deadlock when rt5645jackdetectwork() is called for the second time.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
In the Linux kernel, the following vulnerability has been resolved:
usb: dwc3: gadget: Fix NULL pointer dereference in dwc3gadgetsuspend
In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadgetdriver in dwc3gadgetsuspend, a NULL pointer dereference may occur.
Call Stack:
CPU1: CPU2: gadgetunbinddriver dwc3suspendcommon dwc3gadgetstop dwc3gadgetsuspend dwc3disconnectgadget
CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadgetdriver is cleared and in parallel CPU2 executes dwc3gadgetsuspend where it finds dwc->gadgetdriver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3disconnectgadget where it checks dwc->gadgetdriver is already NULL because of which the NULL pointer deference occur.
In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Fix null pointer dereference in sevplatformshutdownlocked
The SEV platform device can be shutdown with a null pspmaster, e.g., using DEBUGTESTDRIVERREMOVE. Found using KASAN:
[ 137.148210] ccp 0000:23:00.1: enabling device (0000 -> 0002) [ 137.162647] ccp 0000:23:00.1: no command queues available [ 137.170598] ccp 0000:23:00.1: sev enabled [ 137.174645] ccp 0000:23:00.1: psp enabled [ 137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUGPAGEALLOC KASAN NOPTI [ 137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7] [ 137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311 [ 137.182693] RIP: 0010:sevplatformshutdownlocked+0x51/0x180 [ 137.182693] Code: 08 80 3c 08 00 0f 85 0e 01 00 00 48 8b 1d 67 b6 01 08 48 b8 00 00 00 00 00 fc ff df 48 8d bb f0 00 00 00 48 89 f9 48 c1 e9 03 <80> 3c 01 00 0f 85 fe 00 00 00 48 8b 9b f0 00 00 00 48 85 db 74 2c [ 137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216 [ 137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e [ 137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0 [ 137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66 [ 137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28 [ 137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8 [ 137.182693] FS: 0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000 [ 137.182693] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0 [ 137.182693] Call Trace: [ 137.182693] <TASK> [ 137.182693] ? showregs+0x6c/0x80 [ 137.182693] ? diebody+0x24/0x70 [ 137.182693] ? dieaddr+0x4b/0x80 [ 137.182693] ? excgeneralprotection+0x126/0x230 [ 137.182693] ? asmexcgeneralprotection+0x2b/0x30 [ 137.182693] ? sevplatformshutdownlocked+0x51/0x180 [ 137.182693] sevfirmwareshutdown.isra.0+0x1e/0x80 [ 137.182693] sevdevdestroy+0x49/0x100 [ 137.182693] pspdevdestroy+0x47/0xb0 [ 137.182693] spdestroy+0xbb/0x240 [ 137.182693] sppciremove+0x45/0x60 [ 137.182693] pcideviceremove+0xaa/0x1d0 [ 137.182693] deviceremove+0xc7/0x170 [ 137.182693] reallyprobe+0x374/0xbe0 [ 137.182693] ? srsoreturnthunk+0x5/0x5f [ 137.182693] driverprobedevice+0x199/0x460 [ 137.182693] driverprobedevice+0x4e/0xd0 [ 137.182693] driverattach+0x191/0x3d0 [ 137.182693] ? pfxdriverattach+0x10/0x10 [ 137.182693] busforeachdev+0x100/0x190 [ 137.182693] ? pfxbusforeachdev+0x10/0x10 [ 137.182693] ? kasancheckread+0x15/0x20 [ 137.182693] ? srsoreturnthunk+0x5/0x5f [ 137.182693] ? rawspinunlock+0x27/0x50 [ 137.182693] driverattach+0x41/0x60 [ 137.182693] busadddriver+0x2a8/0x580 [ 137.182693] driverregister+0x141/0x480 [ 137.182693] pciregisterdriver+0x1d6/0x2a0 [ 137.182693] ? srsoreturnthunk+0x5/0x5f [ 137.182693] ? esrtsysfsinit+0x1cd/0x5d0 [ 137.182693] ? pfxspmodinit+0x10/0x10 [ 137.182693] sppciinit+0x22/0x30 [ 137.182693] spmodinit+0x14/0x30 [ 137.182693] ? pfxspmodinit+0x10/0x10 [ 137.182693] dooneinitcall+0xd1/0x470 [ 137.182693] ? pfxdooneinitcall+0x10/0x10 [ 137.182693] ? parameq+0x80/0xf0 [ 137.182693] ? srsoreturnthunk+0x5/0x5f [ 137.182693] ? kmalloc+0x3b0/0x4e0 [ 137.182693] ? kernelinitfreeable+0x92d/0x1050 [ 137.182693] ? kasanpopulatevmallocpte+0x171/0x190 [ 137.182693] ? srsoreturnthunk+0x5/0x5f [ 137.182693] kernelinitfreeable+0xa64/0x1050 [ 137.182693] ? pfxkernelinit+0x10/0x10 [ 137.182693] kernelinit+0x24/0x160 [ 137.182693] ? switchtoasm+0x3e/0x70 [ 137.182693] retfromfork+0x40/0x80 [ 137.182693] ? pfxkernelinit+0x1 ---truncated---