CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26770 – HID: nvidia-shield: Add missing null pointer checks to LED initialization
https://notcve.org/view.php?id=CVE-2024-26770
In the Linux kernel, the following vulnerability has been resolved: HID: nvidia-shield: Add missing null pointer checks to LED initialization devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. Ensure the allocation was successful by checking the pointer validity. [jkosina@suse.com: tweak changelog a bit] En el kernel de Linux, se resolvió la siguiente vulnerabilidad: HID: nvidia-shield: agregar comprobaciones de puntero nulo faltantes a la inicialización del LED devm_kasprintf() devuelve un puntero a la memoria asignada dinámicamente que puede ser NULL en caso de falla. Asegúrese de que la asignación se haya realizado correctamente comprobando la validez del puntero. [jkosina@suse.com: modificar un poco el registro de cambios] • https://git.kernel.org/stable/c/83527a13740f57b45f162e3af4c7db4b88521100 https://git.kernel.org/stable/c/e71cc4a1e584293deafff1a7dea614b0210d0443 https://git.kernel.org/stable/c/b6eda11c44dc89a681e1c105f0f4660e69b1e183 •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26769 – nvmet-fc: avoid deadlock on delete association path
https://notcve.org/view.php?id=CVE-2024-26769
In the Linux kernel, the following vulnerability has been resolved: nvmet-fc: avoid deadlock on delete association path When deleting an association the shutdown path is deadlocking because we try to flush the nvmet_wq nested. Avoid this by deadlock by deferring the put work into its own work item. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nvmet-fc: evita el punto muerto al eliminar la ruta de asociación Al eliminar una asociación, la ruta de cierre se bloquea porque intentamos vaciar el nvmet_wq anidado. Evite este punto muerto al diferir el trabajo colocado en su propio elemento de trabajo. • https://git.kernel.org/stable/c/5e0bc09a52b6169ce90f7ac6e195791adb16cec4 https://git.kernel.org/stable/c/9e6987f8937a7bd7516aa52f25cb7e12c0c92ee8 https://git.kernel.org/stable/c/eaf0971fdabf2a93c1429dc6bedf3bbe85dffa30 https://git.kernel.org/stable/c/1d86f79287206deec36d63b89c741cf542b6cadd https://git.kernel.org/stable/c/710c69dbaccdac312e32931abcb8499c1525d397 https://access.redhat.com/security/cve/CVE-2024-26769 https://bugzilla.redhat.com/show_bug.cgi?id=2273180 • CWE-833: Deadlock •
CVSS: 6.5EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26768 – LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC]
https://notcve.org/view.php?id=CVE-2024-26768
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Change acpi_core_pic[NR_CPUS] to acpi_core_pic[MAX_CORE_PIC] With default config, the value of NR_CPUS is 64. When HW platform has more then 64 cpus, system will crash on these platforms. MAX_CORE_PIC is the maximum cpu number in MADT table (max physical number) which can exceed the supported maximum cpu number (NR_CPUS, max logical number), but kernel should not crash. Kernel should boot cpus with NR_CPUS, let the remainder cpus stay in BIOS. The potential crash reason is that the array acpi_core_pic[NR_CPUS] can be overflowed when parsing MADT table, and it is obvious that CORE_PIC should be corresponding to physical core rather than logical core, so it is better to define the array as acpi_core_pic[MAX_CORE_PIC]. With the patch, system can boot up 64 vcpus with qemu parameter -smp 128, otherwise system will crash with the following message. [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000420000004259, era == 90000000037a5f0c, ra == 90000000037a46ec [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.8.0-rc2+ #192 [ 0.000000] Hardware name: QEMU QEMU Virtual Machine, BIOS unknown 2/2/2022 [ 0.000000] pc 90000000037a5f0c ra 90000000037a46ec tp 9000000003c90000 sp 9000000003c93d60 [ 0.000000] a0 0000000000000019 a1 9000000003d93bc0 a2 0000000000000000 a3 9000000003c93bd8 [ 0.000000] a4 9000000003c93a74 a5 9000000083c93a67 a6 9000000003c938f0 a7 0000000000000005 [ 0.000000] t0 0000420000004201 t1 0000000000000000 t2 0000000000000001 t3 0000000000000001 [ 0.000000] t4 0000000000000003 t5 0000000000000000 t6 0000000000000030 t7 0000000000000063 [ 0.000000] t8 0000000000000014 u0 ffffffffffffffff s9 0000000000000000 s0 9000000003caee98 [ 0.000000] s1 90000000041b0480 s2 9000000003c93da0 s3 9000000003c93d98 s4 9000000003c93d90 [ 0.000000] s5 9000000003caa000 s6 000000000a7fd000 s7 000000000f556b60 s8 000000000e0a4330 [ 0.000000] ra: 90000000037a46ec platform_init+0x214/0x250 [ 0.000000] ERA: 90000000037a5f0c efi_runtime_init+0x30/0x94 [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0) [ 0.000000] BADV: 0000420000004259 [ 0.000000] PRID: 0014c010 (Loongson-64bit, Loongson-3A5000) [ 0.000000] Modules linked in: [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [ 0.000000] Stack : 9000000003c93a14 9000000003800898 90000000041844f8 90000000037a46ec [ 0.000000] 000000000a7fd000 0000000008290000 0000000000000000 0000000000000000 [ 0.000000] 0000000000000000 0000000000000000 00000000019d8000 000000000f556b60 [ 0.000000] 000000000a7fd000 000000000f556b08 9000000003ca7700 9000000003800000 [ 0.000000] 9000000003c93e50 9000000003800898 9000000003800108 90000000037a484c [ 0.000000] 000000000e0a4330 000000000f556b60 000000000a7fd000 000000000f556b08 [ 0.000000] 9000000003ca7700 9000000004184000 0000000000200000 000000000e02b018 [ 0.000000] 000000000a7fd000 90000000037a0790 9000000003800108 0000000000000000 [ 0.000000] 0000000000000000 000000000e0a4330 000000000f556b60 000000000a7fd000 [ 0.000000] 000000000f556b08 000000000eaae298 000000000eaa5040 0000000000200000 [ 0.000000] ... [ 0.000000] Call Trace: [ 0.000000] [<90000000037a5f0c>] efi_runtime_init+0x30/0x94 [ 0.000000] [<90000000037a46ec>] platform_init+0x214/0x250 [ 0.000000] [<90000000037a484c>] setup_arch+0x124/0x45c [ 0.000000] [<90000000037a0790>] start_kernel+0x90/0x670 [ 0.000000] [<900000000378b0d8>] kernel_entry+0xd8/0xdc En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LoongArch: cambie acpi_core_pic[NR_CPUS] a acpi_core_pic[MAX_CORE_PIC] Con la configuración predeterminada, el valor de NR_CPUS es 64. Cuando la plataforma HW tiene más de 64 cpus, el SYSTEM fallará en estas plataformas . • https://git.kernel.org/stable/c/88e189bd16e5889e44a41b3309558ebab78b9280 https://git.kernel.org/stable/c/0f6810e39898af2d2cabd9313e4dbc945fb5dfdd https://git.kernel.org/stable/c/4551b30525cf3d2f026b92401ffe241eb04dfebe • CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow') •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26767 – drm/amd/display: fixed integer types and null check locations
https://notcve.org/view.php?id=CVE-2024-26767
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: fixed integer types and null check locations [why]: issues fixed: - comparison with wider integer type in loop condition which can cause infinite loops - pointer dereference before null check En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/amd/display: tipos de enteros fijos y ubicaciones de verificación nula [por qué]: problemas solucionados: - comparación con un tipo de entero más amplio en condición de bucle que puede causar bucles infinitos - desreferencia del puntero antes cheque nulo • https://git.kernel.org/stable/c/71783d1ff65204d69207fd156d4b2eb1d3882375 https://git.kernel.org/stable/c/beea9ab9080cd2ef46296070bb327af066ee09d7 https://git.kernel.org/stable/c/0484e05d048b66d01d1f3c1d2306010bb57d8738 https://access.redhat.com/security/cve/CVE-2024-26767 https://bugzilla.redhat.com/show_bug.cgi?id=2273185 • CWE-170: Improper Null Termination •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-26766 – IB/hfi1: Fix sdma.h tx->num_descs off-by-one error
https://notcve.org/view.php?id=CVE-2024-26766
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix sdma.h tx->num_descs off-by-one error Unfortunately the commit `fd8958efe877` introduced another error causing the `descs` array to overflow. This reults in further crashes easily reproducible by `sendmsg` system call. [ 1080.836473] general protection fault, probably for non-canonical address 0x400300015528b00a: 0000 [#1] PREEMPT SMP PTI [ 1080.869326] RIP: 0010:hfi1_ipoib_build_ib_tx_headers.constprop.0+0xe1/0x2b0 [hfi1] -- [ 1080.974535] Call Trace: [ 1080.976990] <TASK> [ 1081.021929] hfi1_ipoib_send_dma_common+0x7a/0x2e0 [hfi1] [ 1081.027364] hfi1_ipoib_send_dma_list+0x62/0x270 [hfi1] [ 1081.032633] hfi1_ipoib_send+0x112/0x300 [hfi1] [ 1081.042001] ipoib_start_xmit+0x2a9/0x2d0 [ib_ipoib] [ 1081.046978] dev_hard_start_xmit+0xc4/0x210 -- [ 1081.148347] __sys_sendmsg+0x59/0xa0 crash> ipoib_txreq 0xffff9cfeba229f00 struct ipoib_txreq { txreq = { list = { next = 0xffff9cfeba229f00, prev = 0xffff9cfeba229f00 }, descp = 0xffff9cfeba229f40, coalesce_buf = 0x0, wait = 0xffff9cfea4e69a48, complete = 0xffffffffc0fe0760 <hfi1_ipoib_sdma_complete>, packet_len = 0x46d, tlen = 0x0, num_desc = 0x0, desc_limit = 0x6, next_descq_idx = 0x45c, coalesce_idx = 0x0, flags = 0x0, descs = {{ qw = {0x8024000120dffb00, 0x4} # SDMA_DESC0_FIRST_DESC_FLAG (bit 63) }, { qw = { 0x3800014231b108, 0x4} }, { qw = { 0x310000e4ee0fcf0, 0x8} }, { qw = { 0x3000012e9f8000, 0x8} }, { qw = { 0x59000dfb9d0000, 0x8} }, { qw = { 0x78000e02e40000, 0x8} }} }, sdma_hdr = 0x400300015528b000, <<< invalid pointer in the tx request structure sdma_status = 0x0, SDMA_DESC0_LAST_DESC_FLAG (bit 62) complete = 0x0, priv = 0x0, txq = 0xffff9cfea4e69880, skb = 0xffff9d099809f400 } If an SDMA send consists of exactly 6 descriptors and requires dword padding (in the 7th descriptor), the sdma_txreq descriptor array is not properly expanded and the packet will overflow into the container structure. This results in a panic when the send completion runs. The exact panic varies depending on what elements of the container structure get corrupted. The fix is to use the correct expression in _pad_sdma_tx_descs() to test the need to expand the descriptor array. With this patch the crashes are no longer reproducible and the machine is stable. • https://git.kernel.org/stable/c/d1c1ee052d25ca23735eea912f843bc7834781b4 https://git.kernel.org/stable/c/40ac5cb6cbb01afa40881f78b4d2f559fb7065c4 https://git.kernel.org/stable/c/6cf8f3d690bb5ad31ef0f41a6206ecf5a068d179 https://git.kernel.org/stable/c/bd57756a7e43c7127d0eca1fc5868e705fd0f7ba https://git.kernel.org/stable/c/eeaf35f4e3b360162081de5e744cf32d6d1b0091 https://git.kernel.org/stable/c/fd8958efe8779d3db19c9124fce593ce681ac709 https://git.kernel.org/stable/c/0ef9594936d1f078e8599a1cf683b052df2bec00 https://git.kernel.org/stable/c/115b7f3bc1dce590a6851a2dcf23dc110 •