CVSS: 5.3EPSS: 0%CPEs: 5EXPL: 0CVE-2024-26731 – bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready()
https://notcve.org/view.php?id=CVE-2024-26731
In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Fix NULL pointer dereference in sk_psock_verdict_data_ready() syzbot reported the following NULL pointer dereference issue [1]: BUG: kernel NULL pointer dereference, address: 0000000000000000 [...] RIP: 0010:0x0 [...] Call Trace: <TASK> sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230 unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293 sock_sendmsg_nosec net/socket.c:730 [inline] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [inline] __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667 do_syscall_64+0xf9/0x240 entry_SYSCALL_64_after_hwframe+0x6f/0x77 If sk_psock_verdict_data_ready() and sk_psock_stop_verdict() are called concurrently, psock->saved_data_ready can be NULL, causing the above issue. This patch fixes this issue by calling the appropriate data ready function using the sk_psock_data_ready() helper and protecting it from concurrency with sk->sk_callback_lock. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: bpf, sockmap: corrigió la desreferencia del puntero NULL en sk_psock_verdict_data_ready() syzbot informó el siguiente problema de desreferencia del puntero NULL [1]: ERROR: desreferencia del puntero NULL del kernel, dirección: 0000000000000000 [... ] RIP: 0010:0x0 [...] Seguimiento de llamadas: sk_psock_verdict_data_ready+0x232/0x340 net/core/skmsg.c:1230 unix_stream_sendmsg+0x9b4/0x1230 net/unix/af_unix.c:2293 sock_sendmsg_nosec net/socket. c:730 [en línea] __sock_sendmsg+0x221/0x270 net/socket.c:745 ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584 ___sys_sendmsg net/socket.c:2638 [en línea] __sys_sendmsg+0x2b0/0x3a0 net /socket. c:2667 do_syscall_64+0xf9/0x240 Entry_SYSCALL_64_after_hwframe+0x6f/0x77 Si sk_psock_verdict_data_ready() y sk_psock_stop_verdict() se llaman simultáneamente, psock->saved_data_ready puede ser NULL, causando el problema anterior. Este parche soluciona este problema llamando a la función de preparación de datos adecuada utilizando el asistente sk_psock_data_ready() y protegiéndola de la concurrencia con sk->sk_callback_lock. • https://git.kernel.org/stable/c/dd628fc697ee59b76bd3877c4bd13f07ccc3776f https://git.kernel.org/stable/c/6df7f764cd3cf5a03a4a47b23be47e57e41fcd85 https://git.kernel.org/stable/c/d3cbd7c571446a876aefd8320500300b2c951c58 https://git.kernel.org/stable/c/4588b13abcbd561ec67f5b3c1cb2eff690990a54 https://git.kernel.org/stable/c/9b099ed46dcaf1403c531ff02c3d7400fa37fa26 https://git.kernel.org/stable/c/d61608a4e394f23e0dca099df9eb8e555453d949 https://git.kernel.org/stable/c/4cd12c6065dfcdeba10f49949bffcf383b3952d8 • CWE-476: NULL Pointer Dereference •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26730 – hwmon: (nct6775) Fix access to temperature configuration registers
https://notcve.org/view.php?id=CVE-2024-26730
In the Linux kernel, the following vulnerability has been resolved: hwmon: (nct6775) Fix access to temperature configuration registers The number of temperature configuration registers does not always match the total number of temperature registers. This can result in access errors reported if KASAN is enabled. BUG: KASAN: global-out-of-bounds in nct6775_probe+0x5654/0x6fe9 nct6775_core En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: hwmon: (nct6775) Arreglar el acceso a los registros de configuración de temperatura El número de registros de configuración de temperatura no siempre coincide con el número total de registros de temperatura. Esto puede resultar en errores de acceso reportados si KASAN está habilitado. ERROR: KASAN: global fuera de los límites en nct6775_probe+0x5654/0x6fe9 nct6775_core • https://git.kernel.org/stable/c/b7f1f7b2523a6a4382f12fe953380b847b80e09d https://git.kernel.org/stable/c/f006c45a3ea424f8f6c8e4b9283bc245ce2a4d0f https://git.kernel.org/stable/c/c196387820c9214c5ceaff56d77303c82514b8b1 https://git.kernel.org/stable/c/d56e460e19ea8382f813eb489730248ec8d7eb73 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52641 – fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame()
https://notcve.org/view.php?id=CVE-2023-52641
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Add NULL ptr dereference checking at the end of attr_allocate_frame() It is preferable to exit through the out: label because internal debugging functions are located there. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Agregar verificación de desreferencia de ptr NULL al final de attr_allocate_frame() Es preferible salir por la etiqueta out: porque las funciones de depuración interna se encuentran allí. • https://git.kernel.org/stable/c/ee8db6475cb15c8122855f72ad4cfa5375af6a7b https://git.kernel.org/stable/c/50545eb6cd5f7ff852a01fa29b7372524ef948cc https://git.kernel.org/stable/c/947c3f3d31ea185ddc8e7f198873f17d36deb24c https://git.kernel.org/stable/c/847b68f58c212f0439c5a8101b3841f32caffccd https://git.kernel.org/stable/c/aaab47f204aaf47838241d57bf8662c8840de60a •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2023-52640 – fs/ntfs3: Fix oob in ntfs_listxattr
https://notcve.org/view.php?id=CVE-2023-52640
In the Linux kernel, the following vulnerability has been resolved: fs/ntfs3: Fix oob in ntfs_listxattr The length of name cannot exceed the space occupied by ea. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: fs/ntfs3: Se corrige oob en ntfs_listxattr La longitud del nombre no puede exceder el espacio ocupado por ea. • https://git.kernel.org/stable/c/a585faf0591548fe0920641950ebfa8a6eefe1cd https://git.kernel.org/stable/c/6ed6cdbe88334ca3430c5aee7754dc4597498dfb https://git.kernel.org/stable/c/52fff5799e3d1b5803ecd2f5f19c13c65f4f7b23 https://git.kernel.org/stable/c/0830c5cf19bdec50d0ede4755ddc463663deb21c https://git.kernel.org/stable/c/731ab1f9828800df871c5a7ab9ffe965317d3f15 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26727 – btrfs: do not ASSERT() if the newly created subvolume already got read
https://notcve.org/view.php?id=CVE-2024-26727
In the Linux kernel, the following vulnerability has been resolved: btrfs: do not ASSERT() if the newly created subvolume already got read [BUG] There is a syzbot crash, triggered by the ASSERT() during subvolume creation: assertion failed: !anon_dev, in fs/btrfs/disk-io.c:1319 ------------[ cut here ]------------ kernel BUG at fs/btrfs/disk-io.c:1319! invalid opcode: 0000 [#1] PREEMPT SMP KASAN RIP: 0010:btrfs_get_root_ref.part.0+0x9aa/0xa60 <TASK> btrfs_get_new_fs_root+0xd3/0xf0 create_subvol+0xd02/0x1650 btrfs_mksubvol+0xe95/0x12b0 __btrfs_ioctl_snap_create+0x2f9/0x4f0 btrfs_ioctl_snap_create+0x16b/0x200 btrfs_ioctl+0x35f0/0x5cf0 __x64_sys_ioctl+0x19d/0x210 do_syscall_64+0x3f/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b ---[ end trace 0000000000000000 ]--- [CAUSE] During create_subvol(), after inserting root item for the newly created subvolume, we would trigger btrfs_get_new_fs_root() to get the btrfs_root of that subvolume. The idea here is, we have preallocated an anonymous device number for the subvolume, thus we can assign it to the new subvolume. But there is really nothing preventing things like backref walk to read the new subvolume. If that happens before we call btrfs_get_new_fs_root(), the subvolume would be read out, with a new anonymous device number assigned already. In that case, we would trigger ASSERT(), as we really expect no one to read out that subvolume (which is not yet accessible from the fs). But things like backref walk is still possible to trigger the read on the subvolume. Thus our assumption on the ASSERT() is not correct in the first place. [FIX] Fix it by removing the ASSERT(), and just free the @anon_dev, reset it to 0, and continue. If the subvolume tree is read out by something else, it should have already get a new anon_dev assigned thus we only need to free the preallocated one. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: btrfs: no haga ASSERT() si el subvolumen recién creado ya se leyó [ERROR] Hay un bloqueo del syzbot, provocado por ASSERT() durante la creación del subvolumen: la aserción falló: ! anon_dev, en fs/btrfs/disk-io.c:1319 ------------[ cortar aquí ]------------ ERROR del kernel en fs/btrfs/disk -io.c:1319! • https://git.kernel.org/stable/c/2dfb1e43f57dd3aeaa66f7cf05d068db2d4c8788 https://git.kernel.org/stable/c/917d608fe375041eb7f29befa6a6d7fd3cf32dde https://git.kernel.org/stable/c/3f5d47eb163bceb1b9e613c9003bae5fefc0046f https://git.kernel.org/stable/c/e31546b0f34af21738c4ceac47d662c00ee6382f https://git.kernel.org/stable/c/66b317a2fc45b2ef66527ee3f8fa08fb5beab88d https://git.kernel.org/stable/c/833775656d447c545133a744a0ed1e189ce61430 https://git.kernel.org/stable/c/5a172344bfdabb46458e03708735d7b1a918c468 https://git.kernel.org/stable/c/e03ee2fe873eb68c1f9ba5112fee70303 •