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: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2024-36884 – iommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault()
https://notcve.org/view.php?id=CVE-2024-36884
In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu: Use the correct type in nvidia_smmu_context_fault() This was missed because of the function pointer indirection. nvidia_smmu_context_fault() is also installed as a irq function, and the 'void *' was changed to a struct arm_smmu_domain. Since the iommu_domain is embedded at a non-zero offset this causes nvidia_smmu_context_fault() to miscompute the offset. Fixup the types. Unable to handle kernel NULL pointer dereference at virtual address 0000000000000120 Mem abort info: ESR = 0x0000000096000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 FSC = 0x04: level 0 translation fault Data abort info: ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000 CM = 0, WnR = 0, TnD = 0, TagAccess = 0 GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=0000000107c9f000 [0000000000000120] pgd=0000000000000000, p4d=0000000000000000 Internal error: Oops: 0000000096000004 [#1] SMP Modules linked in: CPU: 1 PID: 47 Comm: kworker/u25:0 Not tainted 6.9.0-0.rc7.58.eln136.aarch64 #1 Hardware name: Unknown NVIDIA Jetson Orin NX/NVIDIA Jetson Orin NX, BIOS 3.1-32827747 03/19/2023 Workqueue: events_unbound deferred_probe_work_func pstate: 604000c9 (nZCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : nvidia_smmu_context_fault+0x1c/0x158 lr : __free_irq+0x1d4/0x2e8 sp : ffff80008044b6f0 x29: ffff80008044b6f0 x28: ffff000080a60b18 x27: ffffd32b5172e970 x26: 0000000000000000 x25: ffff0000802f5aac x24: ffff0000802f5a30 x23: ffff0000802f5b60 x22: 0000000000000057 x21: 0000000000000000 x20: ffff0000802f5a00 x19: ffff000087d4cd80 x18: ffffffffffffffff x17: 6234362066666666 x16: 6630303078302d30 x15: ffff00008156d888 x14: 0000000000000000 x13: ffff0000801db910 x12: ffff00008156d6d0 x11: 0000000000000003 x10: ffff0000801db918 x9 : ffffd32b50f94d9c x8 : 1fffe0001032fda1 x7 : ffff00008197ed00 x6 : 000000000000000f x5 : 000000000000010e x4 : 000000000000010e x3 : 0000000000000000 x2 : ffffd32b51720cd8 x1 : ffff000087e6f700 x0 : 0000000000000057 Call trace: nvidia_smmu_context_fault+0x1c/0x158 __free_irq+0x1d4/0x2e8 free_irq+0x3c/0x80 devm_free_irq+0x64/0xa8 arm_smmu_domain_free+0xc4/0x158 iommu_domain_free+0x44/0xa0 iommu_deinit_device+0xd0/0xf8 __iommu_group_remove_device+0xcc/0xe0 iommu_bus_notifier+0x64/0xa8 notifier_call_chain+0x78/0x148 blocking_notifier_call_chain+0x4c/0x90 bus_notify+0x44/0x70 device_del+0x264/0x3e8 pci_remove_bus_device+0x84/0x120 pci_remove_root_bus+0x5c/0xc0 dw_pcie_host_deinit+0x38/0xe0 tegra_pcie_config_rp+0xc0/0x1f0 tegra_pcie_dw_probe+0x34c/0x700 platform_probe+0x70/0xe8 really_probe+0xc8/0x3a0 __driver_probe_device+0x84/0x160 driver_probe_device+0x44/0x130 __device_attach_driver+0xc4/0x170 bus_for_each_drv+0x90/0x100 __device_attach+0xa8/0x1c8 device_initial_probe+0x1c/0x30 bus_probe_device+0xb0/0xc0 deferred_probe_work_func+0xbc/0x120 process_one_work+0x194/0x490 worker_thread+0x284/0x3b0 kthread+0xf4/0x108 ret_from_fork+0x10/0x20 Code: a9b97bfd 910003fd a9025bf5 f85a0035 (b94122a1) En el kernel de Linux, se resolvió la siguiente vulnerabilidad: iommu/arm-smmu: use el tipo correcto en nvidia_smmu_context_fault() Esto se omitió debido a la dirección indirecta del puntero de función. nvidia_smmu_context_fault() también está instalado como una función irq, y 'void *' se cambió a una estructura arm_smmu_domain. Dado que iommu_domain está incrustado en un desplazamiento distinto de cero, esto hace que nvidia_smmu_context_fault() calcule mal el desplazamiento. Arregle los tipos. • https://git.kernel.org/stable/c/e0976331ad114af8e379e18483c346c6c79ca858 https://git.kernel.org/stable/c/e83de8f05b998e227b48cdeea54cba4c9d66d3aa https://git.kernel.org/stable/c/65ade5653f5ab5a21635e51d0c65e95f490f5b6f https://access.redhat.com/security/cve/CVE-2024-36884 https://bugzilla.redhat.com/show_bug.cgi?id=2284269 • CWE-476: NULL Pointer Dereference •
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 •