CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49930 – wifi: ath11k: fix array out-of-bound access in SoC stats
https://notcve.org/view.php?id=CVE-2024-49930
In the Linux kernel, the following vulnerability has been resolved: wifi: ath11k: fix array out-of-bound access in SoC stats Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx() function access ath11k_soc_dp_stats::hal_reo_error using the REO destination SRNG ring ID, which is incorrect. SRNG ring ID differ from normal ring ID, and this usage leads to out-of-bounds array access. To fix this issue, modify ath11k_dp_process_rx() to use the normal ring ID directly instead of the SRNG ring ID to avoid out-of-bounds array access. Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1 • https://git.kernel.org/stable/c/0f26f26944035ec67546a944f182cbad6577a9c0 https://git.kernel.org/stable/c/4dd732893bd38cec51f887244314e2b47f0d658f https://git.kernel.org/stable/c/73e235728e515faccc104b0153b47d0f263b3344 https://git.kernel.org/stable/c/7a552bc2f3efe2aaf77a85cb34cdf4a63d81a1a7 https://git.kernel.org/stable/c/6045ef5b4b00fee3629689f791992900a1c94009 https://git.kernel.org/stable/c/01b77f5ee11c89754fb836af8f76799d3b72ae2f https://git.kernel.org/stable/c/69f253e46af98af17e3efa3e5dfa72fcb7d1983d •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49929 – wifi: iwlwifi: mvm: avoid NULL pointer dereference
https://notcve.org/view.php?id=CVE-2024-49929
In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: avoid NULL pointer dereference iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta pointer is not NULL. It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is dereferencing the ieee80211_sta pointer. If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL pointer. Fix this by checking the sta pointer before retrieving the mvmsta from it. If sta is not NULL, then mvmsta isn't either. • https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28 https://git.kernel.org/stable/c/cdbf51bfa4b0411820806777da36d93d49bc49a1 https://git.kernel.org/stable/c/c0b4f5d94934c290479180868a32c15ba36a6d9e https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49928 – wifi: rtw89: avoid reading out of bounds when loading TX power FW elements
https://notcve.org/view.php?id=CVE-2024-49928
In the Linux kernel, the following vulnerability has been resolved: wifi: rtw89: avoid reading out of bounds when loading TX power FW elements Because the loop-expression will do one more time before getting false from cond-expression, the original code copied one more entry size beyond valid region. Fix it by moving the entry copy to loop-body. • https://git.kernel.org/stable/c/83c84cdb75572048b67d6a3916283aeac865996e https://git.kernel.org/stable/c/4007c3d2da31d0c755ea3fcf55e395118e5d5621 https://git.kernel.org/stable/c/ed2e4bb17a4884cf29c3347353d8aabb7265b46c •
CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-49927 – x86/ioapic: Handle allocation failures gracefully
https://notcve.org/view.php?id=CVE-2024-49927
In the Linux kernel, the following vulnerability has been resolved: x86/ioapic: Handle allocation failures gracefully Breno observed panics when using failslab under certain conditions during runtime: can not alloc irq_pin_list (-1,0,20) Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed panic+0x4e9/0x590 mp_irqdomain_alloc+0x9ab/0xa80 irq_domain_alloc_irqs_locked+0x25d/0x8d0 __irq_domain_alloc_irqs+0x80/0x110 mp_map_pin_to_irq+0x645/0x890 acpi_register_gsi_ioapic+0xe6/0x150 hpet_open+0x313/0x480 That's a pointless panic which is a leftover of the historic IO/APIC code which panic'ed during early boot when the interrupt allocation failed. The only place which might justify panic is the PIT/HPET timer_check() code which tries to figure out whether the timer interrupt is delivered through the IO/APIC. But that code does not require to handle interrupt allocation failures. If the interrupt cannot be allocated then timer delivery fails and it either panics due to that or falls back to legacy mode. Cure this by removing the panic wrapper around __add_pin_to_irq_node() and making mp_irqdomain_alloc() aware of the failure condition and handle it as any other failure in this function gracefully. • https://git.kernel.org/stable/c/e479cb835feeb2abff97f25766e23b96a6eabe28 https://git.kernel.org/stable/c/ec862cd843faa6f0e84a7a07362f2786446bf697 https://git.kernel.org/stable/c/077e1b7cd521163ded545987bbbd389519aeed71 https://git.kernel.org/stable/c/649a5c2ffae797ce792023a70e84c7fe4b6fb8e0 https://git.kernel.org/stable/c/f17efbeb2922327ea01a9efa8829fea9a30e547d https://git.kernel.org/stable/c/830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49926 – rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb()
https://notcve.org/view.php?id=CVE-2024-49926
In the Linux kernel, the following vulnerability has been resolved: rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb() For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is defined as NR_CPUS instead of the number of possible cpus, this will cause the following system panic: smpboot: Allowing 4 CPUs, 0 hotplug CPUs ... setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1 ... BUG: unable to handle page fault for address: ffffffff9911c8c8 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W 6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee0245691283ea6 RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0 RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082 CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4: 00000000001706f0 Call Trace: <TASK> ? __die+0x23/0x80 ? page_fault_oops+0xa4/0x180 ? exc_page_fault+0x152/0x180 ? asm_exc_page_fault+0x26/0x40 ? • https://git.kernel.org/stable/c/3104bddc666ff64b90491868bbc4c7ebdd90aedf https://git.kernel.org/stable/c/05095271a4fb0f6497121a057f9a2edf386d5d96 https://git.kernel.org/stable/c/fd70e9f1d85f5323096ad313ba73f5fe3d15ea41 •