Page 11 of 2756 results (0.010 seconds)

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: handle otx2_mbox_get_rsp errors in otx2_common.c Add error pointer check after calling otx2_mbox_get_rsp(). • https://git.kernel.org/stable/c/ab58a416c93f134b72ec7e10d8d74509c3985243 https://git.kernel.org/stable/c/785c6758ea32aca73ba9331f7d902f7ce9a25757 https://git.kernel.org/stable/c/9265b6ee754226f61bd122ec57141a781d4e0dcb https://git.kernel.org/stable/c/52c63a6a27d3178fab533fcfb4baa2ed5b8608a3 https://git.kernel.org/stable/c/4b88b202cf1ae79159a94fff9500f9be31559235 https://git.kernel.org/stable/c/d4d5139d280f5837f16d116614c05c2b4eeaf28f https://git.kernel.org/stable/c/0fbc7a5027c6f7f2c785adae3dcec22b2f2b69b3 •

CVSS: -EPSS: 0%CPEs: 6EXPL: 0

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: 0

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: 4EXPL: 0

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: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: blk-cgroup: Fix UAF in blkcg_unpin_online() blkcg_unpin_online() walks up the blkcg hierarchy putting the online pin. To walk up, it uses blkcg_parent(blkcg) but it was calling that after blkcg_destroy_blkgs(blkcg) which could free the blkcg, leading to the following UAF: ================================================================== BUG: KASAN: slab-use-after-free in blkcg_unpin_online+0x15a/0x270 Read of size 8 at addr ffff8881057678c0 by task kworker/9:1/117 CPU: 9 UID: 0 PID: 117 Comm: kworker/9:1 Not tainted 6.13.0-rc1-work-00182-gb8f52214c61a-dirty #48 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 02/02/2022 Workqueue: cgwb_release cgwb_release_workfn Call Trace: <TASK> dump_stack_lvl+0x27/0x80 print_report+0x151/0x710 kasan_report+0xc0/0x100 blkcg_unpin_online+0x15a/0x270 cgwb_release_workfn+0x194/0x480 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 </TASK> ... Freed by task 1944: kasan_save_track+0x2b/0x70 kasan_save_free_info+0x3c/0x50 __kasan_slab_free+0x33/0x50 kfree+0x10c/0x330 css_free_rwork_fn+0xe6/0xb30 process_scheduled_works+0x71b/0xe20 worker_thread+0x82a/0xbd0 kthread+0x242/0x2c0 ret_from_fork+0x33/0x70 ret_from_fork_asm+0x1a/0x30 Note that the UAF is not easy to trigger as the free path is indirected behind a couple RCU grace periods and a work item execution. I could only trigger it with artifical msleep() injected in blkcg_unpin_online(). Fix it by reading the parent pointer before destroying the blkcg's blkg's. • https://git.kernel.org/stable/c/4308a434e5e08c78676aa66bc626ef78cbef0883 https://git.kernel.org/stable/c/64afc6fe24c9896c0153e5a199bcea241ecb0d5c https://git.kernel.org/stable/c/5baa28569c924d9a90d036c2aaab79f791fedaf8 https://git.kernel.org/stable/c/29d1e06560f0f6179062ac638b4064deb637d1ad https://git.kernel.org/stable/c/86e6ca55b83c575ab0f2e105cf08f98e58d3d7af •