By manipulating the text in an <input> tag, an attacker could have caused corrupt memory leading to a potentially exploitable crash. This vulnerability affects Firefox < 127, Firefox ESR < 115.12, and Thunderbird < 115.12.
Android contains an unspecified vulnerability in the kernel that allows for remote code execution. This vulnerability resides in Linux Kernel and could impact other products, including but not limited to Android OS.
An out-of-bounds read in the 'bson' module of PyMongo 4.6.2 or earlier allows deserialization of malformed BSON provided by a Server to raise an exception which may contain arbitrary application memory.
In the Linux kernel, the following vulnerability has been resolved:
fs/9p: only translate RWX permissions for plain 9P2000
Garbage in plain 9P2000's perm bits is allowed through, which causes it to be able to set (among others) the suid bit. This was presumably not the intent since the unix extended bits are handled explicitly and conditionally on .u.
In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drmevent to the size of the structure that's actually used.
The length of the drmevent was set to the parent structure instead of to the drmvmweventfence which is supposed to be read. drmread uses the length parameter to copy the event to the user space thus resuling in oob reads.
In the Linux kernel, the following vulnerability has been resolved:
i40e: fix vf may be used uninitialized in this function warning
The Linux kernel CVE team has assigned CVE-2024-36020 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024053044-CVE-2024-36020-5da7@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
net: fix out-of-bounds access in opsinit
netallocgeneric is called by netalloc, which is called without any locking. It reads maxgenptrs, which is changed under pernetopsrwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access.
It is possible that the array is allocated and another thread is registering a new pernet ops, increments maxgenptrs, which is then used to set s.len with a larger than allocated length for the variable array.
Fix it by reading maxgenptrs only once in netallocgeneric. If maxgenptrs is later incremented, it will be caught in netassigngeneric.
In the Linux kernel, the following vulnerability has been resolved:
tcp: Use refcountincnotzero() in tcptwskunique().
Anderson Nascimento reported a use-after-free splat in tcptwskunique() with nice analysis.
Since commit ec94c2696f0b ("tcp/dccp: avoid one atomic operation for timewait hashdance"), inettwskhashdance() sets TIME-WAIT socket's skrefcnt after putting it into ehash and releasing the bucket lock.
Thus, there is a small race window where other threads could try to reuse the port during connect() and call sockhold() in tcptwskunique() for the TIME-WAIT socket with zero refcnt.
If that happens, the refcnt taken by tcptwskunique() is overwritten and sockput() will cause underflow, triggering a real use-after-free somewhere else.
To avoid the use-after-free, we need to use refcountincnotzero() in tcptwskunique() and give up on reusing the port if it returns false.
[0]: refcountt: addition on 0; use-after-free. WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcountwarnsaturate+0xe5/0x110 CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x8664 #1 Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023 RIP: 0010:refcountwarnsaturate+0xe5/0x110 Code: 42 8e ff 0f 0b c3 cc cc cc cc 80 3d aa 13 ea 01 00 0f 85 5e ff ff ff 48 c7 c7 f8 8e b7 82 c6 05 96 13 ea 01 01 e8 7b 42 8e ff <0f> 0b c3 cc cc cc cc 48 c7 c7 50 8f b7 82 c6 05 7a 13 ea 01 01 e8 RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282 RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027 RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0 RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0 R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84 R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0 FS: 00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0 PKRU: 55555554 Call Trace: <TASK> ? refcountwarnsaturate+0xe5/0x110 ? warn+0x81/0x130 ? refcountwarnsaturate+0xe5/0x110 ? reportbug+0x171/0x1a0 ? refcountwarnsaturate+0xe5/0x110 ? handlebug+0x3c/0x80 ? excinvalidop+0x17/0x70 ? asmexcinvalidop+0x1a/0x20 ? refcountwarnsaturate+0xe5/0x110 tcptwskunique+0x186/0x190 inetcheckestablished+0x176/0x2d0 inethashconnect+0x74/0x7d0 ? pfxinetcheckestablished+0x10/0x10 tcpv4connect+0x278/0x530 inetstreamconnect+0x10f/0x3d0 inetstreamconnect+0x3a/0x60 sysconnect+0xa8/0xd0 x64sysconnect+0x18/0x20 dosyscall64+0x83/0x170 entrySYSCALL64afterhwframe+0x78/0x80 RIP: 0033:0x7f62c11a885d Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a3 45 0c 00 f7 d8 64 89 01 48 RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIGRAX: 000000000000002a RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003 RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0 R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 </TASK>
In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: avoid out of bounds shift
UBSAN catches undefined behavior in blk-iocost, where sometimes iocg->delay is shifted right by a number that is too large, resulting in undefined behavior on some architectures.
[ 186.556576] ------------[ cut here ]------------ UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23 shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long') CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S E N 6.9.0-0fbk700debugrc2kbuilder0gc85af715cac0 #1 Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F093A23 12/08/2020 Call Trace: <IRQ> dumpstacklvl+0x8f/0xe0 ubsanhandleshiftoutofbounds+0x22c/0x280 iocgkickdelay+0x30b/0x310 ioctimerfn+0x2fb/0x1f80 runtimerbase+0x1b6/0x250 ...
Avoid that undefined behavior by simply taking the "delay = 0" branch if the shift is too large.
I am not sure what the symptoms of an undefined value delay will be, but I suspect it could be more than a little annoying to debug.
In the Linux kernel, the following vulnerability has been resolved:
nsh: Restore skb->{protocol,data,macheader} for outer header in nshgsosegment().
syzbot triggered various splats (see [0] and links) by a crafted GSO packet of VIRTIONETHDRGSOUDP layering the following protocols:
ETHP8021AD + ETHPNSH + ETHPIPV6 + IPPROTOUDP
NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS. As the inner protocol can be Ethernet, NSH GSO handler, nshgsosegment(), calls skbmacgsosegment() to invoke inner protocol GSO handlers.
nshgsosegment() does the following for the original skb before calling skbmacgsosegment()
1. reset skb->networkheader 2. save the original skb->{macheaeder,maclen} in a local variable 3. pull the NSH header 4. resets skb->macheader 5. set up skb->maclen and skb->protocol for the inner protocol.
and does the following for the segmented skb
6. set ntohs(ETHPNSH) to skb->protocol 7. push the NSH header 8. restore skb->macheader 9. set skb->macheader + maclen to skb->networkheader 10. restore skb->maclen
There are two problems in 6-7 and 8-9.
(a) After 6 & 7, skb->data points to the NSH header, so the outer header (ETHP8021AD in this case) is stripped when skb is sent out of netdev.
Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH), skbpull() in the first nshgsosegment() will make skb->data point to the middle of the outer NSH or Ethernet header because the Ethernet header is not pulled by the second nshgsosegment().
(b) While restoring skb->{macheader,networkheader} in 8 & 9, nshgsosegment() does not assume that the data in the linear buffer is shifted.
However, udp6ufofragment() could shift the data and change skb->macheader accordingly as demonstrated by syzbot.
If this happens, even the restored skb->macheader points to the middle of the outer header.
It seems nshgsosegment() has never worked with outer headers so far.
At the end of nshgsosegment(), the outer header must be restored for the segmented skb, instead of the NSH header.
To do that, let's calculate the outer header position relatively from the inner header and set skb->{data,macheader,protocol} properly.
[0]: BUG: KMSAN: uninit-value in ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:524 [inline] BUG: KMSAN: uninit-value in ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] BUG: KMSAN: uninit-value in ipvlanqueuexmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlancore.c:668 ipvlanprocessoutbound drivers/net/ipvlan/ipvlancore.c:524 [inline] ipvlanxmitmodel3 drivers/net/ipvlan/ipvlancore.c:602 [inline] ipvlanqueuexmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlancore.c:668 ipvlanstartxmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlanmain.c:222 netdevstartxmit include/linux/netdevice.h:4989 [inline] netdevstartxmit include/linux/netdevice.h:5003 [inline] xmitone net/core/dev.c:3547 [inline] devhardstartxmit+0x244/0xa10 net/core/dev.c:3563 devqueuexmit+0x33ed/0x51c0 net/core/dev.c:4351 devqueuexmit include/linux/netdevice.h:3171 [inline] packetxmit+0x9c/0x6b0 net/packet/afpacket.c:276 packetsnd net/packet/afpacket.c:3081 [inline] packetsendmsg+0x8aef/0x9f10 net/packet/afpacket.c:3113 socksendmsgnosec net/socket.c:730 [inline] socksendmsg net/socket.c:745 [inline] syssendto+0x735/0xa10 net/socket.c:2191 dosyssendto net/socket.c:2203 [inline] sesyssendto net/socket.c:2199 [inline] x64syssendto+0x125/0x1c0 net/socket.c:2199 dosyscallx64 arch/x86/entry/common.c:52 [inline] dosyscall64+0xcf/0x1e0 arch/x86/entry/common.c:83 entrySYSCALL64afterhwframe+0x63/0x6b
Uninit was created at: slabpostallochook mm/slub.c:3819 [inline] slaballocnode mm/slub.c:3860 [inline] dokmallocnode mm/slub.c:3980 [inline] kmallocnodetrackcaller+0x705/0x1000 mm/slub.c:4001 kmallocreserve+0x249/0x4a0 net/core/skbuff.c:582 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
pinctrl: core: delete incorrect free in pinctrlenable()
The "pctldev" struct is allocated in devmpinctrlregisterandinit(). It's a devm managed pointer that is freed by devmpinctrldevrelease(), so freeing it in pinctrlenable() will lead to a double free.
The devmpinctrldevrelease() function frees the pindescs and destroys the mutex as well.
In the Linux kernel, the following vulnerability has been resolved:
net: core: reject skbcopy(expand) for fraglist GSO skbs
SKBGSOFRAGLIST skbs must not be linearized, otherwise they become invalid. Return NULL if such an skb is passed to skbcopy or skbcopyexpand, in order to prevent a crash on a potential later call to skbgsosegment.
In the Linux kernel, the following vulnerability has been resolved:
bna: ensure the copied buf is NUL terminated
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes from userspace to that buffer. Later, we use sscanf on this buffer but we don't ensure that the string is terminated inside the buffer, this can lead to OOB read when using sscanf. Fix this issue by using memdupusernul instead of memdupuser.
In the Linux kernel, the following vulnerability has been resolved:
tty: ngsm: require CAPNETADMIN to attach NGSM0710 ldisc
Any unprivileged user can attach NGSM0710 ldisc, but it requires CAPNETADMIN to create a GSM network anyway.
Require initial namespace CAPNETADMIN to do that.
GStreamer EXIF Metadata Parsing Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation. The specific flaw exists within the parsing of EXIF metadata. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current process. . Was ZDI-CAN-23896.
In the Linux kernel, the following vulnerability has been resolved:
netfilter: complete validation of user input
In my recent commit, I missed that doreplace() handlers use copyfromsockptr() (which I fixed), followed by unsafe copyfromsockptroffset() calls.
In all functions, we can perform the @optlen validation before even calling xtalloctableinfo() with the following check:
if ((u64)optlen < (u64)tmp.size + sizeof(tmp)) return -EINVAL;
In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: Fix not validating setsockopt user input
syzbot reported scosocksetsockopt() is copying data without checking user input length.
BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in scosocksetsockopt+0xc0b/0xf90 net/bluetooth/sco.c:893 Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578
In the Linux kernel, the following vulnerability has been resolved:
kprobes: Fix possible use-after-free issue on kprobe registration
When unloading a module, its state is changing MODULESTATELIVE -> MODULESTATEGOING -> MODULESTATEUNFORMED. Each change will take a time. ismoduletextaddress() and moduletextaddress() works with MODULESTATELIVE and MODULESTATEGOING. If we use ismoduletextaddress() and moduletextaddress() separately, there is a chance that the first one is succeeded but the next one is failed because module->state becomes MODULESTATEUNFORMED between those operations.
In checkkprobeaddresssafe(), if the second moduletextaddress() is failed, that is ignored because it expected a kerneltext address. But it may have failed simply because module->state has been changed to MODULESTATEUNFORMED. In this case, armkprobe() will try to modify non-exist module text address (use-after-free).
To fix this problem, we should not use separated ismoduletextaddress() and moduletextaddress(), but use only moduletextaddress() once and do trymoduleget(module) which is only available with MODULESTATELIVE.
In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fully protect modes[] with dev->modeconfig.mutex
The Linux kernel CVE team has assigned CVE-2024-35950 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024052015-CVE-2024-35950-41bf@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
net: ena: Fix incorrect descriptor free behavior
ENA has two types of TX queues: - queues which only process TX packets arriving from the network stack - queues which only process TX packets forwarded to it by XDPREDIRECT or XDPTX instructions
The enafreetxbufs() cycles through all descriptors in a TX queue and unmaps + frees every descriptor that hasn't been acknowledged yet by the device (uncompleted TX transactions). The function assumes that the processed TX queue is necessarily from the first category listed above and ends up using napiconsumeskb() for descriptors belonging to an XDP specific queue.
This patch solves a bug in which, in case of a VF reset, the descriptors aren't freed correctly, leading to crashes.
In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix race condition between ipv6getifaddr and ipv6deladdr
Although ipv6getifaddr walks inet6addrlst under the RCU lock, it still means hlistforeachentryrcu can return an item that got removed from the list. The memory itself of such item is not freed thanks to RCU but nothing guarantees the actual content of the memory is sane.
In particular, the reference count can be zero. This can happen if ipv6deladdr is called in parallel. ipv6deladdr removes the entry from inet6addrlst (hlistdelinitrcu(&ifp->addrlst)) and drops all references (in6ifaput(ifp) + in6ifaput(ifp)). With bad enough timing, this can happen:
1. In ipv6getifaddr, hlistforeachentryrcu returns an entry.
2. Then, the whole ipv6deladdr is executed for the given entry. The reference count drops to zero and kfreercu is scheduled.
3. ipv6getifaddr continues and tries to increments the reference count (in6ifahold).
4. The rcu is unlocked and the entry is freed.
5. The freed entry is returned.
Prevent increasing of the reference count in such case. The name in6ifaholdsafe is chosen to mimic the existing fib6infoholdsafe.
[ 41.506330] refcountt: addition on 0; use-after-free. [ 41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcountwarnsaturate+0xa5/0x130 [ 41.507413] Modules linked in: veth bridge stp llc [ 41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14 [ 41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) [ 41.509163] RIP: 0010:refcountwarnsaturate+0xa5/0x130 [ 41.509586] Code: ad ff 90 0f 0b 90 90 c3 cc cc cc cc 80 3d c0 30 ad 01 00 75 a0 c6 05 b7 30 ad 01 01 90 48 c7 c7 38 cc 7a 8c e8 cc 18 ad ff 90 <0f> 0b 90 90 c3 cc cc cc cc 80 3d 98 30 ad 01 00 0f 85 75 ff ff ff [ 41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282 [ 41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000 [ 41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900 [ 41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff [ 41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000 [ 41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48 [ 41.514086] FS: 00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000 [ 41.514726] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0 [ 41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 41.516799] Call Trace: [ 41.517037] <TASK> [ 41.517249] ? warn+0x7b/0x120 [ 41.517535] ? refcountwarnsaturate+0xa5/0x130 [ 41.517923] ? reportbug+0x164/0x190 [ 41.518240] ? handlebug+0x3d/0x70 [ 41.518541] ? excinvalidop+0x17/0x70 [ 41.520972] ? asmexcinvalidop+0x1a/0x20 [ 41.521325] ? refcountwarnsaturate+0xa5/0x130 [ 41.521708] ipv6getifaddr+0xda/0xe0 [ 41.522035] inet6rtmgetaddr+0x342/0x3f0 [ 41.522376] ? pfxinet6rtmgetaddr+0x10/0x10 [ 41.522758] rtnetlinkrcvmsg+0x334/0x3d0 [ 41.523102] ? netlinkunicast+0x30f/0x390 [ 41.523445] ? pfxrtnetlinkrcvmsg+0x10/0x10 [ 41.523832] netlinkrcvskb+0x53/0x100 [ 41.524157] netlinkunicast+0x23b/0x390 [ 41.524484] netlinksendmsg+0x1f2/0x440 [ 41.524826] syssendto+0x1d8/0x1f0 [ 41.525145] x64syssendto+0x1f/0x30 [ 41.525467] dosyscall64+0xa5/0x1b0 [ 41.525794] entrySYSCALL64afterhwframe+0x72/0x7a [ 41.526213] RIP: 0033:0x7fbc4cfcea9a [ 41.526528] Code: d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 41 89 ca 64 8b 04 25 18 00 00 00 85 c0 75 15 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 7e c3 0f 1f 44 00 00 41 54 48 83 ec 30 44 89 [ 41.527942] RSP: 002b:00007f ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrumacltcam: Fix warning during rehash
As previously explained, the rehash delayed work migrates filters from one region to another. This is done by iterating over all chunks (all the filters with the same priority) in the region and in each chunk iterating over all the filters.
When the work runs out of credits it stores the current chunk and entry as markers in the per-work context so that it would know where to resume the migration from the next time the work is scheduled.
Upon error, the chunk marker is reset to NULL, but without resetting the entry markers despite being relative to it. This can result in migration being resumed from an entry that does not belong to the chunk being migrated. In turn, this will eventually lead to a chunk being iterated over as if it is an entry. Because of how the two structures happen to be defined, this does not lead to KASAN splats, but to warnings such as [1].
Fix by creating a helper that resets all the markers and call it from all the places the currently only reset the chunk marker. For good measures also call it when starting a completely new rehash. Add a warning to avoid future cases.
[1] WARNING: CPU: 7 PID: 1076 at drivers/net/ethernet/mellanox/mlxsw/coreaclflexkeys.c:407 mlxswafkencode+0x242/0x2f0 Modules linked in: CPU: 7 PID: 1076 Comm: kworker/7:24 Tainted: G W 6.9.0-rc3-custom-00880-g29e61d91b77b #29 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxswcore mlxswspacltcamvregionrehashwork RIP: 0010:mlxswafkencode+0x242/0x2f0 [...] Call Trace: mlxswspaclatcamentryadd+0xd9/0x3c0 mlxswspacltcamentrycreate+0x5e/0xa0 mlxswspacltcamvchunkmigrateall+0x109/0x290 mlxswspacltcamvregionrehashwork+0x6c/0x470 processonework+0x151/0x370 workerthread+0x2cb/0x3e0 kthread+0xd0/0x100 retfromfork+0x34/0x50
In the Linux kernel, the following vulnerability has been resolved:
bpf: Protect against int overflow for stack access size
The Linux kernel CVE team has assigned CVE-2024-35905 to this issue.
Upstream advisory: https://lore.kernel.org/linux-cve-announce/2024051954-CVE-2024-35905-d079@gregkh/T
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: Fix potential data-race in nftflowtabletypeget()
nftunregisterflowtabletype() within nfflowinetmoduleexit() can concurrent with nftflowtabletypeget() within nftablesnewflowtable(). And thhere is not any protection when iterate over nftablesflowtables list in nftflowtabletypeget(). Therefore, there is pertential data-race of nftablesflowtables list entry.
Use listforeachentryrcu() to iterate over nftablesflowtables list in nftflowtabletypeget(), and use rcureadlock() in the caller nftflowtabletypeget() to protect the entire type query process.
In the Linux kernel, the following vulnerability has been resolved:
of: dynamic: Synchronize ofchangesetdestroy() with the devlink removals
In the following sequence: 1) ofplatformdepopulate() 2) ofoverlayremove()
During the step 1, devices are destroyed and devlinks are removed. During the step 2, OF nodes are destroyed but ofchangesetentrydestroy() can raise warnings related to missing ofnodeput(): ERROR: memory leak, expected refcount 1 instead of 2 ...
Indeed, during the devlink removals performed at step 1, the removal itself releasing the device (and the attached ofnode) is done by a job queued in a workqueue and so, it is done asynchronously with respect to function calls. When the warning is present, ofnodeput() will be called but wrongly too late from the workqueue job.
In order to be sure that any ongoing devlink removals are done before the ofnode destruction, synchronize the ofchangesetdestroy() with the devlink removals.
In the Linux kernel, the following vulnerability has been resolved:
erspan: make sure erspanbasehdr is present in skb->head
syzbot reported a problem in ip6erspanrcv() [1]
Issue is that ip6erspanrcv() (and erspanrcv()) no longer make sure erspanbasehdr is present in skb linear part (skb->head) before getting @ver field from it.
Add the missing pskbmaypull() calls.
v2: Reload iph pointer in erspanrcv() after pskbmaypull() because skb->head might have changed.
[1]
BUG: KMSAN: uninit-value in pskbmaypullreason include/linux/skbuff.h:2742 [inline] BUG: KMSAN: uninit-value in pskbmaypull include/linux/skbuff.h:2756 [inline] BUG: KMSAN: uninit-value in ip6erspanrcv net/ipv6/ip6gre.c:541 [inline] BUG: KMSAN: uninit-value in grercv+0x11f8/0x1930 net/ipv6/ip6gre.c:610 pskbmaypullreason include/linux/skbuff.h:2742 [inline] pskbmaypull include/linux/skbuff.h:2756 [inline] ip6erspanrcv net/ipv6/ip6gre.c:541 [inline] grercv+0x11f8/0x1930 net/ipv6/ip6gre.c:610 ip6protocoldeliverrcu+0x1d4c/0x2ca0 net/ipv6/ip6input.c:438 ip6inputfinish net/ipv6/ip6input.c:483 [inline] NFHOOK include/linux/netfilter.h:314 [inline] ip6input+0x15d/0x430 net/ipv6/ip6input.c:492 ip6mcinput+0xa7e/0xc80 net/ipv6/ip6input.c:586 dstinput include/net/dst.h:460 [inline] ip6rcvfinish+0x955/0x970 net/ipv6/ip6input.c:79 NFHOOK include/linux/netfilter.h:314 [inline] ipv6rcv+0xde/0x390 net/ipv6/ip6input.c:310 netifreceiveskbonecore net/core/dev.c:5538 [inline] netifreceiveskb+0x1da/0xa00 net/core/dev.c:5652 netifreceiveskbinternal net/core/dev.c:5738 [inline] netifreceiveskb+0x58/0x660 net/core/dev.c:5798 tunrxbatched+0x3ee/0x980 drivers/net/tun.c:1549 tungetuser+0x5566/0x69e0 drivers/net/tun.c:2002 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2108 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xb63/0x1520 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x93/0xe0 fs/readwrite.c:652 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75
Uninit was created at: slabpostallochook mm/slub.c:3804 [inline] slaballocnode mm/slub.c:3845 [inline] kmemcacheallocnode+0x613/0xc50 mm/slub.c:3888 kmallocreserve+0x13d/0x4a0 net/core/skbuff.c:577 allocskb+0x35b/0x7a0 net/core/skbuff.c:668 allocskb include/linux/skbuff.h:1318 [inline] allocskbwithfrags+0xc8/0xbf0 net/core/skbuff.c:6504 sockallocsendpskb+0xa81/0xbf0 net/core/sock.c:2795 tunallocskb drivers/net/tun.c:1525 [inline] tungetuser+0x209a/0x69e0 drivers/net/tun.c:1846 tunchrwriteiter+0x3af/0x5d0 drivers/net/tun.c:2048 callwriteiter include/linux/fs.h:2108 [inline] newsyncwrite fs/readwrite.c:497 [inline] vfswrite+0xb63/0x1520 fs/readwrite.c:590 ksyswrite+0x20f/0x4c0 fs/readwrite.c:643 dosyswrite fs/readwrite.c:655 [inline] sesyswrite fs/readwrite.c:652 [inline] x64syswrite+0x93/0xe0 fs/readwrite.c:652 dosyscall64+0xd5/0x1f0 entrySYSCALL64afterhwframe+0x6d/0x75
CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0
In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed by BPF after commit 20f2505fb436 ("bpf: Try to avoid kzalloc in cgroup/{s,g}etsockopt")
setsockopt() @optlen argument should be taken into account before copying data.
BUG: KASAN: slab-out-of-bounds in copyfromsockptroffset include/linux/sockptr.h:49 [inline] BUG: KASAN: slab-out-of-bounds in copyfromsockptr include/linux/sockptr.h:55 [inline] BUG: KASAN: slab-out-of-bounds in doreplace net/ipv4/netfilter/iptables.c:1111 [inline] BUG: KASAN: slab-out-of-bounds in doiptsetctl+0x902/0x3dd0 net/ipv4/netfilter/iptables.c:1627 Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 Call Trace: dumpstack lib/dumpstack.c:88 [inline] dumpstacklvl+0x241/0x360 lib/dumpstack.c:114 printaddressdescription mm/kasan/report.c:377 [inline] printreport+0x169/0x550 mm/kasan/report.c:488 kasanreport+0x143/0x180 mm/kasan/report.c:601 kasancheckrange+0x282/0x290 mm/kasan/generic.c:189 asanmemcpy+0x29/0x70 mm/kasan/shadow.c:105 copyfromsockptroffset include/linux/sockptr.h:49 [inline] copyfromsockptr include/linux/sockptr.h:55 [inline] doreplace net/ipv4/netfilter/iptables.c:1111 [inline] doiptsetctl+0x902/0x3dd0 net/ipv4/netfilter/iptables.c:1627 nfsetsockopt+0x295/0x2c0 net/netfilter/nfsockopt.c:101 dosocksetsockopt+0x3af/0x720 net/socket.c:2311 syssetsockopt+0x1ae/0x250 net/socket.c:2334 dosyssetsockopt net/socket.c:2343 [inline] sesyssetsockopt net/socket.c:2340 [inline] x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfb/0x240 entrySYSCALL64afterhwframe+0x72/0x7a RIP: 0033:0x7fd22067dde9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIGRAX: 0000000000000036 RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9 RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003 RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000 R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8
Allocated by task 7238: kasansavestack mm/kasan/common.c:47 [inline] kasansavetrack+0x3f/0x80 mm/kasan/common.c:68 poisonkmallocredzone mm/kasan/common.c:370 [inline] kasankmalloc+0x98/0xb0 mm/kasan/common.c:387 kasankmalloc include/linux/kasan.h:211 [inline] dokmallocnode mm/slub.c:4069 [inline] kmallocnoprof+0x200/0x410 mm/slub.c:4082 kmallocnoprof include/linux/slab.h:664 [inline] cgroupbpfrunfiltersetsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869 dosocksetsockopt+0x6b4/0x720 net/socket.c:2293 syssetsockopt+0x1ae/0x250 net/socket.c:2334 dosyssetsockopt net/socket.c:2343 [inline] sesyssetsockopt net/socket.c:2340 [inline] x64syssetsockopt+0xb5/0xd0 net/socket.c:2340 dosyscall64+0xfb/0x240 entrySYSCALL64afterhwframe+0x72/0x7a
The buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8 The buggy address is located 0 bytes inside of allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
The buggy address belongs to the physical page: page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73 flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff) pagetype: 0xffffefff(slab) raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122 raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00 ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: flush pending destroy work before exitnet release
Similar to 2c9f0293280e ("netfilter: nftables: flush pending destroy work before netlink notifier") to address a race between exitnet and the destroy workqueue.
The trace below shows an element to be released via destroy workqueue while exitnet path (triggered via module removal) has already released the set that is used in such transaction.
[ 1360.547789] BUG: KASAN: slab-use-after-free in nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465 [ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359 [ 1360.547882] Workqueue: events nftablestransdestroywork [nftables] [ 1360.547984] Call Trace: [ 1360.547991] <TASK> [ 1360.547998] dumpstacklvl+0x53/0x70 [ 1360.548014] printreport+0xc4/0x610 [ 1360.548026] ? virtaddrvalid+0xba/0x160 [ 1360.548040] ? pfxrawspinlockirqsave+0x10/0x10 [ 1360.548054] ? nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.548176] kasanreport+0xae/0xe0 [ 1360.548189] ? nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.548312] nftablestransdestroywork+0x3f5/0x590 [nftables] [ 1360.548447] ? pfxnftablestransdestroywork+0x10/0x10 [nftables] [ 1360.548577] ? rawspinunlockirq+0x18/0x30 [ 1360.548591] processonework+0x2f1/0x670 [ 1360.548610] workerthread+0x4d3/0x760 [ 1360.548627] ? pfxworkerthread+0x10/0x10 [ 1360.548640] kthread+0x16b/0x1b0 [ 1360.548653] ? pfxkthread+0x10/0x10 [ 1360.548665] retfromfork+0x2f/0x50 [ 1360.548679] ? pfxkthread+0x10/0x10 [ 1360.548690] retfromforkasm+0x1a/0x30 [ 1360.548707] </TASK>
[ 1360.548719] Allocated by task 192061: [ 1360.548726] kasansavestack+0x20/0x40 [ 1360.548739] kasansavetrack+0x14/0x30 [ 1360.548750] kasankmalloc+0x8f/0xa0 [ 1360.548760] kmallocnode+0x1f1/0x450 [ 1360.548771] nftablesnewset+0x10c7/0x1b50 [nftables] [ 1360.548883] nfnetlinkrcvbatch+0xbc4/0xdc0 [nfnetlink] [ 1360.548909] nfnetlinkrcv+0x1a8/0x1e0 [nfnetlink] [ 1360.548927] netlinkunicast+0x367/0x4f0 [ 1360.548935] netlinksendmsg+0x34b/0x610 [ 1360.548944] syssendmsg+0x4d4/0x510 [ 1360.548953] syssendmsg+0xc9/0x120 [ 1360.548961] syssendmsg+0xbe/0x140 [ 1360.548971] dosyscall64+0x55/0x120 [ 1360.548982] entrySYSCALL64afterhwframe+0x55/0x5d
[ 1360.548994] Freed by task 192222: [ 1360.548999] kasansavestack+0x20/0x40 [ 1360.549009] kasansavetrack+0x14/0x30 [ 1360.549019] kasansavefreeinfo+0x3b/0x60 [ 1360.549028] poisonslabobject+0x100/0x180 [ 1360.549036] kasanslabfree+0x14/0x30 [ 1360.549042] kfree+0xb6/0x260 [ 1360.549049] nftreleasetable+0x473/0x6a0 [nftables] [ 1360.549131] nftablesexitnet+0x170/0x240 [nftables] [ 1360.549221] opsexitlist+0x50/0xa0 [ 1360.549229] freeexitlist+0x101/0x140 [ 1360.549236] unregisterpernetoperations+0x107/0x160 [ 1360.549245] unregisterpernetsubsys+0x1c/0x30 [ 1360.549254] nftablesmoduleexit+0x43/0x80 [nftables] [ 1360.549345] dosysdeletemodule+0x253/0x370 [ 1360.549352] dosyscall64+0x55/0x120 [ 1360.549360] entrySYSCALL64afterhwframe+0x55/0x5d
(gdb) list nftreleasetable+0x473 0x1e033 is in nftreleasetable (net/netfilter/nftablesapi.c:11354). 11349 listforeachentrysafe(flowtable, nf, &table->flowtables, list) { 11350 listdel(&flowtable->list); 11351 nftusedec(&table->use); 11352 nftablesflowtabledestroy(flowtable); 11353 } 11354 listforeachentrysafe(set, ns, &table->sets, list) { 11355 listdel(&set->list); 11356 nftusedec(&table->use); 11357 if (set->flags & (NFTSETMAP | NFTSETOBJECT)) 11358 nftmapdeactivat ---truncated---
In the Linux kernel, the following vulnerability has been resolved:
netfilter: nftables: discard table flag update with pending basechain deletion
Hook unregistration is deferred to the commit phase, same occurs with hook updates triggered by the table dormant flag. When both commands are combined, this results in deleting a basechain while leaving its hook still registered in the core.
In the Linux kernel, the following vulnerability has been resolved:
riscv: process: Fix kernel gp leakage
childregs represents the registers which are active for the new thread in user context. For a kernel thread, childregs->gp is never used since the kernel gp is not touched by switchto. For a user mode helper, the gp value can be observed in user space after execve or possibly by other means.
[From the email thread]
The / Kernel thread / comment is somewhat inaccurate in that it is also used for usermodehelper threads, which exec a user process, e.g. /sbin/init or when /proc/sys/kernel/corepattern is a pipe. Such threads do not have PFKTHREAD set and are valid targets for ptrace etc. even before they exec.
childregs is the user context during syscall execution and it is observable from userspace in at least five ways:
1. kernelexecve does not currently clear integer registers, so the starting register state for PID 1 and other user processes started by the kernel has sp = user stack, gp = kernel globalpointer$, all other integer registers zeroed by the memset in the patch comment.
This is a bug in its own right, but I'm unwilling to bet that it is the only way to exploit the issue addressed by this patch.
2. ptrace(PTRACEGETREGSET): you can PTRACEATTACH to a usermodehelper thread before it execs, but ptrace requires SIGSTOP to be delivered which can only happen at user/kernel boundaries.
3. /proc//task//syscall: this is perfectly happy to read ptregs for usermodehelpers before the exec completes, but gp is not one of the registers it returns.
4. PERFSAMPLEREGSUSER: LOCKDOWNPERF normally prevents access to kernel addresses via PERFSAMPLEREGSINTR, but due to this bug kernel addresses are also exposed via PERFSAMPLEREGSUSER which is permitted under LOCKDOWNPERF. I have not attempted to write exploit code.
5. Much of the tracing infrastructure allows access to user registers. I have not attempted to determine which forms of tracing allow access to user registers without already allowing access to kernel registers.