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: 4EXPL: 0CVE-2024-26726 – btrfs: don't drop extent_map for free space inode on write error
https://notcve.org/view.php?id=CVE-2024-26726
In the Linux kernel, the following vulnerability has been resolved: btrfs: don't drop extent_map for free space inode on write error While running the CI for an unrelated change I hit the following panic with generic/648 on btrfs_holes_spacecache. assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385 ------------[ cut here ]------------ kernel BUG at fs/btrfs/extent_io.c:1385! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G W 6.8.0-rc2+ #1 RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0 Call Trace: <TASK> extent_write_cache_pages+0x2ac/0x8f0 extent_writepages+0x87/0x110 do_writepages+0xd5/0x1f0 filemap_fdatawrite_wbc+0x63/0x90 __filemap_fdatawrite_range+0x5c/0x80 btrfs_fdatawrite_range+0x1f/0x50 btrfs_write_out_cache+0x507/0x560 btrfs_write_dirty_block_groups+0x32a/0x420 commit_cowonly_roots+0x21b/0x290 btrfs_commit_transaction+0x813/0x1360 btrfs_sync_file+0x51a/0x640 __x64_sys_fdatasync+0x52/0x90 do_syscall_64+0x9c/0x190 entry_SYSCALL_64_after_hwframe+0x6e/0x76 This happens because we fail to write out the free space cache in one instance, come back around and attempt to write it again. However on the second pass through we go to call btrfs_get_extent() on the inode to get the extent mapping. Because this is a new block group, and with the free space inode we always search the commit root to avoid deadlocking with the tree, we find nothing and return a EXTENT_MAP_HOLE for the requested range. This happens because the first time we try to write the space cache out we hit an error, and on an error we drop the extent mapping. • https://git.kernel.org/stable/c/02f2b95b00bf57d20320ee168b30fb7f3db8e555 https://git.kernel.org/stable/c/7bddf18f474f166c19f91b2baf67bf7c5eda03f7 https://git.kernel.org/stable/c/a4b7741c8302e28073bfc6dd1c2e73598e5e535e https://git.kernel.org/stable/c/5571e41ec6e56e35f34ae9f5b3a335ef510e0ade •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-26719 – nouveau: offload fence uevents work to workqueue
https://notcve.org/view.php?id=CVE-2024-26719
In the Linux kernel, the following vulnerability has been resolved: nouveau: offload fence uevents work to workqueue This should break the deadlock between the fctx lock and the irq lock. This offloads the processing off the work from the irq into a workqueue. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: nuevo: descargar valla uevents work to workqueue Esto debería romper el punto muerto entre el bloqueo fctx y el bloqueo irq. Esto descarga el procesamiento del trabajo del irq a una cola de trabajo. • https://git.kernel.org/stable/c/cc0037fa592d56e4abb9c7d1c52c4d2dc25cd906 https://git.kernel.org/stable/c/985d053f7633d8b539ab1531738d538efac678a9 https://git.kernel.org/stable/c/39126abc5e20611579602f03b66627d7cd1422f0 https://access.redhat.com/security/cve/CVE-2024-26719 https://bugzilla.redhat.com/show_bug.cgi?id=2273143 • CWE-833: Deadlock •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-26715 – usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend
https://notcve.org/view.php?id=CVE-2024-26715
In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Fix NULL pointer dereference in dwc3_gadget_suspend In current scenario if Plug-out and Plug-In performed continuously there could be a chance while checking for dwc->gadget_driver in dwc3_gadget_suspend, a NULL pointer dereference may occur. Call Stack: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 basically clears the variable and CPU2 checks the variable. Consider CPU1 is running and right before gadget_driver is cleared and in parallel CPU2 executes dwc3_gadget_suspend where it finds dwc->gadget_driver which is not NULL and resumes execution and then CPU1 completes execution. CPU2 executes dwc3_disconnect_gadget where it checks dwc->gadget_driver is already NULL because of which the NULL pointer deference occur. En el kernel de Linux, se resolvió la siguiente vulnerabilidad: usb: dwc3: gadget: corrige la desreferencia del puntero NULL en dwc3_gadget_suspend En el escenario actual, si el Plug-out y el Plug-In se ejecutan continuamente, podría haber una posibilidad al verificar dwc->gadget_driver en dwc3_gadget_suspend, puede ocurrir una desreferencia del puntero NULL. Pila de llamadas: CPU1: CPU2: gadget_unbind_driver dwc3_suspend_common dwc3_gadget_stop dwc3_gadget_suspend dwc3_disconnect_gadget CPU1 básicamente borra la variable y CPU2 verifica la variable. Considere que CPU1 se está ejecutando y justo antes de que se borre gadget_driver y en paralelo CPU2 ejecuta dwc3_gadget_suspend donde encuentra dwc->gadget_driver que no es NULL y reanuda la ejecución y luego CPU1 completa la ejecución. • https://git.kernel.org/stable/c/9772b47a4c2916d645c551228b6085ea24acbe5d https://git.kernel.org/stable/c/8cca5c85393a7a490d4d7942c24d73d29cc77b3e https://git.kernel.org/stable/c/df2ca3271569367352835f981618e284fdc4ca94 https://git.kernel.org/stable/c/88936ceab6b426f1312327e9ef849c215c6007a7 https://git.kernel.org/stable/c/57e2e42ccd3cd6183228269715ed032f44536751 https://git.kernel.org/stable/c/c7ebd8149ee519d27232e6e4940e9c02071b568b https://git.kernel.org/stable/c/36695d5eeeefe5a64b47d0336e7c8fc144e78182 https://git.kernel.org/stable/c/61a348857e869432e6a920ad8ea9132e8 •