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:
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---
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:
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
A race condition was found in the Linux kernel's media/xc4000 device driver in xc4000 xc4000getfrequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.
A race condition was found in the Linux kernel's net/bluetooth in sniff{min,max}intervalset() function. This can result in a bluetooth sniffing exception issue, possibly leading denial of service.
A race condition was found in the Linux kernel's media/dvb-core in dvbdmxwrite()Â function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.
A race condition was found in the Linux kernel's net/bluetooth in {conn,adv}{min,max}intervalset() function. This can result in I2cap connection or broadcast abnormality issue, possibly leading to denial of service.
A race condition was found in the Linux kernel's net/bluetooth device driver in conninfo{min,max}ageset() function. This can result in integrity overflow issue, possibly leading to bluetooth connection abnormality or denial of service.
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.