CVSS: 9.1EPSS: 0%CPEs: 9EXPL: 0CVE-2023-52832 – wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
https://notcve.org/view.php?id=CVE-2023-52832
In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: don't return unset power in ieee80211_get_tx_power() We can get a UBSAN warning if ieee80211_get_tx_power() returns the INT_MIN value mac80211 internally uses for "unset power level". UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type 'int' CPU: 0 PID: 20433 Comm: insmod Tainted: G WC OE Call Trace: dump_stack+0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 [cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [...] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] In this case, simply return an error instead, to indicate that no data is available. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: wifi: mac80211: no devolver energía no configurada en ieee80211_get_tx_power(). Podemos obtener una advertencia de UBSAN si ieee80211_get_tx_power() devuelve el valor INT_MIN que mac80211 usa internamente para "nivel de energía no configurada". UBSAN: desbordamiento de entero con signo en net/wireless/nl80211.c:3816:5 -2147483648 * 100 no se puede representar en el tipo 'int' CPU: 0 PID: 20433 Comm: insmod Contaminado: G WC OE Call Trace: dump_stack+ 0x74/0x92 ubsan_epilogue+0x9/0x50 handle_overflow+0x8d/0xd0 __ubsan_handle_mul_overflow+0xe/0x10 nl80211_send_iface+0x688/0x6b0 [cfg80211] [...] cfg80211_register_wdev+0x78/0xb0 cfg80211] cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211] [.. .] ieee80211_if_add+0x60e/0x8f0 [mac80211] ieee80211_register_hw+0xda5/0x1170 [mac80211] En este caso, simplemente devuelva un error para indicar que no hay datos disponibles. • https://git.kernel.org/stable/c/1571120c44dbe5757aee1612c5b6097cdc42710f https://git.kernel.org/stable/c/298e767362cade639b7121ecb3cc5345b6529f62 https://git.kernel.org/stable/c/efeae5f4972f75d50002bc50eb112ab9e7069b18 https://git.kernel.org/stable/c/717de20abdcd1d4993fa450e28b8086a352620ea https://git.kernel.org/stable/c/21a0f310a9f3bfd2b4cf4f382430e638607db846 https://git.kernel.org/stable/c/2be24c47ac19bf639c48c082486c08888bd603c6 https://git.kernel.org/stable/c/adc2474d823fe81d8da759207f4f1d3691aa775a https://git.kernel.org/stable/c/5a94cffe90e20e8fade0b9abd4370bd67 • CWE-190: Integer Overflow or Wraparound CWE-920: Improper Restriction of Power Consumption •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2023-52831 – cpu/hotplug: Don't offline the last non-isolated CPU
https://notcve.org/view.php?id=CVE-2023-52831
In the Linux kernel, the following vulnerability has been resolved: cpu/hotplug: Don't offline the last non-isolated CPU If a system has isolated CPUs via the "isolcpus=" command line parameter, then an attempt to offline the last housekeeping CPU will result in a WARN_ON() when rebuilding the scheduler domains and a subsequent panic due to and unhandled empty CPU mas in partition_sched_domains_locked(). cpuset_hotplug_workfn() rebuild_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset.effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN)); Thus results in an empty CPU mask which triggers the warning and then the subsequent crash: WARNING: CPU: 4 PID: 80 at kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Call trace: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+0x234/0x880 rebuild_sched_domains_locked+0x37c/0x798 rebuild_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930 Unable to handle kernel paging request at virtual address fffe80027ab37080 partition_sched_domains_locked+0x318/0x880 rebuild_sched_domains_locked+0x37c/0x798 Aside of the resulting crash, it does not make any sense to offline the last last housekeeping CPU. Prevent this by masking out the non-housekeeping CPUs when selecting a target CPU for initiating the CPU unplug operation via the work queue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cpu/hotplug: no desconectar la última CPU no aislada. Si un sistema tiene CPU aisladas mediante el parámetro de línea de comando "isolcpus=", entonces se intenta desconectar la última limpieza La CPU dará como resultado un WARN_ON() al reconstruir los dominios del programador y un pánico posterior debido a una masa de CPU vacía no controlada en particion_sched_domains_locked(). cpuset_hotplug_workfn() build_sched_domains_locked() ndoms = generate_sched_domains(&doms, &attr); cpumask_and(doms[0], top_cpuset. Effective_cpus, housekeeping_cpumask(HK_FLAG_DOMAIN)); Por lo tanto, se genera una máscara de CPU vacía que activa la advertencia y luego el bloqueo posterior: ADVERTENCIA: CPU: 4 PID: 80 en kernel/sched/topology.c:2366 build_sched_domains+0x120c/0x1408 Seguimiento de llamadas: build_sched_domains+0x120c/0x1408 partition_sched_domains_locked+ 0x234/0x880 build_sched_domains_locked+0x37c/0x798 build_sched_domains+0x30/0x58 cpuset_hotplug_workfn+0x2a8/0x930 No se puede manejar la solicitud de paginación del kernel en la dirección virtual fffe80027ab37080 particion_sched_domains_locked+0x318/0x880 _sched_domains_locked+0x37c/0x798 Aparte del bloqueo resultante, no tiene ningún sentido para desconectar la última CPU de mantenimiento. Evite esto enmascarando las CPU que no son de mantenimiento al seleccionar una CPU de destino para iniciar la operación de desconexión de la CPU a través de la cola de trabajo. • https://git.kernel.org/stable/c/3410b702354702b500bde10e3cc1f9db8731d908 https://git.kernel.org/stable/c/335a47ed71e332c82339d1aec0c7f6caccfcda13 https://git.kernel.org/stable/c/3073f6df783d9d75f7f69f73e16c7ef85d6cfb63 https://git.kernel.org/stable/c/38685e2a0476127db766f81b1c06019ddc4c9ffa https://access.redhat.com/security/cve/CVE-2023-52831 https://bugzilla.redhat.com/show_bug.cgi?id=2282740 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52829 – wifi: ath12k: fix possible out-of-bound write in ath12k_wmi_ext_hal_reg_caps()
https://notcve.org/view.php?id=CVE-2023-52829
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix possible out-of-bound write in ath12k_wmi_ext_hal_reg_caps() reg_cap.phy_id is extracted from WMI event and could be an unexpected value in case some errors happen. As a result out-of-bound write may occur to soc->hal_reg_cap. Fix it by validating reg_cap.phy_id before using it. This is found during code review. Compile tested only. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath12k: corrige una posible escritura fuera de los límites en ath12k_wmi_ext_hal_reg_caps() reg_cap.phy_id se extrae del evento WMI y podría ser un valor inesperado en caso de que ocurran algunos errores. Como resultado, puede ocurrir una escritura fuera de los límites en soc->hal_reg_cap. • https://git.kernel.org/stable/c/dfe13eaab043130f90dd3d57c7d88577c04adc97 https://git.kernel.org/stable/c/4dd0547e8b45faf6f95373be5436b66cde326c0e https://git.kernel.org/stable/c/b302dce3d9edea5b93d1902a541684a967f3c63c •
CVSS: 6.6EPSS: 0%CPEs: 6EXPL: 0CVE-2023-52828 – bpf: Detect IP == ksym.end as part of BPF program
https://notcve.org/view.php?id=CVE-2023-52828
In the Linux kernel, the following vulnerability has been resolved: bpf: Detect IP == ksym.end as part of BPF program Now that bpf_throw kfunc is the first such call instruction that has noreturn semantics within the verifier, this also kicks in dead code elimination in unprecedented ways. For one, any instruction following a bpf_throw call will never be marked as seen. Moreover, if a callchain ends up throwing, any instructions after the call instruction to the eventually throwing subprog in callers will also never be marked as seen. The tempting way to fix this would be to emit extra 'int3' instructions which bump the jited_len of a program, and ensure that during runtime when a program throws, we can discover its boundaries even if the call instruction to bpf_throw (or to subprogs that always throw) is emitted as the final instruction in the program. An example of such a program would be this: do_something(): ... r0 = 0 exit foo(): r1 = 0 call bpf_throw r0 = 0 exit bar(cond): if r1 != 0 goto pc+2 call do_something exit call foo r0 = 0 // Never seen by verifier exit // main(ctx): r1 = ... call bar r0 = 0 exit Here, if we do end up throwing, the stacktrace would be the following: bpf_throw foo bar main In bar, the final instruction emitted will be the call to foo, as such, the return address will be the subsequent instruction (which the JIT emits as int3 on x86). This will end up lying outside the jited_len of the program, thus, when unwinding, we will fail to discover the return address as belonging to any program and end up in a panic due to the unreliable stack unwinding of BPF programs that we never expect. To remedy this case, make bpf_prog_ksym_find treat IP == ksym.end as part of the BPF program, so that is_bpf_text_address returns true when such a case occurs, and we are able to unwind reliably when the final instruction ends up being a call instruction. • https://git.kernel.org/stable/c/6058e4829696412457729a00734969acc6fd1d18 https://git.kernel.org/stable/c/cf353904a82873e952633fcac4385c2fcd3a46e1 https://git.kernel.org/stable/c/aa42a7cb92647786719fe9608685da345883878f https://git.kernel.org/stable/c/327b92e8cb527ae097961ffd1610c720481947f5 https://git.kernel.org/stable/c/821a7e4143af115b840ec199eb179537e18af922 https://git.kernel.org/stable/c/66d9111f3517f85ef2af0337ece02683ce0faf21 •
CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2023-52827 – wifi: ath12k: fix possible out-of-bound read in ath12k_htt_pull_ppdu_stats()
https://notcve.org/view.php?id=CVE-2023-52827
In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix possible out-of-bound read in ath12k_htt_pull_ppdu_stats() len is extracted from HTT message and could be an unexpected value in case errors happen, so add validation before using to avoid possible out-of-bound read in the following message iteration and parsing. The same issue also applies to ppdu_info->ppdu_stats.common.num_users, so validate it before using too. These are found during code review. Compile test only. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: wifi: ath12k: corrige una posible lectura fuera de los límites en ath12k_htt_pull_ppdu_stats(). len se extrae del mensaje HTT y podría ser un valor inesperado en caso de que ocurran errores, así que agregue validación antes de usarlo para evitar una posible lectura fuera de los límites en la siguiente iteración y análisis del mensaje. El mismo problema también se aplica a ppdu_info->ppdu_stats.common.num_users, así que valídelo antes de usarlo también. Estos se encuentran durante la revisión del código. Compilar prueba únicamente. • https://git.kernel.org/stable/c/79527c21a3ce04cffc35ea54f74ee087e532be57 https://git.kernel.org/stable/c/c9e44111da221246efb2e623ae1be40a5cf6542c https://git.kernel.org/stable/c/1bc44a505a229bb1dd4957e11aa594edeea3690e • CWE-125: Out-of-bounds Read •