CVSS: 7.8EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26589 – bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS
https://notcve.org/view.php?id=CVE-2024-26589
In the Linux kernel, the following vulnerability has been resolved: bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off for validation. However, variable offset ptr alu is not prohibited for this ptr kind. So the variable offset is not checked. The following prog is accepted: func#0 @0 0: R1=ctx() R10=fp0 0: (bf) r6 = r1 ; R1=ctx() R6_w=ctx() 1: (79) r7 = *(u64 *)(r6 +144) ; R6_w=ctx() R7_w=flow_keys() 2: (b7) r8 = 1024 ; R8_w=1024 3: (37) r8 /= 1 ; R8_w=scalar() 4: (57) r8 &= 1024 ; R8_w=scalar(smin=smin32=0, smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400)) 5: (0f) r7 += r8 mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1 mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024 mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1 mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024 6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024, var_off=(0x0; 0x400)) 6: (79) r0 = *(u64 *)(r7 +0) ; R0_w=scalar() 7: (95) exit This prog loads flow_keys to r7, and adds the variable offset r8 to r7, and finally causes out-of-bounds access: BUG: unable to handle page fault for address: ffffc90014c80038 [...] Call Trace: <TASK> bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline] __bpf_prog_run include/linux/filter.h:651 [inline] bpf_prog_run include/linux/filter.h:658 [inline] bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline] bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991 bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359 bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline] __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475 __do_sys_bpf kernel/bpf/syscall.c:5561 [inline] __se_sys_bpf kernel/bpf/syscall.c:5559 [inline] __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x63/0x6b Fix this by rejecting ptr alu with variable offset on flow_keys. Applying the patch rejects the program with "R7 pointer arithmetic on flow_keys prohibited". En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: Rechazar variable offset alu en PTR_TO_FLOW_KEYS Para PTR_TO_FLOW_KEYS, check_flow_keys_access() solo usa fijo para la validación. Sin embargo, el desplazamiento variable ptr alu no está prohibido para este tipo de ptr. • https://git.kernel.org/stable/c/d58e468b1112dcd1d5193c0a89ff9f98b5a3e8b9 https://git.kernel.org/stable/c/29ffa63f21bcdcef3e36b03cccf9d0cd031f6ab0 https://git.kernel.org/stable/c/4108b86e324da42f7ed425bd71632fd844300dc8 https://git.kernel.org/stable/c/e8d3872b617c21100c5ee4f64e513997a68c2e3d https://git.kernel.org/stable/c/1b500d5d6cecf98dd6ca88bc9e7ae1783c83e6d3 https://git.kernel.org/stable/c/22c7fa171a02d310e3a3f6ed46a698ca8a0060ed • CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer •
CVSS: 6.7EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26586 – mlxsw: spectrum_acl_tcam: Fix stack corruption
https://notcve.org/view.php?id=CVE-2024-26586
In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix stack corruption When tc filters are first added to a net device, the corresponding local port gets bound to an ACL group in the device. The group contains a list of ACLs. In turn, each ACL points to a different TCAM region where the filters are stored. During forwarding, the ACLs are sequentially evaluated until a match is found. One reason to place filters in different regions is when they are added with decreasing priorities and in an alternating order so that two consecutive filters can never fit in the same region because of their key usage. In Spectrum-2 and newer ASICs the firmware started to report that the maximum number of ACLs in a group is more than 16, but the layout of the register that configures ACL groups (PAGT) was not updated to account for that. It is therefore possible to hit stack corruption [1] in the rare case where more than 16 ACLs in a group are required. Fix by limiting the maximum ACL group size to the minimum between what the firmware reports and the maximum ACLs that fit in the PAGT register. Add a test case to make sure the machine does not crash when this condition is hit. [1] Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120 [...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b En el kernel de Linux, se resolvió la siguiente vulnerabilidad: mlxsw: espectro_acl_tcam: corrige la corrupción de la pila Cuando los filtros tc se agregan por primera vez a un dispositivo de red, el puerto local correspondiente se vincula a un grupo ACL en el dispositivo. • https://git.kernel.org/stable/c/c3ab435466d5109b2c7525a3b90107d4d9e918fc https://git.kernel.org/stable/c/56750ea5d15426b5f307554e7699e8b5f76c3182 https://git.kernel.org/stable/c/348112522a35527c5bcba933b9fefb40a4f44f15 https://git.kernel.org/stable/c/6fd24675188d354b1cad47462969afa2ab09d819 https://git.kernel.org/stable/c/2f5e1565740490706332c06f36211d4ce0f88e62 https://git.kernel.org/stable/c/a361c2c1da5dbb13ca67601cf961ab3ad68af383 https://git.kernel.org/stable/c/483ae90d8f976f8339cf81066312e1329f2d3706 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-787: Out-of-bounds Write •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2023-52443 – apparmor: avoid crash when parsed profile name is empty
https://notcve.org/view.php?id=CVE-2023-52443
In the Linux kernel, the following vulnerability has been resolved: apparmor: avoid crash when parsed profile name is empty When processing a packed profile in unpack_profile() described like "profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}" a string ":samba-dcerpcd" is unpacked as a fully-qualified name and then passed to aa_splitn_fqname(). aa_splitn_fqname() treats ":samba-dcerpcd" as only containing a namespace. Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later aa_alloc_profile() crashes as the new profile name is NULL now. general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014 RIP: 0010:strlen+0x1e/0xa0 Call Trace: <TASK> ? strlen+0x1e/0xa0 aa_policy_init+0x1bb/0x230 aa_alloc_profile+0xb1/0x480 unpack_profile+0x3bc/0x4960 aa_unpack+0x309/0x15e0 aa_replace_profiles+0x213/0x33c0 policy_update+0x261/0x370 profile_replace+0x20e/0x2a0 vfs_write+0x2af/0xe00 ksys_write+0x126/0x250 do_syscall_64+0x46/0xf0 entry_SYSCALL_64_after_hwframe+0x6e/0x76 </TASK> ---[ end trace 0000000000000000 ]--- RIP: 0010:strlen+0x1e/0xa0 It seems such behaviour of aa_splitn_fqname() is expected and checked in other places where it is called (e.g. aa_remove_profiles). Well, there is an explicit comment "a ns name without a following profile is allowed" inside. AFAICS, nothing can prevent unpacked "name" to be in form like ":samba-dcerpcd" - it is passed from userspace. Deny the whole profile set replacement in such case and inform user with EPROTO and an explaining message. Found by Linux Verification Center (linuxtesting.org). • https://git.kernel.org/stable/c/04dc715e24d0820bf8740e1a1135ed61fe162bc8 https://git.kernel.org/stable/c/9286ee97aa4803d99185768735011d0d65827c9e https://git.kernel.org/stable/c/1d8e62b5569cc1466ceb8a7e4872cf10160a9dcf https://git.kernel.org/stable/c/5ff00408e5029d3550ee77f62dc15f1e15c47f87 https://git.kernel.org/stable/c/0a12db736edbb4933e4274932aeea594b5876fa4 https://git.kernel.org/stable/c/9d4fa5fe2b1d56662afd14915a73b4d0783ffa45 https://git.kernel.org/stable/c/5c0392fdafb0a2321311900be83ffa572bef8203 https://git.kernel.org/stable/c/77ab09b92f16c8439a948d1af48919695 • CWE-476: NULL Pointer Dereference •
CVSS: 7.0EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26585 – tls: fix race between tx work scheduling and socket close
https://notcve.org/view.php?id=CVE-2024-26585
In the Linux kernel, the following vulnerability has been resolved: tls: fix race between tx work scheduling and socket close Similarly to previous commit, the submitting thread (recvmsg/sendmsg) may exit as soon as the async crypto handler calls complete(). Reorder scheduling the work before calling complete(). This seems more logical in the first place, as it's the inverse order of what the submitting thread will do. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: tls: corrige la ejecución entre la programación de trabajo de transmisión y el cierre del socket De manera similar a el commit anterior, el hilo de envío (recvmsg/sendmsg) puede cerrarse tan pronto como el controlador de cifrado asíncrono llame a complete(). Reordene la programación del trabajo antes de llamar a complete(). En primer lugar, esto parece más lógico, ya que es el orden inverso de lo que hará el hilo de envío. A race condition vulnerability was found in the tls subsystem of the Linux kernel. • https://git.kernel.org/stable/c/a42055e8d2c30d4decfc13ce943d09c7b9dad221 https://git.kernel.org/stable/c/dd32621f19243f89ce830919496a5dcc2158aa33 https://git.kernel.org/stable/c/196f198ca6fce04ba6ce262f5a0e4d567d7d219d https://git.kernel.org/stable/c/6db22d6c7a6dc914b12c0469b94eb639b6a8a146 https://git.kernel.org/stable/c/e327ed60bff4a991cd7a709c47c4f0c5b4a4fd57 https://git.kernel.org/stable/c/e01e3934a1b2d122919f73bc6ddbe1cdafc4bbdb https://access.redhat.com/security/cve/CVE-2024-26585 https://bugzilla.redhat.com/show_bug.cgi?id=2265517 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26584 – net: tls: handle backlogging of crypto requests
https://notcve.org/view.php?id=CVE-2024-26584
In the Linux kernel, the following vulnerability has been resolved: net: tls: handle backlogging of crypto requests Since we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on our requests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, when the cryptd queue for AESNI is full (easy to trigger with an artificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueued to the backlog but still processed. In that case, the async callback will also be called twice: first with err == -EINPROGRESS, which it seems we can just ignore, then with err == 0. Compared to Sabrina's original patch this version uses the new tls_*crypt_async_wait() helpers and converts the EBUSY to EINPROGRESS to avoid having to modify all the error handling paths. The handling is identical. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: tls: manejar el retraso de solicitudes criptográficas Dado que estamos configurando el indicador CRYPTO_TFM_REQ_MAY_BACKLOG en nuestras solicitudes a la API criptográfica, crypto_aead_{encrypt,decrypt} puede devolver -EBUSY en lugar de - EINPROGRESS en situaciones válidas. • https://git.kernel.org/stable/c/a54667f6728c2714a400f3c884727da74b6d1717 https://git.kernel.org/stable/c/3ade391adc584f17b5570fd205de3ad029090368 https://git.kernel.org/stable/c/cd1bbca03f3c1d845ce274c0d0a66de8e5929f72 https://git.kernel.org/stable/c/13eca403876bbea3716e82cdfe6f1e6febb38754 https://git.kernel.org/stable/c/ab6397f072e5097f267abf5cb08a8004e6b17694 https://git.kernel.org/stable/c/8590541473188741055d27b955db0777569438e3 https://access.redhat.com/security/cve/CVE-2024-26584 https://bugzilla.redhat.com/show_bug.cgi?id=2265519 • CWE-393: Return of Wrong Status Code CWE-755: Improper Handling of Exceptional Conditions •