CVSS: -EPSS: 0%CPEs: 6EXPL: 0CVE-2024-56678 – powerpc/mm/fault: Fix kfence page fault reporting
https://notcve.org/view.php?id=CVE-2024-56678
In the Linux kernel, the following vulnerability has been resolved: powerpc/mm/fault: Fix kfence page fault reporting copy_from_kernel_nofault() can be called when doing read of /proc/kcore. /proc/kcore can have some unmapped kfence objects which when read via copy_from_kernel_nofault() can cause page faults. Since *_nofault() functions define their own fixup table for handling fault, use that instead of asking kfence to handle such faults. Hence we search the exception tables for the nip which generated the fault. If there is an entry then we let the fixup table handler handle the page fault by returning an error from within ___do_page_fault(). This can be easily triggered if someone tries to do dd from /proc/kcore. eg. dd if=/proc/kcore of=/dev/null bs=1M Some example false negatives: =============================== BUG: KFENCE: invalid read in copy_from_kernel_nofault+0x9c/0x1a0 Invalid read at 0xc0000000fdff0000: copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec BUG: KFENCE: use-after-free read in copy_from_kernel_nofault+0x9c/0x1a0 Use-after-free read at 0xc0000000fe050000 (in kfence-#2): copy_from_kernel_nofault+0x9c/0x1a0 0xc00000000665f950 read_kcore_iter+0x57c/0xa04 proc_reg_read_iter+0xe4/0x16c vfs_read+0x320/0x3ec ksys_read+0x90/0x154 system_call_exception+0x120/0x310 system_call_vectored_common+0x15c/0x2ec • https://git.kernel.org/stable/c/90cbac0e995dd92f7bcf82f74aa50250bf194a4a https://git.kernel.org/stable/c/e0a470b5733c1fe068d5c58b0bb91ad539604bc6 https://git.kernel.org/stable/c/4d2655754e94741b159aa807b72ea85518a65fd5 https://git.kernel.org/stable/c/9ea8d8bf9b625e8ad3be6b0432aecdc549914121 https://git.kernel.org/stable/c/7eaeb7a49b6d16640f9f3c9074c05175d74c710b https://git.kernel.org/stable/c/15f78d2c3d1452645bd8b9da909b0ca266f83c43 https://git.kernel.org/stable/c/06dbbb4d5f7126b6307ab807cbf04ecfc459b933 •
CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-56677 – powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init()
https://notcve.org/view.php?id=CVE-2024-56677
In the Linux kernel, the following vulnerability has been resolved: powerpc/fadump: Move fadump_cma_init to setup_arch() after initmem_init() During early init CMA_MIN_ALIGNMENT_BYTES can be PAGE_SIZE, since pageblock_order is still zero and it gets initialized later during initmem_init() e.g. setup_arch() -> initmem_init() -> sparse_init() -> set_pageblock_order() One such use case where this causes issue is - early_setup() -> early_init_devtree() -> fadump_reserve_mem() -> fadump_cma_init() This causes CMA memory alignment check to be bypassed in cma_init_reserved_mem(). Then later cma_activate_area() can hit a VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) if the reserved memory area was not pageblock_order aligned. Fix it by moving the fadump_cma_init() after initmem_init(), where other such cma reservations also gets called. <stack trace> ============== page: refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x10010 flags: 0x13ffff800000000(node=1|zone=0|lastcpupid=0x7ffff) CMA raw: 013ffff800000000 5deadbeef0000100 5deadbeef0000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: VM_BUG_ON_PAGE(pfn & ((1 << order) - 1)) ------------[ cut here ]------------ kernel BUG at mm/page_alloc.c:778! Call Trace: __free_one_page+0x57c/0x7b0 (unreliable) free_pcppages_bulk+0x1a8/0x2c8 free_unref_page_commit+0x3d4/0x4e4 free_unref_page+0x458/0x6d0 init_cma_reserved_pageblock+0x114/0x198 cma_init_reserved_areas+0x270/0x3e0 do_one_initcall+0x80/0x2f8 kernel_init_freeable+0x33c/0x530 kernel_init+0x34/0x26c ret_from_kernel_user_thread+0x14/0x1c • https://git.kernel.org/stable/c/11ac3e87ce09c27f4587a8c4fe0829d814021a82 https://git.kernel.org/stable/c/aabef6301dcf410dfd2b8759cd413b2a003c7e3f https://git.kernel.org/stable/c/c5c1d1ef70834013fc3bd12b6a0f4664c6d75a74 https://git.kernel.org/stable/c/f551637fe9bf863386309e03f9d148d97f535ad1 https://git.kernel.org/stable/c/7351c5a6507b4401aeecadb5959131410a339520 https://git.kernel.org/stable/c/05b94cae1c47f94588c3e7096963c1007c4d9c1d •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56676 – thermal: testing: Initialize some variables annoteded with _free()
https://notcve.org/view.php?id=CVE-2024-56676
In the Linux kernel, the following vulnerability has been resolved: thermal: testing: Initialize some variables annoteded with _free() Variables annotated with __free() need to be initialized if the function can return before they get updated for the first time or the attempt to free the memory pointed to by them upon function return may crash the kernel. Fix this issue in some places in the thermal testing code. • https://git.kernel.org/stable/c/f6a034f2df426e279f1ecad53626bab80c04796a https://git.kernel.org/stable/c/526c132124a62be486bad1701f7e8e92212ccec6 https://git.kernel.org/stable/c/0104dcdaad3a7afd141e79a5fb817a92ada910ac •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-56675 – bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors
https://notcve.org/view.php?id=CVE-2024-56675
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix UAF via mismatching bpf_prog/attachment RCU flavors Uprobes always use bpf_prog_run_array_uprobe() under tasks-trace-RCU protection. But it is possible to attach a non-sleepable BPF program to a uprobe, and non-sleepable BPF programs are freed via normal RCU (see __bpf_prog_put_noref()). This leads to UAF of the bpf_prog because a normal RCU grace period does not imply a tasks-trace-RCU grace period. Fix it by explicitly waiting for a tasks-trace-RCU grace period after removing the attachment of a bpf_prog to a perf_event. • https://git.kernel.org/stable/c/8c7dcb84e3b744b2b70baa7a44a9b1881c33a9c9 https://git.kernel.org/stable/c/9245459a992d22fe0e92e988f49db1fec82c184a https://git.kernel.org/stable/c/f9f85df30118f3f4112761e6682fc60ebcce23e5 https://git.kernel.org/stable/c/9b53d2c2a38a1effc341d99be3f99fa7ef17047d https://git.kernel.org/stable/c/ef1b808e3b7c98612feceedf985c2fbbeb28f956 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-56674 – virtio_net: correct netdev_tx_reset_queue() invocation point
https://notcve.org/view.php?id=CVE-2024-56674
In the Linux kernel, the following vulnerability has been resolved: virtio_net: correct netdev_tx_reset_queue() invocation point When virtnet_close is followed by virtnet_open, some TX completions can possibly remain unconsumed, until they are finally processed during the first NAPI poll after the netdev_tx_reset_queue(), resulting in a crash [1]. Commit b96ed2c97c79 ("virtio_net: move netdev_tx_reset_queue() call before RX napi enable") was not sufficient to eliminate all BQL crash cases for virtio-net. This issue can be reproduced with the latest net-next master by running: `while :; do ip l set DEV down; ip l set DEV up; done` under heavy network TX load from inside the machine. netdev_tx_reset_queue() can actually be dropped from virtnet_open path; the device is not stopped in any case. For BQL core part, it's just like traffic nearly ceases to exist for some period. For stall detector added to BQL, even if virtnet_close could somehow lead to some TX completions delayed for long, followed by virtnet_open, we can just take it as stall as mentioned in commit 6025b9135f7a ("net: dqs: add NIC stall detector based on BQL"). Note also that users can still reset stall_max via sysfs. So, drop netdev_tx_reset_queue() from virtnet_enable_queue_pair(). • https://git.kernel.org/stable/c/c8bd1f7f3e61fc6c562c806045f3ccd2cc819c01 https://git.kernel.org/stable/c/b4294d4ac61fbb382811a1d64eaf81f446ce2af4 https://git.kernel.org/stable/c/3ddccbefebdbe0c4c72a248676e4d39ac66a8e26 •