An out-of-bounds write in the Graphite 2 library triggered with a maliciously crafted Graphite font. This results in a potentially exploitable crash. This issue was fixed in the Graphite 2 library as well as Mozilla products.
A flaw was found in the Netfilter module in the Linux kernel. The problem is in the nftbyteordereval() function where the code is iterating through a loop and writing to dst[0], dst[1], dst[2] and so on. On each iteration 8 bytes get written, but dst[] is an array of u32 so each element only has space for 4 bytes. That means that every iteration overwrites part of the previous element.
Upstream commit: https://github.com/torvalds/linux/commit/c301f0981fdd3fd1ffac6836b423c4d7a8e0eb63
In the Linux kernel, the following vulnerability has been resolved:
NFS: Fix the setting of capabilities when automounting a new filesystem
Capabilities cannot be inherited when we cross into a new filesystem. They need to be reset to the minimal defaults, and then probed for again.
In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix one NULL pointer dereference in smcibissgneedsync()
BUG: kernel NULL pointer dereference, address: 00000000000002ec PGD 0 P4D 0 Oops: Oops: 0000 [#1] SMP PTI CPU: 28 UID: 0 PID: 343 Comm: kworker/28:1 Kdump: loaded Tainted: G OE 6.17.0-rc2+ #9 NONE Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 Workqueue: smchswq smclistenwork [smc] RIP: 0010:smcibissgneedsync+0x9e/0xd0 [smc] ... Call Trace: <TASK> smcrbufmaplink+0x211/0x2a0 [smc] smcbufcreate+0x522/0x970 [smc] smcbufcreate+0x3a/0x110 [smc] smcfindrdmav2deviceserv+0x18f/0x240 [smc] ? smcvlanbytcpsk+0x7e/0xe0 [smc] smclistenfinddevice+0x1dd/0x2b0 [smc] smclistenwork+0x30f/0x580 [smc] processonework+0x18c/0x340 workerthread+0x242/0x360 kthread+0xe7/0x220 retfromfork+0x13a/0x160 retfromforkasm+0x1a/0x30 </TASK>
If the software RoCE device is used, ibdev->dmadevice is a null pointer. As a result, the problem occurs. Null pointer detection is added to prevent problems.
fs: writeback: fix use-after-free in markinodedirty()
Bluetooth: Fix use-after-free in l2capsockcleanuplisten()
In the Linux kernel, the following vulnerability has been resolved:
libceph: fix invalid accesses to cephconnectionv1info
There is a place where generic code in messenger.c is reading and another place where it is writing to con->v1 union member without checking that the union member is active (i.e. msgr1 is in use).
On 64-bit systems, con->v1.authretry overlaps with con->v2.outiter, so such a read is almost guaranteed to return a bogus value instead of 0 when msgr2 is in use. This ends up being fairly benign because the side effect is just the invalidation of the authorizer and successive fetching of new tickets.
con->v1.connectseq overlaps with con->v2.connbufs and the fact that it's being written to can cause more serious consequences, but luckily it's not something that happens often.
In the Linux kernel, the following vulnerability has been resolved:
mm/slub: avoid accessing metadata when pointer is invalid in objecterr()
objecterr() reports details of an object for further debugging, such as the freelist pointer, redzone, etc. However, if the pointer is invalid, attempting to access object metadata can lead to a crash since it does not point to a valid object.
One known path to the crash is when allocconsistencychecks() determines the pointer to the allocated object is invalid because of a freelist corruption, and calls objecterr() to report it. The debug code should report and handle the corruption gracefully and not crash in the process.
In case the pointer is NULL or checkvalidpointer() returns false for the pointer, only print the pointer value and skip accessing metadata.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: brnetfilter: do not check confirmed bit in brnflocalin() after confirm
When send a broadcast packet to a tap device, which was added to a bridge, brnflocalin() is called to confirm the conntrack. If another conntrack with the same hash value is added to the hash table, which can be triggered by a normal packet to a non-bridge device, the below warning may happen.
------------[ cut here ]------------ WARNING: CPU: 1 PID: 96 at net/bridge/brnetfilterhooks.c:632 brnflocalin+0x168/0x200 CPU: 1 UID: 0 PID: 96 Comm: tapsend Not tainted 6.17.0-rc2-dirty #44 PREEMPT(voluntary) RIP: 0010:brnflocalin+0x168/0x200 Call Trace: <TASK> nfhookslow+0x3e/0xf0 brpassframeup+0x103/0x180 brhandleframefinish+0x2de/0x5b0 brnfhookthresh+0xc0/0x120 brnfpreroutingfinish+0x168/0x3a0 brnfprerouting+0x237/0x5e0 brhandleframe+0x1ec/0x3c0 netifreceiveskbcore+0x225/0x1210 netifreceiveskbonecore+0x37/0xa0 netifreceiveskb+0x36/0x160 tungetuser+0xa54/0x10c0 tunchrwriteiter+0x65/0xb0 vfswrite+0x305/0x410 ksyswrite+0x60/0xd0 dosyscall64+0xa4/0x260 entrySYSCALL64afterhwframe+0x77/0x7f </TASK> ---[ end trace 0000000000000000 ]---
To solve the hash conflict, nfctresolveclash() try to merge the conntracks, and update skb->nfct. However, brnflocalin() still use the old ct from local variable 'nfct' after confirm(), which leads to this warning.
If confirm() does not insert the conntrack entry and return NFDROP, the warning may also occur. There is no need to reserve the WARNONONCE, just remove it.
btrfs: do not allow relocation of partially dropped subvolumes
In the Linux kernel, the following vulnerability has been resolved:
mm/debugvmpgtable: clear page table entries at destroyargs()
The mm/debugvmpagetable test allocates manually page table entries for the tests it runs, using also its manually allocated mmstruct. That in itself is ok, but when it exits, at destroyargs() it fails to clear those entries with the clear functions.
The problem is that leaves stale entries. If another process allocates an mmstruct with a pgd at the same address, it may end up running into the stale entry. This is happening in practice on a debug kernel with CONFIGDEBUGVMPGTABLE=y, for example this is the output with some extra debugging I added (it prints a warning trace if pgtablesbytes goes negative, in addition to the warning at checkmm() function):
[ 2.539353] debugvmpgtable: [getrandomvaddr ]: randomvaddr is 0x7ea247140000 [ 2.539366] kmemcache info [ 2.539374] kmemcachep 0x000000002ce82385 - freelist 0x0000000000000000 - offset 0x508 [ 2.539447] debugvmpgtable: [initargs ]: args->mm is 0x000000002267cc9e (...) [ 2.552800] WARNING: CPU: 5 PID: 116 at include/linux/mm.h:2841 freepudrange+0x8bc/0x8d0 [ 2.552816] Modules linked in: [ 2.552843] CPU: 5 UID: 0 PID: 116 Comm: modprobe Not tainted 6.12.0-105.debugvm2.el10.ppc64le+debug #1 VOLUNTARY [ 2.552859] Hardware name: IBM,9009-41A POWER9 (architected) 0x4e0202 0xf000005 of:IBM,FW910.00 (VL910062) hv:phyp pSeries [ 2.552872] NIP: c0000000007eef3c LR: c0000000007eef30 CTR: c0000000003d8c90 [ 2.552885] REGS: c0000000622e73b0 TRAP: 0700 Not tainted (6.12.0-105.debugvm2.el10.ppc64le+debug) [ 2.552899] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 24002822 XER: 0000000a [ 2.552954] CFAR: c0000000008f03f0 IRQMASK: 0 [ 2.552954] GPR00: c0000000007eef30 c0000000622e7650 c000000002b1ac00 0000000000000001 [ 2.552954] GPR04: 0000000000000008 0000000000000000 c0000000007eef30 ffffffffffffffff [ 2.552954] GPR08: 00000000ffff00f5 0000000000000001 0000000000000048 0000000000004000 [ 2.552954] GPR12: 00000003fa440000 c000000017ffa300 c0000000051d9f80 ffffffffffffffdb [ 2.552954] GPR16: 0000000000000000 0000000000000008 000000000000000a 60000000000000e0 [ 2.552954] GPR20: 4080000000000000 c0000000113af038 00007fffcf130000 0000700000000000 [ 2.552954] GPR24: c000000062a6a000 0000000000000001 8000000062a68000 0000000000000001 [ 2.552954] GPR28: 000000000000000a c000000062ebc600 0000000000002000 c000000062ebc760 [ 2.553170] NIP [c0000000007eef3c] freepudrange+0x8bc/0x8d0 [ 2.553185] LR [c0000000007eef30] freepudrange+0x8b0/0x8d0 [ 2.553199] Call Trace: [ 2.553207] [c0000000622e7650] [c0000000007eef30] freepudrange+0x8b0/0x8d0 (unreliable) [ 2.553229] [c0000000622e7750] [c0000000007f40b4] freepgdrange+0x284/0x3b0 [ 2.553248] [c0000000622e7800] [c0000000007f4630] freepgtables+0x450/0x570 [ 2.553274] [c0000000622e78e0] [c0000000008161c0] exitmmap+0x250/0x650 [ 2.553292] [c0000000622e7a30] [c0000000001b95b8] mmput+0x98/0x290 [ 2.558344] [c0000000622e7a80] [c0000000001d1018] exitmm+0x118/0x1b0 [ 2.558361] [c0000000622e7ac0] [c0000000001d141c] doexit+0x2ec/0x870 [ 2.558376] [c0000000622e7b60] [c0000000001d1ca8] dogroupexit+0x88/0x150 [ 2.558391] [c0000000622e7bb0] [c0000000001d1db8] sysexitgroup+0x48/0x50 [ 2.558407] [c0000000622e7be0] [c00000000003d810] systemcallexception+0x1e0/0x4c0 [ 2.558423] [c0000000622e7e50] [c00000000000d05c] systemcallvectoredcommon+0x15c/0x2ec (...) [ 2.558892] ---[ end trace 0000000000000000 ]--- [ 2.559022] BUG: Bad rss-counter state mm:000000002267cc9e type:MMANONPAGES val:1 [ 2.559037] BUG: non-zero pgtablesbytes on freeing mm: -6144
Here the modprobe process ended up with an allocated mmstruct from the mmstruct slab that was used before by the debugvmpgtable test. That is not a problem, since the mmstru ---truncated---
bus: mhi: host: Detect events pointing to unexpected TREs
In the Linux kernel, the following vulnerability has been resolved:
net, hsr: reject HSR frame if skb can't hold tag
Receiving HSR frame with insufficient space to hold HSR tag in the skb can result in a crash (kernel BUG):
[ 45.390915] skbuff: skbunderpanic: text:ffffffff86f32cac len:26 put:14 head:ffff888042418000 data:ffff888042417ff4 tail:0xe end:0x180 dev:bridgeslave1 [ 45.392559] ------------[ cut here ]------------ [ 45.392912] kernel BUG at net/core/skbuff.c:211! [ 45.393276] Oops: invalid opcode: 0000 [#1] SMP DEBUGPAGEALLOC KASAN NOPTI [ 45.393809] CPU: 1 UID: 0 PID: 2496 Comm: reproducer Not tainted 6.15.0 #12 PREEMPT(undef) [ 45.394433] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 [ 45.395273] RIP: 0010:skbpanic+0x15b/0x1d0
<snip registers, remove unreliable trace>
[ 45.402911] Call Trace: [ 45.403105] <IRQ> [ 45.404470] skbpush+0xcd/0xf0 [ 45.404726] brdevqueuepushxmit+0x7c/0x6c0 [ 45.406513] brforwardfinish+0x128/0x260 [ 45.408483] brforward+0x42d/0x590 [ 45.409464] maybedeliver+0x2eb/0x420 [ 45.409763] brflood+0x174/0x4a0 [ 45.410030] brhandleframefinish+0xc7c/0x1bc0 [ 45.411618] brhandleframe+0xac3/0x1230 [ 45.413674] netifreceiveskbcore.constprop.0+0x808/0x3df0 [ 45.422966] netifreceiveskbonecore+0xb4/0x1f0 [ 45.424478] netifreceiveskb+0x22/0x170 [ 45.424806] processbacklog+0x242/0x6d0 [ 45.425116] napipoll+0xbb/0x630 [ 45.425394] netrxaction+0x4d1/0xcc0 [ 45.427613] handlesoftirqs+0x1a4/0x580 [ 45.427926] dosoftirq+0x74/0x90 [ 45.428196] </IRQ>
This issue was found by syzkaller.
The panic happens in brdevqueuepushxmit() once it receives a corrupted skb with ETH header already pushed in linear data. When it attempts the skbpush() call, there's not enough headroom and skbpush() panics.
The corrupted skb is put on the queue by HSR layer, which makes a sequence of unintended transformations when it receives a specific corrupted HSR frame (with incomplete TAG).
Fix it by dropping and consuming frames that are not long enough to contain both ethernet and hsr headers.
Alternative fix would be to check for enough headroom before skbpush() in brdevqueuepushxmit().
In the reproducer, this is injected via AFPACKET, but I don't easily see why it couldn't be sent over the wire from adjacent network.
Further Details:
In the reproducer, the following network interface chain is set up:
┌────────────────┐ ┌────────────────┐ │ veth0tohsr ├───┤ hsrslave0 ┼───┐ └────────────────┘ └────────────────┘ │ │ ┌──────┐ ├─┤ hsr0 ├───┐ │ └──────┘ │ ┌────────────────┐ ┌────────────────┐ │ │┌────────┐ │ veth1tohsr ┼───┤ hsrslave1 ├───┘ └┤ │ └────────────────┘ └────────────────┘ ┌┼ bridge │ ││ │ │└────────┘ │ ┌───────┐ │ │ ... ├──────┘ └───────┘
To trigger the events leading up to crash, reproducer sends a corrupted HSR fr ---truncated---
fs/buffer: fix use-after-free when call bhread() helper
In the Linux kernel, the following vulnerability has been resolved:
tracing: Limit access to parser->buffer when tracegetuser failed
When the length of the string written to setftracefilter exceeds FTRACEBUFFMAX, the following KASAN alarm will be triggered:
BUG: KASAN: slab-out-of-bounds in strsep+0x18c/0x1b0 Read of size 1 at addr ffff0000d00bd5ba by task ash/165
CPU: 1 UID: 0 PID: 165 Comm: ash Not tainted 6.16.0-g6bcdbd62bd56-dirty Hardware name: linux,dummy-virt (DT) Call trace: showstack+0x34/0x50 (C) dumpstacklvl+0xa0/0x158 printaddressdescription.constprop.0+0x88/0x398 printreport+0xb0/0x280 kasanreport+0xa4/0xf0 asanreportload1noabort+0x20/0x30 strsep+0x18c/0x1b0 ftraceprocessregex.isra.0+0x100/0x2d8 ftraceregexrelease+0x484/0x618 fput+0x364/0xa58 fput+0x28/0x40 taskworkrun+0x154/0x278 donotifyresume+0x1f0/0x220 el0svc+0xec/0xf0 el0t64synchandler+0xa0/0xe8 el0t64sync+0x1ac/0x1b0
The reason is that tracegetuser will fail when processing a string longer than FTRACEBUFFMAX, but not set the end of parser->buffer to 0. Then an OOB access will be triggered in ftraceregexrelease-> ftraceprocessregex->strsep->strpbrk. We can solve this problem by limiting access to parser->buffer when tracegetuser failed.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: Fix MAC comparison to be constant-time
To prevent timing attacks, MACs need to be compared in constant time. Use the appropriate helper function for this.
ftrace: Also allocate and copy hash for reading of filter files
In the Linux kernel, the following vulnerability has been resolved:
vsock/virtio: Validate length in packet header before skbput()
When receiving a vsock packet in the guest, only the virtqueue buffer size is validated prior to virtiovsockskbrxput(). Unfortunately, virtiovsockskbrxput() uses the length from the packet header as the length argument to skbput(), potentially resulting in SKB overflow if the host has gone wonky.
Validate the length as advertised by the packet header before calling virtiovsockskbrxput().
In the Linux kernel, the following vulnerability has been resolved:
ppp: fix race conditions in pppfillforwardpath
pppfillforwardpath() has two race conditions:
1. The ppp->channels list can change between listempty() and listfirstentry(), as ppplock() is not held. If the only channel is deleted in pppdisconnectchannel(), listfirstentry() may access an empty head or a freed entry, and trigger a panic.
2. pch->chan can be NULL. When pppunregisterchannel() is called, pch->chan is set to NULL before pch is removed from ppp->channels.
Fix these by using a lockless RCU approach: - Use listfirstornullrcu() to safely test and access the first list entry. - Convert list modifications on ppp->channels to their RCU variants and add synchronizenet() after removal. - Check for a NULL pch->chan before dereferencing it.
In the Linux kernel, the following vulnerability has been resolved:
smb3: fix for slab out of bounds on mount to ksmbd
With KASAN enabled, it is possible to get a slab out of bounds during mount to ksmbd due to missing check in parseserverinterfaces() (see below):
BUG: KASAN: slab-out-of-bounds in parseserverinterfaces+0x14ee/0x1880 [cifs] Read of size 4 at addr ffff8881433dba98 by task mount/9827
CPU: 5 UID: 0 PID: 9827 Comm: mount Tainted: G OE 6.16.0-rc2-kasan #2 PREEMPT(voluntary) Tainted: [O]=OOTMODULE, [E]=UNSIGNEDMODULE Hardware name: Dell Inc. Precision Tower 3620/0MWYPT, BIOS 2.13.1 06/14/2019 Call Trace: <TASK> dumpstacklvl+0x9f/0xf0 printreport+0xd1/0x670 virtaddrvalid+0x22c/0x430 ? parseserverinterfaces+0x14ee/0x1880 [cifs] ? kasancompletemodereportinfo+0x2a/0x1f0 ? parseserverinterfaces+0x14ee/0x1880 [cifs] kasanreport+0xd6/0x110 parseserverinterfaces+0x14ee/0x1880 [cifs] asanreportloadnnoabort+0x13/0x20 parseserverinterfaces+0x14ee/0x1880 [cifs] ? pfxparseserverinterfaces+0x10/0x10 [cifs] ? tracehardirqson+0x51/0x60 SMB3requestinterfaces+0x1ad/0x3f0 [cifs] ? pfxSMB3requestinterfaces+0x10/0x10 [cifs] ? SMB2tcon+0x23c/0x15d0 [cifs] smb3qfstcon+0x173/0x2b0 [cifs] ? pfxsmb3qfstcon+0x10/0x10 [cifs] ? cifsgettcon+0x105d/0x2120 [cifs] ? dorawspinunlock+0x5d/0x200 ? cifsgettcon+0x105d/0x2120 [cifs] ? pfxsmb3qfstcon+0x10/0x10 [cifs] cifsmountgettcon+0x369/0xb90 [cifs] ? dfscachefind+0xe7/0x150 [cifs] dfsmountshare+0x985/0x2970 [cifs] ? checkpath.constprop.0+0x28/0x50 ? savetrace+0x54/0x370 ? pfxdfsmountshare+0x10/0x10 [cifs] ? lockacquire+0xb82/0x2ba0 ? kasancheckwrite+0x18/0x20 cifsmount+0xbc/0x9e0 [cifs] ? pfxcifsmount+0x10/0x10 [cifs] ? dorawspinunlock+0x5d/0x200 ? cifssetupcifssb+0x29d/0x810 [cifs] cifssmb3domount+0x263/0x1990 [cifs]
In the Linux kernel, the following vulnerability has been resolved:
gve: prevent ethtool ops after shutdown
A crash can occur if an ethtool operation is invoked after shutdown() is called.
shutdown() is invoked during system shutdown to stop DMA operations without performing expensive deallocations. It is discouraged to unregister the netdev in this path, so the device may still be visible to userspace and kernel helpers.
In gve, shutdown() tears down most internal data structures. If an ethtool operation is dispatched after shutdown(), it will dereference freed or NULL pointers, leading to a kernel panic. While graceful shutdown normally quiesces userspace before invoking the reboot syscall, forced shutdowns (as observed on GCP VMs) can still trigger this path.
Fix by calling netifdevicedetach() in shutdown(). This marks the device as detached so the ethtool ioctl handler will skip dispatching operations to the driver.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: xtnfacct: don't assume acct name is null-terminated
BUG: KASAN: slab-out-of-bounds in .. lib/vsprintf.c:721 Read of size 1 at addr ffff88801eac95c8 by task syz-executor183/5851 [..] string+0x231/0x2b0 lib/vsprintf.c:721 vsnprintf+0x739/0xf00 lib/vsprintf.c:2874 [..] nfacctmtcheckentry+0xd2/0xe0 net/netfilter/xtnfacct.c:41 xtcheckmatch+0x3d1/0xab0 net/netfilter/xtables.c:523
nfnlacctfindget() handles non-null input, but the error printk relied on its presence.
In the Linux kernel, the following vulnerability has been resolved:
proc: use the same treatment to check proclseek as ones for procreaditer et.al
Check pde->procops->proclseek directly may cause UAF in rmmod scenario. It's a gap in procregopen() after commit 654b33ada4ab("proc: fix UAF in procgetinode()"). Followed by AI Viro's suggestion, fix it in same manner.
In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: clear initialized flag for deinit-ed srng lists
In a number of cases we see kernel panics on resume due to ath11k kernel page fault, which happens under the following circumstances:
1) First ath11khaldumpsrngstats() call
Last interrupt received for each group: ath11kpci 0000:01:00.0: groupid 0 22511ms before ath11kpci 0000:01:00.0: groupid 1 14440788ms before [..] ath11kpci 0000:01:00.0: failed to receive control response completion, polling.. ath11kpci 0000:01:00.0: Service connect timeout ath11kpci 0000:01:00.0: failed to connect to HTT: -110 ath11kpci 0000:01:00.0: failed to start core: -110 ath11kpci 0000:01:00.0: firmware crashed: MHICBEERDDM ath11kpci 0000:01:00.0: already resetting count 2 ath11kpci 0000:01:00.0: failed to wait wlan mode request (mode 4): -110 ath11kpci 0000:01:00.0: qmi failed to send wlan mode off: -110 ath11kpci 0000:01:00.0: failed to reconfigure driver on crash recovery [..]
2) At this point reconfiguration fails (we have 2 resets) and ath11kcorereconfigureoncrash() calls ath11khalsrngdeinit() which destroys srng lists. However, it does not reset per-list ->initialized flag.
3) Second ath11khaldumpsrngstats() call sees stale ->initialized flag and attempts to dump srng stats:
Last interrupt received for each group: ath11kpci 0000:01:00.0: groupid 0 66785ms before ath11kpci 0000:01:00.0: groupid 1 14485062ms before ath11kpci 0000:01:00.0: groupid 2 14485062ms before ath11kpci 0000:01:00.0: groupid 3 14485062ms before ath11kpci 0000:01:00.0: groupid 4 14780845ms before ath11kpci 0000:01:00.0: groupid 5 14780845ms before ath11kpci 0000:01:00.0: groupid 6 14485062ms before ath11kpci 0000:01:00.0: groupid 7 66814ms before ath11kpci 0000:01:00.0: groupid 8 68997ms before ath11kpci 0000:01:00.0: groupid 9 67588ms before ath11kpci 0000:01:00.0: groupid 10 69511ms before BUG: unable to handle page fault for address: ffffa007404eb010 #PF: supervisor read access in kernel mode #PF: errorcode(0x0000) - not-present page PGD 100000067 P4D 100000067 PUD 10022d067 PMD 100b01067 PTE 0 Oops: 0000 [#1] PREEMPT SMP NOPTI RIP: 0010:ath11khaldumpsrngstats+0x2b4/0x3b0 [ath11k] Call Trace: <TASK> ? diebody+0xae/0xb0 ? pagefaultoops+0x381/0x3e0 ? excpagefault+0x69/0xa0 ? asmexcpagefault+0x22/0x30 ? ath11khaldumpsrngstats+0x2b4/0x3b0 [ath11k (HASH:6cea 4)] ath11kqmidrivereventwork+0xbd/0x1050 [ath11k (HASH:6cea 4)] workerthread+0x389/0x930 kthread+0x149/0x170
Clear per-list ->initialized flag in ath11khalsrngdeinit().
eventpoll: Fix semi-unbounded recursion
bpf, ktls: Fix data corruption when using bpfmsgpopdata() in ktls
In the Linux kernel, the following vulnerability has been resolved:
net/packet: fix a race in packetsetring() and packetnotifier()
When packetsetring() releases po->bindlock, another thread can run packetnotifier() and process an NETDEVUP event.
This race and the fix are both similar to that of commit 15fe076edea7 ("net/packet: fix a race in packetbind() and packetnotifier()").
There too the packetnotifier NETDEVUP event managed to run while a po->bindlock critical section had to be temporarily released. And the fix was similarly to temporarily set po->num to zero to keep the socket unhooked until the lock is retaken.
The po->bindlock in packetsetring and packetnotifier precede the introduction of git history.
In the Linux kernel, the following vulnerability has been resolved:
pptp: ensure minimal skb length in pptpxmit()
Commit aabc6596ffb3 ("net: ppp: Add bound checking for skb data on pppsynctxmung") fixed pppsynctxmunge()
We need a similar fix in pptpxmit(), otherwise we might read uninit data as reported by syzbot.
BUG: KMSAN: uninit-value in pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pptpxmit+0xc34/0x2720 drivers/net/ppp/pptp.c:193 pppchannelbridgeinput drivers/net/ppp/pppgeneric.c:2290 [inline] pppinput+0x1d6/0xe60 drivers/net/ppp/pppgeneric.c:2314 pppoercvcore+0x1e8/0x760 drivers/net/ppp/pppoe.c:379 skbacklogrcv+0x142/0x420 include/net/sock.h:1148 releasesock+0x1d3/0x330 net/core/sock.c:3213 releasesock+0x6b/0x270 net/core/sock.c:3767 pppoesendmsg+0x15d/0xcb0 drivers/net/ppp/pppoe.c:904 socksendmsgnosec net/socket.c:712 [inline] socksendmsg+0x330/0x3d0 net/socket.c:727 syssendmsg+0x893/0xd80 net/socket.c:2566 syssendmsg+0x271/0x3b0 net/socket.c:2620 syssendmmsg+0x2d9/0x7c0 net/socket.c:2709
In the Linux kernel, the following vulnerability has been resolved:
tracing: Add downwrite(traceeventsem) when adding trace event
When a module is loaded, it adds trace events defined by the module. It may also need to modify the modules trace printk formats to replace enum names with their values.
If two modules are loaded at the same time, the adding of the event to the ftraceevents list can corrupt the walking of the list in the code that is modifying the printk format strings and crash the kernel.
The addition of the event should take the traceeventsem for write while it adds the new event.
Also add a lockdepassertheld() on that semaphore in traceaddeventdirs() as it iterates the list.
In the Linux kernel, the following vulnerability has been resolved:
mptcp: plug races between subflow fail and subflow creation
We have races similar to the one addressed by the previous patch between subflow failing and additional subflow creation. They are just harder to trigger.
The solution is similar. Use a separate flag to track the condition 'socket state prevent any additional subflow creation' protected by the fallback lock.
The socket fallback makes such flag true, and also receiving or sending an MPFAIL option.
The field 'allowinfinitefallback' is now always touched under the relevant lock, we can drop the ONCE annotation on write.