CVSS: 7.0EPSS: 0%CPEs: 4EXPL: 0CVE-2024-38581 – drm/amdgpu/mes: fix use-after-free issue
https://notcve.org/view.php?id=CVE-2024-38581
In the Linux kernel, the following vulnerability has been resolved: drm/amdgpu/mes: fix use-after-free issue Delete fence fallback timer to fix the ramdom use-after-free issue. v2: move to amdgpu_mes.c En el kernel de Linux, se resolvió la siguiente vulnerabilidad: drm/amdgpu/mes: soluciona el problema de use-after-free. Elimina el temporizador de reserva de valla para solucionar el problema de use-after-free. v2: pasar a amdgpu_mes.c A flaw was found in the Linux kernel. This issue is due to a possible use-after-free in drivers/gpu/drm/amd/amdgpu/amdgpu_mes.c. • https://git.kernel.org/stable/c/70b1bf6d9edc8692d241f59a65f073aec6d501de https://git.kernel.org/stable/c/39cfce75168c11421d70b8c0c65f6133edccb82a https://git.kernel.org/stable/c/0f98c144c15c8fc0f3176c994bd4e727ef718a5c https://git.kernel.org/stable/c/948255282074d9367e01908b3f5dcf8c10fc9c3d https://access.redhat.com/security/cve/CVE-2024-38581 https://bugzilla.redhat.com/show_bug.cgi?id=2293408 •
CVSS: 3.3EPSS: 0%CPEs: 5EXPL: 0CVE-2024-38580 – epoll: be better about file lifetimes
https://notcve.org/view.php?id=CVE-2024-38580
In the Linux kernel, the following vulnerability has been resolved: epoll: be better about file lifetimes epoll can call out to vfs_poll() with a file pointer that may race with the last 'fput()'. That would make f_count go down to zero, and while the ep->mtx locking means that the resulting file pointer tear-down will be blocked until the poll returns, it means that f_count is already dead, and any use of it won't actually get a reference to the file any more: it's dead regardless. Make sure we have a valid ref on the file pointer before we call down to vfs_poll() from the epoll routines. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: epoll: mejore la duración de los archivos epoll puede llamar a vfs_poll() con un puntero de archivo que puede competir con el último 'fput()'. Eso haría que f_count bajara a cero, y aunque el bloqueo ep->mtx significa que el desmontaje del puntero del archivo resultante se bloqueará hasta que regrese la encuesta, significa que f_count ya está muerto y no se podrá utilizar. De hecho, ya no obtengo una referencia al archivo: está muerto de todos modos. • https://git.kernel.org/stable/c/cbfd1088e24ec4c1199756a37cb8e4cd0a4b016e https://git.kernel.org/stable/c/559214eb4e5c3d05e69428af2fae2691ba1eb784 https://git.kernel.org/stable/c/4f65f4defe4e23659275ce5153541cd4f76ce2d2 https://git.kernel.org/stable/c/16e3182f6322575eb7c12e728ad3c7986a189d5d https://git.kernel.org/stable/c/4efaa5acf0a1d2b5947f98abb3acf8bfd966422b https://access.redhat.com/security/cve/CVE-2024-38580 https://bugzilla.redhat.com/show_bug.cgi?id=2293412 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38578 – ecryptfs: Fix buffer size for tag 66 packet
https://notcve.org/view.php?id=CVE-2024-38578
In the Linux kernel, the following vulnerability has been resolved: ecryptfs: Fix buffer size for tag 66 packet The 'TAG 66 Packet Format' description is missing the cipher code and checksum fields that are packed into the message packet. As a result, the buffer allocated for the packet is 3 bytes too small and write_tag_66_packet() will write up to 3 bytes past the end of the buffer. Fix this by increasing the size of the allocation so the whole packet will always fit in the buffer. This fixes the below kasan slab-out-of-bounds bug: BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0 Write of size 1 at addr ffff88800afbb2a5 by task touch/181 CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014 Call Trace: <TASK> dump_stack_lvl+0x4c/0x70 print_report+0xc5/0x610 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 ? kasan_complete_mode_report_info+0x44/0x210 ? ecryptfs_generate_key_packet_set+0x7d6/0xde0 kasan_report+0xc2/0x110 ? • https://git.kernel.org/stable/c/dddfa461fc8951f9b5f951c13565b6cac678635a https://git.kernel.org/stable/c/1c125b9287e58f364d82174efb167414b92b11f1 https://git.kernel.org/stable/c/235b85981051cd68fc215fd32a81c6f116bfc4df https://git.kernel.org/stable/c/edbfc42ab080e78c6907d40a42c9d10b69e445c1 https://git.kernel.org/stable/c/12db25a54ce6bb22b0af28010fff53ef9cb3fe93 https://git.kernel.org/stable/c/0d0f8ba042af16519f1ef7dd10463a33b21b677c https://git.kernel.org/stable/c/2ed750b7ae1b5dc72896d7dd114c419afd3d1910 https://git.kernel.org/stable/c/a20f09452e2f58f761d11ad7b96b5c894 •
CVSS: 7.1EPSS: 0%CPEs: 9EXPL: 0CVE-2024-38538 – net: bridge: xmit: make sure we have at least eth header len bytes
https://notcve.org/view.php?id=CVE-2024-38538
In the Linux kernel, the following vulnerability has been resolved: net: bridge: xmit: make sure we have at least eth header len bytes syzbot triggered an uninit value[1] error in bridge device's xmit path by sending a short (less than ETH_HLEN bytes) skb. To fix it check if we can actually pull that amount instead of assuming. Tested with dropwatch: drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3) origin: software timestamp: Mon May 13 11:31:53 2024 778214037 nsec protocol: 0x88a8 length: 2 original length: 2 drop reason: PKT_TOO_SMALL [1] BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [inline] netdev_start_xmit include/linux/netdevice.h:4917 [inline] xmit_one net/core/dev.c:3531 [inline] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [inline] __bpf_tx_skb net/core/filter.c:2136 [inline] __bpf_redirect_common net/core/filter.c:2180 [inline] __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187 ____bpf_clone_redirect net/core/filter.c:2460 [inline] bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline] __bpf_prog_run include/linux/filter.h:657 [inline] bpf_prog_run include/linux/filter.h:664 [inline] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline] __se_sys_bpf kernel/bpf/syscall.c:5765 [inline] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x77/0x7f En el kernel de Linux, se resolvió la siguiente vulnerabilidad: net: bridge: xmit: asegúrese de tener al menos el encabezado eth len bytes syzbot desencadenó un error de valor uninit[1] en la ruta xmit del dispositivo puente al enviar un mensaje corto (menos de ETH_HLEN bytes) skb. Para solucionarlo, compruebe si realmente podemos retirar esa cantidad en lugar de suponerla. Probado con dropwatch: soltar en: br_dev_xmit+0xb93/0x12d0 [puente] (0xffffffffc06739b3) origen: marca de tiempo del software: lunes 13 de mayo 11:31:53 2024 778214037 protocolo nsec: 0x88a8 longitud: 2 longitud original: 2 motivo de caída: PKT_TOO_SMALL [1 ] ERROR: KMSAN: valor uninit en br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65 __netdev_start_xmit include/linux/netdevice.h:4903 [en línea] netdev_start_xmit include/linux/netdevice.h:4917 [en línea] xmit_one net/core/dev.c:3531 [en línea] dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547 __dev_queue_xmit+0x34db/0x5350 net/core/dev .c:4341 dev_queue_xmit include/linux/netdevice.h:3091 [en línea] __bpf_tx_skb net/core/filter.c:2136 [en línea] __bpf_redirect_common net/core/filter.c:2180 [en línea] __bpf_redirect+0x14a6/0x1620 net/ Core/Filter.C: 2187 ____BPF_CLONE_REDIRECT NET/CORE/FILTRO.C: 2460 [Inline] BPF_CLONE_REDIRECT+0x328/0x470 NET/Core/Filter.c: 2432 ___ BPF_PROG_RUN+0X13FE/0XE0F0 KERNEL/BPF/BPF/CORE. 0xb5/0xe0 kernel/bpf/core.c:2238 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [en línea] __bpf_prog_run include/linux/filter.h:657 [en línea] bpf_prog_run include/linux/filter.h:664 [en línea ] bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269 pf+0x6aa/0xd90 núcleo/ bpf/syscall.c:5678 __do_sys_bpf kernel/bpf/syscall.c:5767 [en línea] __se_sys_bpf kernel/bpf/syscall.c:5765 [en línea] __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765 ys_call+0x96b /0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322 do_syscall_x64 arch/x86/entry/common.c:52 [en línea] do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83 Entry_SYSCALL_64_after_hwframe+ 0x77/0x7f • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/3e01fc3c66e65d9afe98f1489047a1b2dd8741ca https://git.kernel.org/stable/c/b2b7c43cd32080221bb233741bd6011983fe7c11 https://git.kernel.org/stable/c/82090f94c723dab724b1c32db406091d40448a17 https://git.kernel.org/stable/c/c964429ef53f42098a6545a5dabeb1441c1e821d https://git.kernel.org/stable/c/28126b83f86ab9cc7936029c2dff845d3dcedba2 https://git.kernel.org/stable/c/1abb371147905ba250b4cc0230c4be7e90bea4d5 https://git.kernel.org/stable/c/f482fd4ce919836a49012b2d31b00fc36 • CWE-99: Improper Control of Resource Identifiers ('Resource Injection') •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-36969 – drm/amd/display: Fix division by zero in setup_dsc_config
https://notcve.org/view.php?id=CVE-2024-36969
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix division by zero in setup_dsc_config When slice_height is 0, the division by slice_height in the calculation of the number of slices will cause a division by zero driver crash. This leaves the kernel in a state that requires a reboot. This patch adds a check to avoid the division by zero. The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor connected via Thunderbolt. The amdgpu driver crashed with this exception when I rebooted the system with the monitor connected. kernel: ? • https://git.kernel.org/stable/c/a32c8f951c8a456c1c251e1dcdf21787f8066445 https://git.kernel.org/stable/c/91402e0e5de9124a3108db7a14163fcf9a6d322f https://git.kernel.org/stable/c/7e4f50dfc98c49b3dc6875a35c3112522fb25639 https://git.kernel.org/stable/c/f187fcbbb8f8bf10c6687f0beae22509369f7563 https://git.kernel.org/stable/c/308de6be0c9c7ba36915c0d398e771725c0ea911 https://git.kernel.org/stable/c/130afc8a886183a94cf6eab7d24f300014ff87ba • CWE-369: Divide By Zero •