CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43846 – lib: objagg: Fix general protection fault
https://notcve.org/view.php?id=CVE-2024-43846
In the Linux kernel, the following vulnerability has been resolved: lib: objagg: Fix general protection fault The library supports aggregation of objects into other objects only if the parent object does not have a parent itself. That is, nesting is not supported. Aggregation happens in two cases: Without and with hints, where hints are a pre-computed recommendation on how to aggregate the provided objects. Nesting is not possible in the first case due to a check that prevents it, but in the second case there is no check because the assumption is that nesting cannot happen when creating objects based on hints. The violation of this assumption leads to various warnings and eventually to a general protection fault [1]. Before fixing the root cause, error out when nesting happens and warn. [1] general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTI CPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G W 6.9.0-rc6-custom-gd9b4f1cca7fb #7 Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019 Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work RIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80 [...] Call Trace: <TASK> mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 process_one_work+0x151/0x370 worker_thread+0x2cb/0x3e0 kthread+0xd0/0x100 ret_from_fork+0x34/0x50 ret_from_fork_asm+0x1a/0x30 </TASK> • https://git.kernel.org/stable/c/9069a3817d82b01b3a55da382c774e3575946130 https://git.kernel.org/stable/c/8161263362154cbebfbf4808097b956a6a8cb98a https://git.kernel.org/stable/c/22ae17a267f4812861f0c644186c3421ff97dbfc https://git.kernel.org/stable/c/565213e005557eb6cc4e42189d26eb300e02f170 https://git.kernel.org/stable/c/5adc61d29bbb461d7f7c2b48dceaa90ecd182eb7 https://git.kernel.org/stable/c/1936fa05a180834c3b52e0439a6bddc07814d3eb https://git.kernel.org/stable/c/499f742fed42e74f1321f4b12ca196a66a2b49fc https://git.kernel.org/stable/c/b4a3a89fffcdf09702b1f161b914e52ab •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43845 – udf: Fix bogus checksum computation in udf_rename()
https://notcve.org/view.php?id=CVE-2024-43845
In the Linux kernel, the following vulnerability has been resolved: udf: Fix bogus checksum computation in udf_rename() Syzbot reports uninitialized memory access in udf_rename() when updating checksum of '..' directory entry of a moved directory. This is indeed true as we pass on-stack diriter.fi to the udf_update_tag() and because that has only struct fileIdentDesc included in it and not the impUse or name fields, the checksumming function is going to checksum random stack contents beyond the end of the structure. This is actually harmless because the following udf_fiiter_write_fi() will recompute the checksum from on-disk buffers where everything is properly included. So all that is needed is just removing the bogus calculation. • https://git.kernel.org/stable/c/9616d00140a1cdf0bfa557019b36923dc7796942 https://git.kernel.org/stable/c/e9109a92d2a95889498bed3719cd2318892171a2 https://git.kernel.org/stable/c/c996b570305e7a6910c2ce4cdcd4c22757ffe241 https://git.kernel.org/stable/c/fe2ead240c31e8d158713beca9d0681a6e6a53ab https://git.kernel.org/stable/c/40d7b3ed52449d36143bab8d3e70926aa61a60f4 https://git.kernel.org/stable/c/27ab33854873e6fb958cb074681a0107cc2ecc4c https://git.kernel.org/stable/c/9c439311c13fc6faab1921441165c9b8b500c83b •
CVSS: 7.3EPSS: 0%CPEs: 4EXPL: 0CVE-2024-43842 – wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter()
https://notcve.org/view.php?id=CVE-2024-43842
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: Fix array index mistake in rtw89_sta_info_get_iter() In rtw89_sta_info_get_iter() 'status->he_gi' is compared to array size. But then 'rate->he_gi' is used as array index instead of 'status->he_gi'. This can lead to go beyond array boundaries in case of 'rate->he_gi' is not equal to 'status->he_gi' and is bigger than array size. Looks like "copy-paste" mistake. Fix this mistake by replacing 'rate->he_gi' with 'status->he_gi'. Found by Linux Verification Center (linuxtesting.org) with SVACE. A possible array out-of-bounds read flaw was found in the Linux kernel. This issue may lead to a crash. • https://git.kernel.org/stable/c/e3ec7017f6a20d12ddd9fe23d345ebb7b8c104dd https://git.kernel.org/stable/c/a2a095c08b95372d6d0c5819b77f071af5e75366 https://git.kernel.org/stable/c/7a0edc3d83aff3a48813d78c9cad9daf38decc74 https://git.kernel.org/stable/c/96ae4de5bc4c8ba39fd072369398f59495b73f58 https://git.kernel.org/stable/c/85099c7ce4f9e64c66aa397cd9a37473637ab891 https://access.redhat.com/security/cve/CVE-2024-43842 https://bugzilla.redhat.com/show_bug.cgi?id=2305500 • CWE-129: Improper Validation of Array Index •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-43841 – wifi: virt_wifi: avoid reporting connection success with wrong SSID
https://notcve.org/view.php?id=CVE-2024-43841
In the Linux kernel, the following vulnerability has been resolved: wifi: virt_wifi: avoid reporting connection success with wrong SSID When user issues a connection with a different SSID than the one virt_wifi has advertised, the __cfg80211_connect_result() will trigger the warning: WARN_ON(bss_not_found). The issue is because the connection code in virt_wifi does not check the SSID from user space (it only checks the BSSID), and virt_wifi will call cfg80211_connect_result() with WLAN_STATUS_SUCCESS even if the SSID is different from the one virt_wifi has advertised. Eventually cfg80211 won't be able to find the cfg80211_bss and generate the warning. Fixed it by checking the SSID (from user space) in the connection code. • https://git.kernel.org/stable/c/c7cdba31ed8b87526db978976392802d3f93110c https://git.kernel.org/stable/c/994fc2164a03200c3bf42fb45b3d49d9d6d33a4d https://git.kernel.org/stable/c/05c4488a0e446c6ccde9f22b573950665e1cd414 https://git.kernel.org/stable/c/93e898a264b4e0a475552ba9f99a016eb43ef942 https://git.kernel.org/stable/c/d3cc85a10abc8eae48988336cdd3689ab92581b3 https://git.kernel.org/stable/c/36e92b5edc8e0daa18e9325674313802ce3fbc29 https://git.kernel.org/stable/c/416d3c1538df005195721a200b0371d39636e05d https://git.kernel.org/stable/c/b5d14b0c6716fad7f0c94ac6e1d6f60a4 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43840 – bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG
https://notcve.org/view.php?id=CVE-2024-43840
In the Linux kernel, the following vulnerability has been resolved: bpf, arm64: Fix trampoline for BPF_TRAMP_F_CALL_ORIG When BPF_TRAMP_F_CALL_ORIG is set, the trampoline calls __bpf_tramp_enter() and __bpf_tramp_exit() functions, passing them the struct bpf_tramp_image *im pointer as an argument in R0. The trampoline generation code uses emit_addr_mov_i64() to emit instructions for moving the bpf_tramp_image address into R0, but emit_addr_mov_i64() assumes the address to be in the vmalloc() space and uses only 48 bits. Because bpf_tramp_image is allocated using kzalloc(), its address can use more than 48-bits, in this case the trampoline will pass an invalid address to __bpf_tramp_enter/exit() causing a kernel crash. Fix this by using emit_a64_mov_i64() in place of emit_addr_mov_i64() as it can work with addresses that are greater than 48-bits. • https://git.kernel.org/stable/c/efc9909fdce00a827a37609628223cd45bf95d0b https://git.kernel.org/stable/c/6d218fcc707d6b2c3616b6cd24b948fd4825cfec https://git.kernel.org/stable/c/19d3c179a37730caf600a97fed3794feac2b197b •