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/dd08ebf6c3525a7ea2186e636df064ea47281987 https://git.kernel.org/stable/c/bcb5be3421705e682b0b32073ad627056d6bc2a2 https://git.kernel.org/stable/c/6c10ba06bb1b48acce6d4d9c1e33beb9954f1788 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 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/ecc2aeeaa08a355d84d3ca9c3d2512399a194f29 https://git.kernel.org/stable/c/41f6f64e6999a837048b1bd13a2f8742964eca6b •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50088 – btrfs: fix uninitialized pointer free in add_inode_ref()
https://notcve.org/view.php?id=CVE-2024-50088
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free in add_inode_ref() The add_inode_ref() function does not initialize the "name" struct when it is declared. If any of the following calls to "read_one_inode() returns NULL, dir = read_one_inode(root, parent_objectid); if (!dir) { ret = -ENOENT; goto out; } inode = read_one_inode(root, inode_objectid); if (!inode) { ret = -EIO; goto out; } then "name.name" would be freed on "out" before being initialized. out: ... kfree(name.name); This issue was reported by Coverity with CID 1526744. • https://git.kernel.org/stable/c/1cf474cd474bc5d3ef63086ffd009a87a5b7bb2e https://git.kernel.org/stable/c/e43eec81c5167b655b72c781b0e75e62a05e415e https://git.kernel.org/stable/c/12cf028381aa19bc38465341512c280256e8d82d https://git.kernel.org/stable/c/e11ce03b58743bf1e096c48fcaa7e6f08eb75dfa https://git.kernel.org/stable/c/a941f3d5b1469c60a7e70e775584f110b47e0d16 https://git.kernel.org/stable/c/66691c6e2f18d2aa4b22ffb624b9bdc97e9979e4 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50087 – btrfs: fix uninitialized pointer free on read_alloc_one_name() error
https://notcve.org/view.php?id=CVE-2024-50087
In the Linux kernel, the following vulnerability has been resolved: btrfs: fix uninitialized pointer free on read_alloc_one_name() error The function read_alloc_one_name() does not initialize the name field of the passed fscrypt_str struct if kmalloc fails to allocate the corresponding buffer. Thus, it is not guaranteed that fscrypt_str.name is initialized when freeing it. This is a follow-up to the linked patch that fixes the remaining instances of the bug introduced by commit e43eec81c516 ("btrfs: use struct qstr instead of name and namelen pairs"). • https://git.kernel.org/stable/c/1cf474cd474bc5d3ef63086ffd009a87a5b7bb2e https://git.kernel.org/stable/c/e43eec81c5167b655b72c781b0e75e62a05e415e https://git.kernel.org/stable/c/b37de9491f140a0ff125c27dd1050185c3accbc1 https://git.kernel.org/stable/c/7fc7c47b9ba0cf2d192f2117a64b24881b0b577f https://git.kernel.org/stable/c/1ec28de5e476913ae51f909660b4447eddb28838 https://git.kernel.org/stable/c/2ab5e243c2266c841e0f6904fad1514b18eaf510 •
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/0626e6641f6b467447c81dd7678a69c66f7746cf 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 •