CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56608 – drm/amd/display: Fix out-of-bounds access in 'dcn21_link_encoder_create'
https://notcve.org/view.php?id=CVE-2024-56608
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix out-of-bounds access in 'dcn21_link_encoder_create' An issue was identified in the dcn21_link_encoder_create function where an out-of-bounds access could occur when the hpd_source index was used to reference the link_enc_hpd_regs array. This array has a fixed size and the index was not being checked against the array's bounds before accessing it. This fix adds a conditional check to ensure that the hpd_source index is within the valid range of the link_enc_hpd_regs array. If the index is out of bounds, the function now returns NULL to prevent undefined behavior. References: [ 65.920507] ------------[ cut here ]------------ [ 65.920510] UBSAN: array-index-out-of-bounds in drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn21/dcn21_resource.c:1312:29 [ 65.920519] index 7 is out of range for type 'dcn10_link_enc_hpd_registers [5]' [ 65.920523] CPU: 3 PID: 1178 Comm: modprobe Tainted: G OE 6.8.0-cleanershaderfeatureresetasdntipmi200nv2132 #13 [ 65.920525] Hardware name: AMD Majolica-RN/Majolica-RN, BIOS WMJ0429N_Weekly_20_04_2 04/29/2020 [ 65.920527] Call Trace: [ 65.920529] <TASK> [ 65.920532] dump_stack_lvl+0x48/0x70 [ 65.920541] dump_stack+0x10/0x20 [ 65.920543] __ubsan_handle_out_of_bounds+0xa2/0xe0 [ 65.920549] dcn21_link_encoder_create+0xd9/0x140 [amdgpu] [ 65.921009] link_create+0x6d3/0xed0 [amdgpu] [ 65.921355] create_links+0x18a/0x4e0 [amdgpu] [ 65.921679] dc_create+0x360/0x720 [amdgpu] [ 65.921999] ? dmi_matches+0xa0/0x220 [ 65.922004] amdgpu_dm_init+0x2b6/0x2c90 [amdgpu] [ 65.922342] ? • https://git.kernel.org/stable/c/f01ddd589e162979421e6914b1c74018633f01e0 https://git.kernel.org/stable/c/63de35a8fcfca59ae8750d469a7eb220c7557baf •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56607 – wifi: ath12k: fix atomic calls in ath12k_mac_op_set_bitrate_mask()
https://notcve.org/view.php?id=CVE-2024-56607
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix atomic calls in ath12k_mac_op_set_bitrate_mask() When I try to manually set bitrates: iw wlan0 set bitrates legacy-2.4 1 I get sleeping from invalid context error, see below. Fix that by switching to use recently introduced ieee80211_iterate_stations_mtx(). Do note that WCN6855 firmware is still crashing, I'm not sure if that firmware even supports bitrate WMI commands and should we consider disabling ath12k_mac_op_set_bitrate_mask() for WCN6855? But that's for another patch. BUG: sleeping function called from invalid context at drivers/net/wireless/ath/ath12k/wmi.c:420 in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 2236, name: iw preempt_count: 0, expected: 0 RCU nest depth: 1, expected: 0 3 locks held by iw/2236: #0: ffffffffabc6f1d8 (cb_lock){++++}-{3:3}, at: genl_rcv+0x14/0x40 #1: ffff888138410810 (&rdev->wiphy.mtx){+.+.}-{3:3}, at: nl80211_pre_doit+0x54d/0x800 [cfg80211] #2: ffffffffab2cfaa0 (rcu_read_lock){....}-{1:2}, at: ieee80211_iterate_stations_atomic+0x2f/0x200 [mac80211] CPU: 3 UID: 0 PID: 2236 Comm: iw Not tainted 6.11.0-rc7-wt-ath+ #1772 Hardware name: Intel(R) Client Systems NUC8i7HVK/NUC8i7HVB, BIOS HNKBLi70.86A.0067.2021.0528.1339 05/28/2021 Call Trace: <TASK> dump_stack_lvl+0xa4/0xe0 dump_stack+0x10/0x20 __might_resched+0x363/0x5a0 ? __alloc_skb+0x165/0x340 __might_sleep+0xad/0x160 ath12k_wmi_cmd_send+0xb1/0x3d0 [ath12k] ? ath12k_wmi_init_wcn7850+0xa40/0xa40 [ath12k] ? • https://git.kernel.org/stable/c/2093f062b26805789b73f2af214691475d9baa29 https://git.kernel.org/stable/c/8fac3266c68a8e647240b8ac8d0b82f1821edf85 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56606 – af_packet: avoid erroring out after sock_init_data() in packet_create()
https://notcve.org/view.php?id=CVE-2024-56606
In the Linux kernel, the following vulnerability has been resolved: af_packet: avoid erroring out after sock_init_data() in packet_create() After sock_init_data() the allocated sk object is attached to the provided sock object. On error, packet_create() frees the sk object leaving the dangling pointer in the sock object on return. Some other code may try to use this pointer and cause use-after-free. • https://git.kernel.org/stable/c/71b22837a5e55ac27d6a14b9cdf2326587405c4f https://git.kernel.org/stable/c/1dc1e1db927056cb323296e2294a855cd003dfe7 https://git.kernel.org/stable/c/132e615bb1d7cdec2d3cfbdec2efa630e923fd21 https://git.kernel.org/stable/c/a6cf750b737374454a4e03a5ed449a3eb0c96414 https://git.kernel.org/stable/c/157f08db94123e2ba56877dd0ac88908b13a5dd0 https://git.kernel.org/stable/c/fd09880b16d33aa5a7420578e01cd79148fa9829 https://git.kernel.org/stable/c/46f2a11cb82b657fd15bab1c47821b635e03838b •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-56605 – Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create()
https://notcve.org/view.php?id=CVE-2024-56605
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: do not leave dangling sk pointer on error in l2cap_sock_create() bt_sock_alloc() allocates the sk object and attaches it to the provided sock object. On error l2cap_sock_alloc() frees the sk object, but the dangling pointer is still attached to the sock object, which may create use-after-free in other code. • https://git.kernel.org/stable/c/f6ad641646b67f29c7578dcd6c25813c7dcbf51e https://git.kernel.org/stable/c/daa13175a6dea312a76099066cb4cbd4fc959a84 https://git.kernel.org/stable/c/a8677028dd5123e5e525b8195483994d87123de4 https://git.kernel.org/stable/c/bb2f2342a6ddf7c04f9aefbbfe86104cd138e629 https://git.kernel.org/stable/c/8ad09ddc63ace3950ac43db6fbfe25b40f589dd6 https://git.kernel.org/stable/c/61686abc2f3c2c67822aa23ce6f160467ec83d35 https://git.kernel.org/stable/c/7c4f78cdb8e7501e9f92d291a7d956591bf73be9 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56604 – Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc()
https://notcve.org/view.php?id=CVE-2024-56604
In the Linux kernel, the following vulnerability has been resolved: Bluetooth: RFCOMM: avoid leaving dangling sk pointer in rfcomm_sock_alloc() bt_sock_alloc() attaches allocated sk object to the provided sock object. If rfcomm_dlc_alloc() fails, we release the sk object, but leave the dangling pointer in the sock object, which may cause use-after-free. Fix this by swapping calls to bt_sock_alloc() and rfcomm_dlc_alloc(). • https://git.kernel.org/stable/c/ac3eaac4cf142a15fe67be747a682b1416efeb6e https://git.kernel.org/stable/c/6021ccc2471b7b95e29b7cfc7938e042bf56e281 https://git.kernel.org/stable/c/32df687e129ef0f9afcbcc914f7c32deb28fd481 https://git.kernel.org/stable/c/3945c799f12b8d1f49a3b48369ca494d981ac465 •