CVSS: 9.0EPSS: 0%CPEs: 8EXPL: 0CVE-2024-36886 – tipc: fix UAF in error path
https://notcve.org/view.php?id=CVE-2024-36886
In the Linux kernel, the following vulnerability has been resolved: tipc: fix UAF in error path Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported a UAF in the tipc_buf_append() error path: BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 Read of size 8 at addr ffff88804d2a7c80 by task poc/8034 CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014 Call Trace: <IRQ> __dump_stack linux/lib/dump_stack.c:88 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106 print_address_description linux/mm/kasan/report.c:377 print_report+0xc4/0x620 linux/mm/kasan/report.c:488 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026 skb_release_all linux/net/core/skbuff.c:1094 __kfree_skb linux/net/core/skbuff.c:1108 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144 kfree_skb linux/./include/linux/skbuff.h:1244 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233 NF_HOOK linux/./include/linux/netfilter.h:314 NF_HOOK linux/./include/linux/netfilter.h:308 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254 dst_input linux/./include/net/dst.h:461 ip_rcv_finish linux/net/ipv4/ip_input.c:449 NF_HOOK linux/. • https://git.kernel.org/stable/c/1149557d64c97dc9adf3103347a1c0e8c06d3b89 https://git.kernel.org/stable/c/e19ec8ab0e25bc4803d7cc91c84e84532e2781bd https://git.kernel.org/stable/c/93bc2d6d16f2c3178736ba6b845b30475856dc40 https://git.kernel.org/stable/c/367766ff9e407f8a68409b7ce4dc4d5a72afeab1 https://git.kernel.org/stable/c/66116556076f0b96bc1aa9844008c743c8c67684 https://git.kernel.org/stable/c/21ea04aad8a0839b4ec27ef1691ca480620e8e14 https://git.kernel.org/stable/c/ffd4917c1edb3c3ff334fce3704fbe9c39f35682 https://git.kernel.org/stable/c/a0fbb26f8247e326a320e2cb4395bfb23 • CWE-416: Use After Free •
CVSS: 4.4EPSS: 0%CPEs: 3EXPL: 0CVE-2024-36885 – drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor()
https://notcve.org/view.php?id=CVE-2024-36885
In the Linux kernel, the following vulnerability has been resolved: drm/nouveau/firmware: Fix SG_DEBUG error with nvkm_firmware_ctor() Currently, enabling SG_DEBUG in the kernel will cause nouveau to hit a BUG() on startup: kernel BUG at include/linux/scatterlist.h:187! invalid opcode: 0000 [#1] PREEMPT SMP NOPTI CPU: 7 PID: 930 Comm: (udev-worker) Not tainted 6.9.0-rc3Lyude-Test+ #30 Hardware name: MSI MS-7A39/A320M GAMING PRO (MS-7A39), BIOS 1.I0 01/22/2019 RIP: 0010:sg_init_one+0x85/0xa0 Code: 69 88 32 01 83 e1 03 f6 c3 03 75 20 a8 01 75 1e 48 09 cb 41 89 54 24 08 49 89 1c 24 41 89 6c 24 0c 5b 5d 41 5c e9 7b b9 88 00 <0f> 0b 0f 0b 0f 0b 48 8b 05 5e 46 9a 01 eb b2 66 66 2e 0f 1f 84 00 RSP: 0018:ffffa776017bf6a0 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa77600d87000 RCX: 000000000000002b RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffa77680d87000 RBP: 000000000000e000 R08: 0000000000000000 R09: 0000000000000000 R10: ffff98f4c46aa508 R11: 0000000000000000 R12: ffff98f4c46aa508 R13: ffff98f4c46aa008 R14: ffffa77600d4a000 R15: ffffa77600d4a018 FS: 00007feeb5aae980(0000) GS:ffff98f5c4dc0000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f22cb9a4520 CR3: 00000001043ba000 CR4: 00000000003506f0 Call Trace: <TASK> ? die+0x36/0x90 ? do_trap+0xdd/0x100 ? sg_init_one+0x85/0xa0 ? • https://git.kernel.org/stable/c/1a88c18da464db0ba8ea25196d0a06490f65322e https://git.kernel.org/stable/c/e05af009302893f39b072811a68fa4a196284c75 https://git.kernel.org/stable/c/52a6947bf576b97ff8e14bb0a31c5eaf2d0d96e2 https://access.redhat.com/security/cve/CVE-2024-36885 https://bugzilla.redhat.com/show_bug.cgi?id=2284265 • CWE-489: Active Debug Code •
CVSS: 7.0EPSS: 0%CPEs: 10EXPL: 0CVE-2024-36883 – net: fix out-of-bounds access in ops_init
https://notcve.org/view.php?id=CVE-2024-36883
In the Linux kernel, the following vulnerability has been resolved: net: fix out-of-bounds access in ops_init net_alloc_generic is called by net_alloc, which is called without any locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It is read twice, first to allocate an array, then to set s.len, which is later used to limit the bounds of the array access. It is possible that the array is allocated and another thread is registering a new pernet ops, increments max_gen_ptrs, which is then used to set s.len with a larger than allocated length for the variable array. Fix it by reading max_gen_ptrs only once in net_alloc_generic. If max_gen_ptrs is later incremented, it will be caught in net_assign_generic. En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: net: corrige el acceso fuera de los límites en ops_init net_alloc_generic es llamado por net_alloc, que se llama sin ningún bloqueo. • https://git.kernel.org/stable/c/073862ba5d249c20bd5c49fc6d904ff0e1f6a672 https://git.kernel.org/stable/c/561331eae0a03d0c4cf60f3cf485aa3e8aa5ab48 https://git.kernel.org/stable/c/a2c82f7bee1ffa9eafa1fb0bd886a7eea8c9e497 https://git.kernel.org/stable/c/3cdc34d76c4f777579e28ad373979d36c030cfd3 https://git.kernel.org/stable/c/7b0e64583eab8c1d896b47e5dd0bf2e7d86ec41f https://git.kernel.org/stable/c/0c3248bc708a7797be573214065cf908ff1f54c7 https://git.kernel.org/stable/c/9518b79bfd2fbf99fa9b7e8e36bcb1825e7ba030 https://git.kernel.org/stable/c/2d60ff5874aefd006717ca5e22ac1e25e • CWE-787: Out-of-bounds Write •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36882 – mm: use memalloc_nofs_save() in page_cache_ra_order()
https://notcve.org/view.php?id=CVE-2024-36882
In the Linux kernel, the following vulnerability has been resolved: mm: use memalloc_nofs_save() in page_cache_ra_order() See commit f2c817bed58d ("mm: use memalloc_nofs_save in readahead path"), ensure that page_cache_ra_order() do not attempt to reclaim file-backed pages too, or it leads to a deadlock, found issue when test ext4 large folio. INFO: task DataXceiver for:7494 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. task:DataXceiver for state:D stack:0 pid:7494 ppid:1 flags:0x00000200 Call trace: __switch_to+0x14c/0x240 __schedule+0x82c/0xdd0 schedule+0x58/0xf0 io_schedule+0x24/0xa0 __folio_lock+0x130/0x300 migrate_pages_batch+0x378/0x918 migrate_pages+0x350/0x700 compact_zone+0x63c/0xb38 compact_zone_order+0xc0/0x118 try_to_compact_pages+0xb0/0x280 __alloc_pages_direct_compact+0x98/0x248 __alloc_pages+0x510/0x1110 alloc_pages+0x9c/0x130 folio_alloc+0x20/0x78 filemap_alloc_folio+0x8c/0x1b0 page_cache_ra_order+0x174/0x308 ondemand_readahead+0x1c8/0x2b8 page_cache_async_ra+0x68/0xb8 filemap_readahead.isra.0+0x64/0xa8 filemap_get_pages+0x3fc/0x5b0 filemap_splice_read+0xf4/0x280 ext4_file_splice_read+0x2c/0x48 [ext4] vfs_splice_read.part.0+0xa8/0x118 splice_direct_to_actor+0xbc/0x288 do_splice_direct+0x9c/0x108 do_sendfile+0x328/0x468 __arm64_sys_sendfile64+0x8c/0x148 invoke_syscall+0x4c/0x118 el0_svc_common.constprop.0+0xc8/0xf0 do_el0_svc+0x24/0x38 el0_svc+0x4c/0x1f8 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188/0x190 En el kernel de Linux, se ha resuelto la siguiente vulnerabilidad: mm: use memalloc_nofs_save() en page_cache_ra_order() Consulte el commit f2c817bed58d ("mm: use memalloc_nofs_save en la ruta de lectura anticipada"), asegúrese de que page_cache_ra_order() no intente recuperar archivos respaldados páginas también, o conduce a un punto muerto, se encontró un problema al probar el folio grande ext4. INFORMACIÓN: tarea DataXceiver para:7494 bloqueada durante más de 120 segundos. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" desactiva este mensaje. tarea:DataXceiver para estado:D pila:0 pid:7494 ppid:1 banderas:0x00000200 Rastreo de llamadas: __switch_to+0x14c/0x240 __schedule+0x82c/0xdd0 Schedule+0x58/0xf0 io_schedule+0x24/0xa0 __folio_lock+0x130/0x300 _lote+0x378 /0x918 migrar_páginas+0x350/0x700 compact_zone+0x63c/0xb38 compact_zone_order+0xc0/0x118 try_to_compact_pages+0xb0/0x280 __alloc_pages_direct_compact+0x98/0x248 __alloc_pages+0x510/0x1110 alloc_pages+0 x9c/0x130 folio_alloc+0x20/0x78 filemap_alloc_folio+0x8c/0x1b0 page_cache_ra_order+0x174 /0x308 ondemand_readahead+0x1c8/0x2b8 page_cache_async_ra+0x68/0xb8 filemap_readahead.isra.0+0x64/0xa8 filemap_get_pages+0x3fc/0x5b0 filemap_splice_read+0xf4/0x280 ext4_file_splice_read+0x2c/0x48 [ext4] vfs_splice_read.part.0+0xa8/0x118 empalme_direct_to_actor+ 0xbc/0x288 do_splice_direct+0x9c/0x108 do_sendfile+0x328/0x468 __arm64_sys_sendfile64+0x8c/0x148 invoke_syscall+0x4c/0x118 el0_svc_common.constprop.0+0xc8/0xf0 +0x24/0x38 el0_svc+0x4c/0x1f8 el0t_64_sync_handler+0xc0/0xc8 el0t_64_sync+0x188 /0x190 • https://git.kernel.org/stable/c/793917d997df2e432f3e9ac126e4482d68256d01 https://git.kernel.org/stable/c/7629ef6dda1564098aadeef38e5fbd11ee8627c4 https://git.kernel.org/stable/c/468971c3f4b8187f25334503b68050a0e1370147 https://git.kernel.org/stable/c/cf6a1d16c6df3c30b03f0c6a92a2ba7f86dffb45 https://git.kernel.org/stable/c/30153e4466647a17eebfced13eede5cbe4290e69 https://access.redhat.com/security/cve/CVE-2024-36882 https://bugzilla.redhat.com/show_bug.cgi?id=2284273 • CWE-833: Deadlock •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2024-36881 – mm/userfaultfd: reset ptes when close() for wr-protected ones
https://notcve.org/view.php?id=CVE-2024-36881
In the Linux kernel, the following vulnerability has been resolved: mm/userfaultfd: reset ptes when close() for wr-protected ones Userfaultfd unregister includes a step to remove wr-protect bits from all the relevant pgtable entries, but that only covered an explicit UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself. Cover that too. This fixes a WARN trace. The only user visible side effect is the user can observe leftover wr-protect bits even if the user close()ed on an userfaultfd when releasing the last reference of it. However hopefully that should be harmless, and nothing bad should happen even if so. This change is now more important after the recent page-table-check patch we merged in mm-unstable (446dd9ad37d0 ("mm/page_table_check: support userfault wr-protect entries")), as we'll do sanity check on uffd-wp bits without vma context. So it's better if we can 100% guarantee no uffd-wp bit leftovers, to make sure each report will be valid. • https://git.kernel.org/stable/c/f369b07c861435bd812a9d14493f71b34132ed6f https://git.kernel.org/stable/c/3e2747c3ddfa717697c3cc2aa6ab989e48d6587d https://git.kernel.org/stable/c/377f3a9a3d032a52325a5b110379a25dd1ab1931 https://git.kernel.org/stable/c/8d8b68a5b0c9fb23d37df06bb273ead38fd5a29d https://git.kernel.org/stable/c/c88033efe9a391e72ba6b5df4b01d6e628f4e734 https://access.redhat.com/security/cve/CVE-2024-36881 https://bugzilla.redhat.com/show_bug.cgi?id=2284277 • CWE-281: Improper Preservation of Permissions •