CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-43843 – riscv, bpf: Fix out-of-bounds issue when preparing trampoline image
https://notcve.org/view.php?id=CVE-2024-43843
In the Linux kernel, the following vulnerability has been resolved: riscv, bpf: Fix out-of-bounds issue when preparing trampoline image We get the size of the trampoline image during the dry run phase and allocate memory based on that size. The allocated image will then be populated with instructions during the real patch phase. But after commit 26ef208c209a ("bpf: Use arch_bpf_trampoline_size"), the `im` argument is inconsistent in the dry run and real patch phase. This may cause emit_imm in RV64 to generate a different number of instructions when generating the 'im' address, potentially causing out-of-bounds issues. Let's emit the maximum number of instructions for the "im" address during dry run to fix this problem. • https://git.kernel.org/stable/c/26ef208c209a0e6eed8942a5d191b39dccfa6e38 https://git.kernel.org/stable/c/3e6a1b1b179abb643ec3560c02bc3082bc92285f https://git.kernel.org/stable/c/9f1e16fb1fc9826001c69e0551d51fbbcd2d74e9 •
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. • 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 •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-43839 – bna: adjust 'name' buf size of bna_tcb and bna_ccb structures
https://notcve.org/view.php?id=CVE-2024-43839
In the Linux kernel, the following vulnerability has been resolved: bna: adjust 'name' buf size of bna_tcb and bna_ccb structures To have enough space to write all possible sprintf() args. Currently 'name' size is 16, but the first '%s' specifier may already need at least 16 characters, since 'bnad->netdev->name' is used there. For '%d' specifiers, assume that they require: * 1 char for 'tx_id + tx_info->tcb[i]->id' sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for 'rx_id + rx_info->rx_ctrl[i].ccb->id', BNAD_MAX_RXP_PER_RX is 16 And replace sprintf with snprintf. Detected using the static analysis tool - Svace. • https://git.kernel.org/stable/c/8b230ed8ec96c933047dd0625cf95f739e4939a6 https://git.kernel.org/stable/c/f121740f69eda4da2de9a20a6687a13593e72540 https://git.kernel.org/stable/c/c90b1cd7758fd4839909e838ae195d19f8065d76 https://git.kernel.org/stable/c/6ce46045f9b90d952602e2c0b8886cfadf860bf1 https://git.kernel.org/stable/c/6d20c4044ab4d0e6a99aa35853e66f0aed5589e3 https://git.kernel.org/stable/c/ab748dd10d8742561f2980fea08ffb4f0cacfdef https://git.kernel.org/stable/c/b0ff0cd0847b03c0a0abe20cfa900eabcfcb9e43 https://git.kernel.org/stable/c/e0f48f51d55fb187400e9787192eda09f •