CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2024-26735 – ipv6: sr: fix possible use-after-free and null-ptr-deref
https://notcve.org/view.php?id=CVE-2024-26735
In the Linux kernel, the following vulnerability has been resolved: ipv6: sr: fix possible use-after-free and null-ptr-deref The pernet operations structure for the subsystem must be registered before registering the generic netlink family. En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: ipv6:sr: corrige posible use-after-free y null-ptr-deref La estructura de operaciones pernet para el subsystem debe registrarse antes de registrar la familia netlink genérica. A use-after-free flaw was found in the Linux kernel’s IPv6 protocol functionality. This flaw allows a local user to potentially crash the system. • https://git.kernel.org/stable/c/915d7e5e5930b4f01d0971d93b9b25ed17d221aa https://git.kernel.org/stable/c/953f42934533c151f440cd32390044d2396b87aa https://git.kernel.org/stable/c/82831e3ff76ef09fb184eb93b79a3eb3fb284f1d https://git.kernel.org/stable/c/65c38f23d10ff79feea1e5d50b76dc7af383c1e6 https://git.kernel.org/stable/c/91b020aaa1e59bfb669d34c968e3db3d5416bcee https://git.kernel.org/stable/c/8391b9b651cfdf80ab0f1dc4a489f9d67386e197 https://git.kernel.org/stable/c/9e02973dbc6a91e40aa4f5d87b8c47446fbfce44 https://git.kernel.org/stable/c/02b08db594e8218cfbc0e4680d4331b45 • CWE-416: Use After Free CWE-476: NULL Pointer Dereference •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2024-26733 – arp: Prevent overflow in arp_req_get().
https://notcve.org/view.php?id=CVE-2024-26733
In the Linux kernel, the following vulnerability has been resolved: arp: Prevent overflow in arp_req_get(). syzkaller reported an overflown write in arp_req_get(). [0] When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour entry and copies neigh->ha to struct arpreq.arp_ha.sa_data. The arp_ha here is struct sockaddr, not struct sockaddr_storage, so the sa_data buffer is just 14 bytes. In the splat below, 2 bytes are overflown to the next int field, arp_flags. We initialise the field just after the memcpy(), so it's not a problem. However, when dev->addr_len is greater than 22 (e.g. MAX_ADDR_LEN), arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL) in arp_ioctl() before calling arp_req_get(). To avoid the overflow, let's limit the max length of memcpy(). Note that commit b5f0de6df6dc ("net: dev: Convert sa_data to flexible array in struct sockaddr") just silenced syzkaller. [0]: memcpy: detected field-spanning write (size 16) of single field "r->arp_ha.sa_data" at net/ipv4/arp.c:1128 (size 14) WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Modules linked in: CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128 Code: fd ff ff e8 41 42 de fb b9 0e 00 00 00 4c 89 fe 48 c7 c2 20 6d ab 87 48 c7 c7 80 6d ab 87 c6 05 25 af 72 04 01 e8 5f 8d ad fb <0f> 0b e9 6c fd ff ff e8 13 42 de fb be 03 00 00 00 4c 89 e7 e8 a6 RSP: 0018:ffffc900050b7998 EFLAGS: 00010286 RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001 RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000 R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000 R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010 FS: 00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981 sock_do_ioctl+0xdf/0x260 net/socket.c:1204 sock_ioctl+0x3ef/0x650 net/socket.c:1321 vfs_ioctl fs/ioctl.c:51 [inline] __do_sys_ioctl fs/ioctl.c:870 [inline] __se_sys_ioctl fs/ioctl.c:856 [inline] __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856 do_syscall_x64 arch/x86/entry/common.c:51 [inline] do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81 entry_SYSCALL_64_after_hwframe+0x64/0xce RIP: 0033:0x7f172b262b8d Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003 RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 </TASK> En el kernel de Linux se ha resuelto la siguiente vulnerabilidad: arp: Evita el desbordamiento en arp_req_get(). syzkaller informó una escritura desbordada en arp_req_get(). [0] Cuando se emite ioctl(SIOCGARP), arp_req_get() busca una entrada vecina y copia neigh->ha para estructurar arpreq.arp_ha.sa_data. El arp_ha aquí es struct sockaddr, no struct sockaddr_storage, por lo que el búfer sa_data tiene solo 14 bytes. En el siguiente símbolo, se desbordan 2 bytes al siguiente campo int, arp_flags. • https://git.kernel.org/stable/c/1da177e4c3f41524e886b7f1b8a0c1fc7321cac2 https://git.kernel.org/stable/c/dbc9b22d0ed319b4e29034ce0a3fe32a3ee2c587 https://git.kernel.org/stable/c/97eaa2955db4120ce6ec2ef123e860bc32232c50 https://git.kernel.org/stable/c/f119f2325ba70cbfdec701000dcad4d88805d5b0 https://git.kernel.org/stable/c/a3f2c083cb575d80a7627baf3339e78fedccbb91 https://git.kernel.org/stable/c/3ab0d6f8289ba8402ca95a9fc61a34909d5e1f3a https://git.kernel.org/stable/c/a7d6027790acea24446ddd6632d394096c0f4667 https://lists.debian.org/debian-lts-announce/2024/06/ • CWE-122: Heap-based Buffer Overflow •
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 •