CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50140 – sched/core: Disable page allocation in task_tick_mm_cid()
https://notcve.org/view.php?id=CVE-2024-50140
In the Linux kernel, the following vulnerability has been resolved: sched/core: Disable page allocation in task_tick_mm_cid() With KASAN and PREEMPT_RT enabled, calling task_work_add() in task_tick_mm_cid() may cause the following splat. [ 63.696416] BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 [ 63.696416] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 610, name: modprobe [ 63.696416] preempt_count: 10001, expected: 0 [ 63.696416] RCU nest depth: 1, expected: 1 This problem is caused by the following call trace. sched_tick() [ acquire rq->__lock ] -> task_tick_mm_cid() -> task_work_add() -> __kasan_record_aux_stack() -> kasan_save_stack() -> stack_depot_save_flags() -> alloc_pages_mpol_noprof() -> __alloc_pages_noprof() -> get_page_from_freelist() -> rmqueue() -> rmqueue_pcplist() -> __rmqueue_pcplist() -> rmqueue_bulk() -> rt_spin_lock() The rq lock is a raw_spinlock_t. We can't sleep while holding it. IOW, we can't call alloc_pages() in stack_depot_save_flags(). The task_tick_mm_cid() function with its task_work_add() call was introduced by commit 223baf9d17f2 ("sched: Fix performance regression introduced by mm_cid") in v6.4 kernel. Fortunately, there is a kasan_record_aux_stack_noalloc() variant that calls stack_depot_save_flags() while not allowing it to allocate new pages. To allow task_tick_mm_cid() to use task_work without page allocation, a new TWAF_NO_ALLOC flag is added to enable calling kasan_record_aux_stack_noalloc() instead of kasan_record_aux_stack() if set. The task_tick_mm_cid() function is modified to add this new flag. The possible downside is the missing stack trace in a KASAN report due to new page allocation required when task_work_add_noallloc() is called which should be rare. • https://git.kernel.org/stable/c/223baf9d17f25e2608dbdff7232c095c1e612268 https://git.kernel.org/stable/c/509c29d0d26f68a6f6d0a05cb1a89725237e2b87 https://git.kernel.org/stable/c/ce0241ef83eed55f675376e8a3605d23de53d875 https://git.kernel.org/stable/c/73ab05aa46b02d96509cb029a8d04fca7bbde8c7 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50139 – KVM: arm64: Fix shift-out-of-bounds bug
https://notcve.org/view.php?id=CVE-2024-50139
In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: Fix shift-out-of-bounds bug Fix a shift-out-of-bounds bug reported by UBSAN when running VM with MTE enabled host kernel. UBSAN: shift-out-of-bounds in arch/arm64/kvm/sys_regs.c:1988:14 shift exponent 33 is too large for 32-bit type 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm Not tainted 6.12.0-rc2 #34 Hardware name: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 10/14/2024 Call trace: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x74/0x90 dump_stack+0x18/0x28 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 reset_clidr+0x10c/0x1c8 kvm_reset_sys_regs+0x50/0x1c8 kvm_reset_vcpu+0xec/0x2b0 __kvm_vcpu_set_target+0x84/0x158 kvm_vcpu_set_target+0x138/0x168 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 kvm_arch_vcpu_ioctl+0x28c/0x4b8 kvm_vcpu_ioctl+0x4bc/0x7a8 __arm64_sys_ioctl+0xb4/0x100 invoke_syscall+0x70/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: KVM: arm64: Corregir error de desplazamiento fuera de los límites Corrige un error de desplazamiento fuera de los límites informado por UBSAN al ejecutar una máquina virtual con un kernel de host habilitado para MTE. UBSAN: desplazamiento fuera de los límites en arch/arm64/kvm/sys_regs.c:1988:14 el exponente de desplazamiento 33 es demasiado grande para el tipo de 32 bits 'int' CPU: 26 UID: 0 PID: 7629 Comm: qemu-kvm No contaminado 6.12.0-rc2 #34 Nombre del hardware: IEI NF5280R7/Mitchell MB, BIOS 00.00. 2024-10-12 09:28:54 14/10/2024 Seguimiento de llamadas: dump_backtrace+0xa0/0x128 show_stack+0x20/0x38 dump_stack_lvl+0x74/0x90 dump_stack+0x18/0x28 __ubsan_handle_shift_out_of_bounds+0xf8/0x1e0 reset_clidr+0x10c/0x1c8 kvm_reset_sys_regs+0x50/0x1c8 kvm_reset_vcpu+0xec/0x2b0 __kvm_vcpu_set_target+0x84/0x158 kvm_vcpu_set_target+0x138/0x168 kvm_arch_vcpu_ioctl_vcpu_init+0x40/0x2b0 kvm_arch_vcpu_ioctl+0x28c/0x4b8 kvm_vcpu_ioctl+0x4bc/0x7a8 __arm64_sys_ioctl+0xb4/0x100 invocar_llamada_al_sistema+0x70/0x100 el0_svc_common.constprop.0+0x48/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x3c/0x158 el0t_64_sync_handler+0x120/0x130 el0t_64_sync+0x194/0x198 • https://git.kernel.org/stable/c/7af0c2534f4c57b16e92dfca8c5f40fa90fbb3f3 https://git.kernel.org/stable/c/04ed2ba07ce73f323052475fbd33d647aca3ff2e https://git.kernel.org/stable/c/4b9e11794d910aa55300debbac5f0adcc42c491a https://git.kernel.org/stable/c/c6c167afa090ea0451f91814e1318755a8fb8bb9 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50138 – bpf: Use raw_spinlock_t in ringbuf
https://notcve.org/view.php?id=CVE-2024-50138
In the Linux kernel, the following vulnerability has been resolved: bpf: Use raw_spinlock_t in ringbuf The function __bpf_ringbuf_reserve is invoked from a tracepoint, which disables preemption. Using spinlock_t in this context can lead to a "sleep in atomic" warning in the RT variant. This issue is illustrated in the example below: BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 556208, name: test_progs preempt_count: 1, expected: 0 RCU nest depth: 1, expected: 1 INFO: lockdep is turned off. Preemption disabled at: [<ffffd33a5c88ea44>] migrate_enable+0xc0/0x39c CPU: 7 PID: 556208 Comm: test_progs Tainted: G Hardware name: Qualcomm SA8775P Ride (DT) Call trace: dump_backtrace+0xac/0x130 show_stack+0x1c/0x30 dump_stack_lvl+0xac/0xe8 dump_stack+0x18/0x30 __might_resched+0x3bc/0x4fc rt_spin_lock+0x8c/0x1a4 __bpf_ringbuf_reserve+0xc4/0x254 bpf_ringbuf_reserve_dynptr+0x5c/0xdc bpf_prog_ac3d15160d62622a_test_read_write+0x104/0x238 trace_call_bpf+0x238/0x774 perf_call_bpf_enter.isra.0+0x104/0x194 perf_syscall_enter+0x2f8/0x510 trace_sys_enter+0x39c/0x564 syscall_trace_enter+0x220/0x3c0 do_el0_svc+0x138/0x1dc el0_svc+0x54/0x130 el0t_64_sync_handler+0x134/0x150 el0t_64_sync+0x17c/0x180 Switch the spinlock to raw_spinlock_t to avoid this error. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: bpf: uso de raw_spinlock_t en ringbuf La función __bpf_ringbuf_reserve se invoca desde un punto de seguimiento, lo que desactiva la preempción. El uso de spinlock_t en este contexto puede provocar una advertencia de "suspensión en atómico" en la variante RT. • https://git.kernel.org/stable/c/457f44363a8894135c85b7a9afd2bd8196db24ab https://git.kernel.org/stable/c/5eb34999d118e69a20dc0c6556f315fcb0a1f8d3 https://git.kernel.org/stable/c/ca30e682e5d6de44d12c4610767811c9a21d59ba https://git.kernel.org/stable/c/8b62645b09f870d70c7910e7550289d444239a46 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50137 – reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC
https://notcve.org/view.php?id=CVE-2024-50137
In the Linux kernel, the following vulnerability has been resolved: reset: starfive: jh71x0: Fix accessing the empty member on JH7110 SoC data->asserted will be NULL on JH7110 SoC since commit 82327b127d41 ("reset: starfive: Add StarFive JH7110 reset driver") was added. Add the judgment condition to avoid errors when calling reset_control_status on JH7110 SoC. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: reset: starfive: jh71x0: Se ha corregido el acceso al miembro vacío en el SoC JH7110. La información data->asserted será NULL en el SoC JH7110 desde que se agregó la confirmación 82327b127d41 ("reset: starfive: Add StarFive JH7110 reset driver"). Se ha agregado la condición de juicio para evitar errores al llamar a reset_control_status en el SoC JH7110. • https://git.kernel.org/stable/c/82327b127d4117e5b867cca945f97a5074aef786 https://git.kernel.org/stable/c/c923f1fb8ae8627322d167b73bb4f978404a05de https://git.kernel.org/stable/c/2cf59663660799ce16f4dfbed97cdceac7a7fa11 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50136 – net/mlx5: Unregister notifier on eswitch init failure
https://notcve.org/view.php?id=CVE-2024-50136
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: Unregister notifier on eswitch init failure It otherwise remains registered and a subsequent attempt at eswitch enabling might trigger warnings of the sort: [ 682.589148] ------------[ cut here ]------------ [ 682.590204] notifier callback eswitch_vport_event [mlx5_core] already registered [ 682.590256] WARNING: CPU: 13 PID: 2660 at kernel/notifier.c:31 notifier_chain_register+0x3e/0x90 [...snipped] [ 682.610052] Call Trace: [ 682.610369] <TASK> [ 682.610663] ? __warn+0x7c/0x110 [ 682.611050] ? notifier_chain_register+0x3e/0x90 [ 682.611556] ? report_bug+0x148/0x170 [ 682.611977] ? handle_bug+0x36/0x70 [ 682.612384] ? • https://git.kernel.org/stable/c/0aa1e83a20f12e9eaad32f72212ebc7fe0c29c95 https://git.kernel.org/stable/c/7624e58a8b3a251e3e5108b32f2183b34453db32 https://git.kernel.org/stable/c/dc426bd9d813aa5754ce35adaa6f97f0585c06fc https://git.kernel.org/stable/c/e58fb7ddbab6635191c26dea1af26b91cce00866 https://git.kernel.org/stable/c/9f2ccb6f3888bec45c00121ee43e4e72423b12c1 https://git.kernel.org/stable/c/599147722c5778c96292e2fbff4103abbdb45b1f https://git.kernel.org/stable/c/1da9cfd6c41c2e6bbe624d0568644e1521c33e12 •