CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26841 – LoongArch: Update cpu_sibling_map when disabling nonboot CPUs
https://notcve.org/view.php?id=CVE-2024-26841
In the Linux kernel, the following vulnerability has been resolved: LoongArch: Update cpu_sibling_map when disabling nonboot CPUs Update cpu_sibling_map when disabling nonboot CPUs by defining & calling clear_cpu_sibling_map(), otherwise we get such errors on SMT systems: jump label: negative count! WARNING: CPU: 6 PID: 45 at kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100 CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 pc 90000000004c302c ra 90000000004c302c tp 90000001005bc000 sp 90000001005bfd20 a0 000000000000001b a1 900000000224c278 a2 90000001005bfb58 a3 900000000224c280 a4 900000000224c278 a5 90000001005bfb50 a6 0000000000000001 a7 0000000000000001 t0 ce87a4763eb5234a t1 ce87a4763eb5234a t2 0000000000000000 t3 0000000000000000 t4 0000000000000006 t5 0000000000000000 t6 0000000000000064 t7 0000000000001964 t8 000000000009ebf6 u0 9000000001f2a068 s9 0000000000000000 s0 900000000246a2d8 s1 ffffffffffffffff s2 ffffffffffffffff s3 90000000021518c0 s4 0000000000000040 s5 9000000002151058 s6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006 ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 ERA: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1c (LIE=2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EsubCode=0) PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) CPU: 6 PID: 45 Comm: cpuhp/6 Not tainted 6.8.0-rc5+ #1340 Stack : 0000000000000000 900000000203f258 900000000179afc8 90000001005bc000 90000001005bf980 0000000000000000 90000001005bf988 9000000001fe0be0 900000000224c280 900000000224c278 90000001005bf8c0 0000000000000001 0000000000000001 ce87a4763eb5234a 0000000007f38000 90000001003f8cc0 0000000000000000 0000000000000006 0000000000000000 4c206e6f73676e6f 6f4c203a656d616e 000000000009ec99 0000000007f38000 0000000000000000 900000000214b000 9000000001fe0be0 0000000000000004 0000000000000000 0000000000000107 0000000000000009 ffffffffffafdabe 00000000000000b4 0000000000000006 90000000004c302c 9000000000224528 00005555939a0c7c 00000000000000b0 0000000000000004 0000000000000000 0000000000071c1c ... Call Trace: [<9000000000224528>] show_stack+0x48/0x1a0 [<900000000179afc8>] dump_stack_lvl+0x78/0xa0 [<9000000000263ed0>] __warn+0x90/0x1a0 [<90000000017419b8>] report_bug+0x1b8/0x280 [<900000000179c564>] do_bp+0x264/0x420 [<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100 [<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300 [<9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0 [<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240 [<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0 [<900000000029a720>] kthread+0x140/0x160 [<9000000000222288>] ret_from_kernel_thread+0xc/0xa4 En el kernel de Linux, se resolvió la siguiente vulnerabilidad: LoongArch: actualice cpu_sibling_map al deshabilitar las CPU que no son de arranque. Actualice cpu_sibling_map al deshabilitar las CPU que no son de arranque definiendo y llamando a clear_cpu_sibling_map(); de lo contrario, obtenemos este tipo de errores en los sistemas SMT: etiqueta de salto: recuento negativo. ADVERTENCIA: CPU: 6 PID: 45 en kernel/jump_label.c:263 __static_key_slow_dec_cpuslocked+0xec/0x100 CPU: 6 PID: 45 Comm: cpuhp/6 No contaminado 6.8.0-rc5+ #1340 pc 90000000004c302c ra 90000000004c3 02c tp 90000001005bc000 sp 90000001005bfd20 a0 000000000000001B A1 900000000224C278 A2 90000001005BFB58 A3 900000000224C280 A4 900000000224C278 A5 90000001005BFB50 A6 00000000000001 A7 00000000000001 T0 763EB5234A T2 0000000000000000 T3 000000000000000000 T4 000000000000000006 T5 00000000000000 T6 0000000000000064 T7 000000000000001964 T8 46a2d8 S1 fffffffffffffff S2 fffffffffffffff S3 90000000021518C0 S4 0000000000000040 S5 9000000002151058 S6 9000000009828e40 s7 00000000000000b4 s8 0000000000000006 ra: 90000000004c302c __static_key_slow_dec_cpuslocked+0xec/0x100 ERA: 90000000004c302c _key_slow_dec_cpuslocked+0xec/0x100 CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) PRMD: 00000004 (PPLV0 +PIE -PWE ) EUEN: 00000000 (-FPE -SXE -ASXE -BTE) ECFG: 00071c1c (LIE=2-4,10-12 VS=7) ESTAT: 000c0000 [BRK] (IS= ECode=12 EssubCode=0) PRID: 0014d000 (Loongson-64bit, Loongson-3A6000-HV) CPU: 6 PID: 45 Comm: CPUHP/6 No contaminado 6.8.0-RC5+ #1340 Pila: 000000000000000000 90000000000203F258 90000000000179AFC8 90000005BC000 900001005BF980 005bf988 900000000001FE0BE0 900000000224C280 90000000000224C278 9000000001005BF8C0 0000000000000001 0000000000000001 CE87A4763EB5234A 0000000007F38000 90000000033F8CA0000000000000000000000000000000000 MUTITOS. 0000000000000006 0000000000000000 4C206E6F73676E6F 6F4C203A656D616E 000000000009EC99 0000000007F38000 000000000000000000000000214BECT 0000000000000009 FFFFFFFFFFFAFDABE 00000000000000B4 000000000000000006 90000000004C302C 9000000000224528 00005555939A0C7C 0000000000000000B0 00000000000004 4528>] show_stack+0x48/0x1a0 [<900000000179AFC8>] dump_stack_lvl+0x78/0xa0 [ <9000000000263ed0>] __warn+0x90/0x1a0 [<90000000017419b8>] report_bug+0x1b8/0x280 [<900000000179c564>] do_bp+0x264/0x420 [<90000000004c302c>] __static_key_slow_dec_cpuslocked+0xec/0x100 [<90000000002b4d7c>] sched_cpu_deactivate+0x2fc/0x300 [ <9000000000266498>] cpuhp_invoke_callback+0x178/0x8a0 [<9000000000267f70>] cpuhp_thread_fun+0xf0/0x240 [<90000000002a117c>] smpboot_thread_fn+0x1dc/0x2e0 [<900000000029a720>] kthread+0x140/0x160 [<9000000000222288>] ret_from_kernel_thread+0xc/0xa4 • https://git.kernel.org/stable/c/b1ec3d6b86fdd057559a5908e6668279bf770e0e https://git.kernel.org/stable/c/0d862db64d26c2905ba1a6a8561466b215b664c2 https://git.kernel.org/stable/c/752cd08da320a667a833803a8fd6bb266114cce5 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26840 – cachefiles: fix memory leak in cachefiles_add_cache()
https://notcve.org/view.php?id=CVE-2024-26840
In the Linux kernel, the following vulnerability has been resolved: cachefiles: fix memory leak in cachefiles_add_cache() The following memory leak was reported after unbinding /dev/cachefiles: ================================================================== unreferenced object 0xffff9b674176e3c0 (size 192): comm "cachefilesd2", pid 680, jiffies 4294881224 hex dump (first 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc ea38a44b): [<ffffffff8eb8a1a5>] kmem_cache_alloc+0x2d5/0x370 [<ffffffff8e917f86>] prepare_creds+0x26/0x2e0 [<ffffffffc002eeef>] cachefiles_determine_cache_security+0x1f/0x120 [<ffffffffc00243ec>] cachefiles_add_cache+0x13c/0x3a0 [<ffffffffc0025216>] cachefiles_daemon_write+0x146/0x1c0 [<ffffffff8ebc4a3b>] vfs_write+0xcb/0x520 [<ffffffff8ebc5069>] ksys_write+0x69/0xf0 [<ffffffff8f6d4662>] do_syscall_64+0x72/0x140 [<ffffffff8f8000aa>] entry_SYSCALL_64_after_hwframe+0x6e/0x76 ================================================================== Put the reference count of cache_cred in cachefiles_daemon_unbind() to fix the problem. And also put cache_cred in cachefiles_add_cache() error branch to avoid memory leaks. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: cachefiles: corrige la pérdida de memoria en cachefiles_add_cache() Se informó la siguiente pérdida de memoria después de desvincular /dev/cachefiles: ================= ==================================================== objeto sin referencia 0xffff9b674176e3c0 (tamaño 192): comm "cachefilesd2", pid 680, jiffies 4294881224 volcado hexadecimal (primeros 32 bytes): 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ retroceso (crc ea38a44b): [ ] kmem_cache_alloc+0x2d5/0x370 [] prepare_creds+0x26/0x2e0 [] cachefiles_determine_cache_security+0x1f/0x120 [] cachefiles_add_cache+0x13c/0x 3a0 [] cachefiles_daemon_write+0x146/0x1c0 [ ] vfs_write+0xcb/0x520 [] ksys_write+0x69/0xf0 [] do_syscall_64+0x72/0x140 [] Entry_SYSCALL_64_after_hwframe+0x6e/0x76 =============== ==================================================== == Coloque el recuento de referencias de cache_cred en cachefiles_daemon_unbind() para solucionar el problema. Y también coloque cache_cred en la rama de error cachefiles_add_cache() para evitar pérdidas de memoria. • https://git.kernel.org/stable/c/9ae326a69004dea8af2dae4fde58de27db700a8d https://git.kernel.org/stable/c/cb5466783793e66272624cf71925ae1d1ba32083 https://git.kernel.org/stable/c/037d5a949b0455540ef9aab34c10ddf54b65d285 https://git.kernel.org/stable/c/43eccc5823732ba6daab2511ed32dfc545a666d8 https://git.kernel.org/stable/c/94965be37add0983672e48ecb33cdbda92b62579 https://git.kernel.org/stable/c/8b218e2f0a27a9f09428b1847b4580640b9d1e58 https://git.kernel.org/stable/c/38e921616320d159336b0ffadb09e9fb4945c7c3 https://git.kernel.org/stable/c/9cac69912052a4def571fedf1cb9bb4ec • CWE-402: Transmission of Private Resources into a New Sphere ('Resource Leak') •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26839 – IB/hfi1: Fix a memleak in init_credit_return
https://notcve.org/view.php?id=CVE-2024-26839
In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix a memleak in init_credit_return When dma_alloc_coherent fails to allocate dd->cr_base[i].va, init_credit_return should deallocate dd->cr_base and dd->cr_base[i] that allocated before. Or those resources would be never freed and a memleak is triggered. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: IB/hfi1: corrige una fuga de mem en init_credit_return Cuando dma_alloc_coherent no puede asignar dd->cr_base[i].va, init_credit_return debería desasignar dd->cr_base y dd->cr_base[i]. ] el asignado antes. O esos recursos nunca se liberarían y se desencadenaría una fuga de memoria. • https://git.kernel.org/stable/c/7724105686e718ac476a6ad3304fea2fbcfcffde https://git.kernel.org/stable/c/2e4f9f20b32658ef3724aa46f7aef4908d2609e3 https://git.kernel.org/stable/c/cecfb90cf71d91e9efebd68b9e9b84661b277cc8 https://git.kernel.org/stable/c/3fa240bb6b2dbb3e7a3ee1440a4889cbb6207eb7 https://git.kernel.org/stable/c/52de5805c147137205662af89ed7e083d656ae25 https://git.kernel.org/stable/c/f0d857ce31a6bc7a82afcdbadb8f7417d482604b https://git.kernel.org/stable/c/b41d0ade0398007fb746213f09903d52a920e896 https://git.kernel.org/stable/c/8412c86e89cc78d8b513cb25cf2157a2a •
CVSS: 4.4EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26838 – RDMA/irdma: Fix KASAN issue with tasklet
https://notcve.org/view.php?id=CVE-2024-26838
In the Linux kernel, the following vulnerability has been resolved: RDMA/irdma: Fix KASAN issue with tasklet KASAN testing revealed the following issue assocated with freeing an IRQ. [50006.466686] Call Trace: [50006.466691] <IRQ> [50006.489538] dump_stack+0x5c/0x80 [50006.493475] print_address_description.constprop.6+0x1a/0x150 [50006.499872] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.505742] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.511644] kasan_report.cold.11+0x7f/0x118 [50006.516572] ? irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.522473] irdma_sc_process_ceq+0x483/0x790 [irdma] [50006.528232] irdma_process_ceq+0xb2/0x400 [irdma] [50006.533601] ? irdma_hw_flush_wqes_callback+0x370/0x370 [irdma] [50006.540298] irdma_ceq_dpc+0x44/0x100 [irdma] [50006.545306] tasklet_action_common.isra.14+0x148/0x2c0 [50006.551096] __do_softirq+0x1d0/0xaf8 [50006.555396] irq_exit_rcu+0x219/0x260 [50006.559670] irq_exit+0xa/0x20 [50006.563320] smp_apic_timer_interrupt+0x1bf/0x690 [50006.568645] apic_timer_interrupt+0xf/0x20 [50006.573341] </IRQ> The issue is that a tasklet could be pending on another core racing the delete of the irq. Fix by insuring any scheduled tasklet is killed after deleting the irq. • https://git.kernel.org/stable/c/44d9e52977a1b90b0db1c7f8b197c218e9226520 https://git.kernel.org/stable/c/635d79aa477f9912e602feb5498bdd51fb9cb824 https://git.kernel.org/stable/c/b2e4a5266e3d133b4c7f0e43bf40d13ce14fd1aa https://git.kernel.org/stable/c/c6f1ca235f68b22b3e691b2ea87ac285e5946848 https://git.kernel.org/stable/c/0ae8ad0013978f7471f22bcf45b027393e87f5dc https://git.kernel.org/stable/c/bd97cea7b18a0a553773af806dfbfac27a7c4acb https://access.redhat.com/security/cve/CVE-2024-26838 https://bugzilla.redhat.com/show_bug.cgi?id=2275578 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-26837 – net: bridge: switchdev: Skip MDB replays of deferred events on offload
https://notcve.org/view.php?id=CVE-2024-26837
In the Linux kernel, the following vulnerability has been resolved: net: bridge: switchdev: Skip MDB replays of deferred events on offload Before this change, generation of the list of MDB events to replay would race against the creation of new group memberships, either from the IGMP/MLD snooping logic or from user configuration. While new memberships are immediately visible to walkers of br->mdb_list, the notification of their existence to switchdev event subscribers is deferred until a later point in time. So if a replay list was generated during a time that overlapped with such a window, it would also contain a replay of the not-yet-delivered event. The driver would thus receive two copies of what the bridge internally considered to be one single event. On destruction of the bridge, only a single membership deletion event was therefore sent. As a consequence of this, drivers which reference count memberships (at least DSA), would be left with orphan groups in their hardware database when the bridge was destroyed. This is only an issue when replaying additions. While deletion events may still be pending on the deferred queue, they will already have been removed from br->mdb_list, so no duplicates can be generated in that scenario. To a user this meant that old group memberships, from a bridge in which a port was previously attached, could be reanimated (in hardware) when the port joined a new bridge, without the new bridge's knowledge. For example, on an mv88e6xxx system, create a snooping bridge and immediately add a port to it: root@infix-06-0b-00:~$ ip link add dev br0 up type bridge mcast_snooping 1 && \ > ip link set dev x3 up master br0 And then destroy the bridge: root@infix-06-0b-00:~$ ip link del dev br0 root@infix-06-0b-00:~$ mvls atu ADDRESS FID STATE Q F 0 1 2 3 4 5 6 7 8 9 a DEV:0 Marvell 88E6393X 33:33:00:00:00:6a 1 static - - 0 . . . . . . . . . . 33:33:ff:87:e4:3f 1 static - - 0 . . . . . . . . . . ff:ff:ff:ff:ff:ff 1 static - - 0 1 2 3 4 5 6 7 8 9 a root@infix-06-0b-00:~$ The two IPv6 groups remain in the hardware database because the port (x3) is notified of the host's membership twice: once via the original event and once via a replay. • https://git.kernel.org/stable/c/4f2673b3a2b6246729a1ff13b8945a040839dbd3 https://git.kernel.org/stable/c/2d5b4b3376fa146a23917b8577064906d643925f https://git.kernel.org/stable/c/603be95437e7fd85ba694e75918067fb9e7754db https://git.kernel.org/stable/c/e0b4c5b1d760008f1dd18c07c35af0442e54f9c8 https://git.kernel.org/stable/c/dc489f86257cab5056e747344f17a164f63bff4b https://access.redhat.com/security/cve/CVE-2024-26837 https://bugzilla.redhat.com/show_bug.cgi?id=2275580 • CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') •