CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-50090 – drm/xe/oa: Fix overflow in oa batch buffer
https://notcve.org/view.php?id=CVE-2024-50090
In the Linux kernel, the following vulnerability has been resolved: drm/xe/oa: Fix overflow in oa batch buffer By default xe_bb_create_job() appends a MI_BATCH_BUFFER_END to batch buffer, this is not a problem if batch buffer is only used once but oa reuses the batch buffer for the same metric and at each call it appends a MI_BATCH_BUFFER_END, printing the warning below and then overflowing. [ 381.072016] ------------[ cut here ]------------ [ 381.072019] xe 0000:00:02.0: [drm] Assertion `bb->len * 4 + bb_prefetch(q->gt) <= size` failed! platform: LUNARLAKE subplatform: 1 graphics: Xe2_LPG / Xe2_HPG 20.04 step B0 media: Xe2_LPM / Xe2_HPM 20.00 step B0 tile: 0 VRAM 0 B GT: 0 type 1 So here checking if batch buffer already have MI_BATCH_BUFFER_END if not append it. v2: - simply fix, suggestion from Ashutosh (cherry picked from commit 9ba0e0f30ca42a98af3689460063edfb6315718a) En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: drm/xe/oa: Corregir desbordamiento en el búfer por lotes de oa. De manera predeterminada, xe_bb_create_job() agrega un MI_BATCH_BUFFER_END al buffer por lotes, esto no es un problema si el buffer por lotes solo se usa una vez, pero oa reutiliza el búfer por lotes para la misma métrica y en cada llamada agrega un MI_BATCH_BUFFER_END, imprimiendo la advertencia a continuación y luego desbordándose. [ 381.072016] ------------[ cortar aquí ]------------ [ 381.072019] xe 0000:00:02.0: [drm] ¡La afirmación `bb->len * 4 + bb_prefetch(q->gt) <= size` falló! Plataforma: LUNARLAKE Subplataforma: 1 Gráficos: Xe2_LPG / Xe2_HPG 20.04 Paso B0 Medios: Xe2_LPM / Xe2_HPM 20.00 Paso B0 Mosaico: 0 VRAM 0 B GT: 0 Tipo 1 Aquí se verifica si el buffer de lote ya tiene MI_BATCH_BUFFER_END si no, se agrega. v2: - simplemente se arregla, sugerencia de Ashutosh (seleccionada del commit 9ba0e0f30ca42a98af3689460063edfb6315718a) • https://git.kernel.org/stable/c/bcb5be3421705e682b0b32073ad627056d6bc2a2 https://git.kernel.org/stable/c/6c10ba06bb1b48acce6d4d9c1e33beb9954f1788 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-50089 – unicode: Don't special case ignorable code points
https://notcve.org/view.php?id=CVE-2024-50089
In the Linux kernel, the following vulnerability has been resolved: unicode: Don't special case ignorable code points We don't need to handle them separately. Instead, just let them decompose/casefold to themselves. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: unicode: No aplicar mayúsculas y minúsculas especiales a los puntos de código que se puedan ignorar. No necesitamos manejarlos por separado. En su lugar, simplemente dejamos que se descompongan o se conviertan en mayúsculas y minúsculas por sí mismos. • https://git.kernel.org/stable/c/18b5f47e7da46d3a0d7331e48befcaf151ed2ddf https://git.kernel.org/stable/c/39fffca572844d733b137a0ff9eacd67b9b0c8e3 https://git.kernel.org/stable/c/651b954cd8d5b0a358ceb47c93876bb6201224e4 https://git.kernel.org/stable/c/21526498d25e54bda3c650f756493d63fd9131b7 https://git.kernel.org/stable/c/ac20736861f3c9c8e0a78273a4c57e9bcb0d8cc6 https://git.kernel.org/stable/c/876d3577a5b353e482d9228d45fa0d82bf1af53a https://git.kernel.org/stable/c/5c26d2f1d3f5e4be3e196526bead29ecb139cf91 •
CVSS: -EPSS: 0%CPEs: 1EXPL: 0CVE-2023-52920 – bpf: support non-r10 register spill/fill to/from stack in precision tracking
https://notcve.org/view.php?id=CVE-2023-52920
In the Linux kernel, the following vulnerability has been resolved: bpf: support non-r10 register spill/fill to/from stack in precision tracking Use instruction (jump) history to record instructions that performed register spill/fill to/from stack, regardless if this was done through read-only r10 register, or any other register after copying r10 into it *and* potentially adjusting offset. To make this work reliably, we push extra per-instruction flags into instruction history, encoding stack slot index (spi) and stack frame number in extra 10 bit flags we take away from prev_idx in instruction history. We don't touch idx field for maximum performance, as it's checked most frequently during backtracking. This change removes basically the last remaining practical limitation of precision backtracking logic in BPF verifier. It fixes known deficiencies, but also opens up new opportunities to reduce number of verified states, explored in the subsequent patches. There are only three differences in selftests' BPF object files according to veristat, all in the positive direction (less states). File Program Insns (A) Insns (B) Insns (DIFF) States (A) States (B) States (DIFF) -------------------------------------- ------------- --------- --------- ------------- ---------- ---------- ------------- test_cls_redirect_dynptr.bpf.linked3.o cls_redirect 2987 2864 -123 (-4.12%) 240 231 -9 (-3.75%) xdp_synproxy_kern.bpf.linked3.o syncookie_tc 82848 82661 -187 (-0.23%) 5107 5073 -34 (-0.67%) xdp_synproxy_kern.bpf.linked3.o syncookie_xdp 85116 84964 -152 (-0.18%) 5162 5130 -32 (-0.62%) Note, I avoided renaming jmp_history to more generic insn_hist to minimize number of lines changed and potential merge conflicts between bpf and bpf-next trees. Notice also cur_hist_entry pointer reset to NULL at the beginning of instruction verification loop. This pointer avoids the problem of relying on last jump history entry's insn_idx to determine whether we already have entry for current instruction or not. It can happen that we added jump history entry because current instruction is_jmp_point(), but also we need to add instruction flags for stack access. • https://git.kernel.org/stable/c/41f6f64e6999a837048b1bd13a2f8742964eca6b •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-50086 – ksmbd: fix user-after-free from session log off
https://notcve.org/view.php?id=CVE-2024-50086
In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix user-after-free from session log off There is racy issue between smb2 session log off and smb2 session setup. It will cause user-after-free from session log off. This add session_lock when setting SMB2_SESSION_EXPIRED and referece count to session struct not to free session while it is being used. • https://git.kernel.org/stable/c/0f62358ce85b2d4c949ef1b648be01b29cec667a https://git.kernel.org/stable/c/a9839c37fd813b432988f58a9d9dd59253d3eb2c https://git.kernel.org/stable/c/5511999e9615e4318e9142d23b29bd1597befc08 https://git.kernel.org/stable/c/ee371898b53a9b9b51c02d22a8c31bfb86d45f0d https://git.kernel.org/stable/c/7aa8804c0b67b3cb263a472d17f2cb50d7f1a930 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50073 – tty: n_gsm: Fix use-after-free in gsm_cleanup_mux
https://notcve.org/view.php?id=CVE-2024-50073
In the Linux kernel, the following vulnerability has been resolved: tty: n_gsm: Fix use-after-free in gsm_cleanup_mux BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace: <TASK> gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm] __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389 update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500 __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846 __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161 gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107 __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm] ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195 ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79 __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338 __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805 tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 Allocated by task 65: gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm] gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm] gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm] gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm] tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391 tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39 flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445 process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229 worker_thread+0x3dc/0x950 kernel/workqueue.c:3391 kthread+0x2a3/0x370 kernel/kthread.c:389 ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257 Freed by task 3367: kfree+0x126/0x420 mm/slub.c:4580 gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm] tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818 [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock. • https://git.kernel.org/stable/c/bf171b5e86e41de4c1cf32fb7aefa275c3d7de49 https://git.kernel.org/stable/c/c29f192e0d44cc1cbaf698fa1ff198f63556691a https://git.kernel.org/stable/c/0eec592c6a7460ba795d7de29f3dc95cb5422e62 https://git.kernel.org/stable/c/9462f4ca56e7d2430fdb6dcc8498244acbfc4489 •