Page 40 of 3563 results (0.007 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: ext4: drop ppath from ext4_ext_replay_update_ex() to avoid double-free When calling ext4_force_split_extent_at() in ext4_ext_replay_update_ex(), the 'ppath' is updated but it is the 'path' that is freed, thus potentially triggering a double-free in the following process: ext4_ext_replay_update_ex ppath = path ext4_force_split_extent_at(&ppath) ext4_split_extent_at ext4_ext_insert_extent ext4_ext_create_new_leaf ext4_ext_grow_indepth ext4_find_extent if (depth > path[0].p_maxdepth) kfree(path) ---> path First freed *orig_path = path = NULL ---> null ppath kfree(path) ---> path double-free !!! So drop the unnecessary ppath and use path directly to avoid this problem. And use ext4_find_extent() directly to update path, avoiding unnecessary memory allocation and freeing. Also, propagate the error returned by ext4_find_extent() instead of using strange error codes. • https://git.kernel.org/stable/c/8016e29f4362e285f0f7e38fadc61a5b7bdfdfa2 https://git.kernel.org/stable/c/8c26d9e53e5fbacda0732a577e97c5a5b7882aaf https://git.kernel.org/stable/c/a34bed978364114390162c27e50fca50791c568d https://git.kernel.org/stable/c/6367d3f04c69e2b8770b8137bd800e0784b0abbc https://git.kernel.org/stable/c/1b558006d98b7b0b730027be0ee98973dd10ee0d https://git.kernel.org/stable/c/3ff710662e8d86a63a39b334e9ca0cb10e5c14b0 https://git.kernel.org/stable/c/63adc9016917e6970fb0104ee5fd6770f02b2d80 https://git.kernel.org/stable/c/5c0f4cc84d3a601c99bc5e6e6eb1cbda5 •

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

In the Linux kernel, the following vulnerability has been resolved: aoe: fix the potential use-after-free problem in more places For fixing CVE-2023-6270, f98364e92662 ("aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts") makes tx() calling dev_put() instead of doing in aoecmd_cfg_pkts(). It avoids that the tx() runs into use-after-free. Then Nicolai Stange found more places in aoe have potential use-after-free problem with tx(). e.g. revalidate(), aoecmd_ata_rw(), resend(), probe() and aoecmd_cfg_rsp(). Those functions also use aoenet_xmit() to push packet to tx queue. So they should also use dev_hold() to increase the refcnt of skb->dev. On the other hand, moving dev_put() to tx() causes that the refcnt of skb->dev be reduced to a negative value, because corresponding dev_hold() are not called in revalidate(), aoecmd_ata_rw(), resend(), probe(), and aoecmd_cfg_rsp(). This patch fixed this issue. • https://git.kernel.org/stable/c/ad80c34944d7175fa1f5c7a55066020002921a99 https://git.kernel.org/stable/c/1a54aa506b3b2f31496731039e49778f54eee881 https://git.kernel.org/stable/c/faf0b4c5e00bb680e8e43ac936df24d3f48c8e65 https://git.kernel.org/stable/c/7dd09fa80b0765ce68bfae92f4e2f395ccf0fba4 https://git.kernel.org/stable/c/74ca3ef68d2f449bc848c0a814cefc487bf755fa https://git.kernel.org/stable/c/eb48680b0255a9e8a9bdc93d6a55b11c31262e62 https://git.kernel.org/stable/c/f98364e926626c678fb4b9004b75cacf92ff0662 https://git.kernel.org/stable/c/079cba4f4e307c69878226fdf5228c20a •

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

In the Linux kernel, the following vulnerability has been resolved: media: venus: fix use after free bug in venus_remove due to race condition in venus_probe, core->work is bound with venus_sys_error_handler, which is used to handle error. The code use core->sys_err_done to make sync work. The core->work is started in venus_event_notify. If we call venus_remove, there might be an unfished work. The possible sequence is as follows: CPU0 CPU1 |venus_sys_error_handler venus_remove | hfi_destroy | venus_hfi_destroy | kfree(hdev); | |hfi_reinit |venus_hfi_queues_reinit |//use hdev Fix it by canceling the work in venus_remove. • https://git.kernel.org/stable/c/af2c3834c8ca7cc65d15592ac671933df8848115 https://git.kernel.org/stable/c/5098b9e6377577fe13d03e1d8914930f014a3314 https://git.kernel.org/stable/c/63bbe26471ebdcc3c20bb4cc3950d666279ad658 https://git.kernel.org/stable/c/60b6968341a6dd5353554f3e72db554693a128a5 https://git.kernel.org/stable/c/bf6be32e2d39f6301ff1831e249d32a8744ab28a https://git.kernel.org/stable/c/2a541fcc0bd2b05a458e9613376df1289ec11621 https://git.kernel.org/stable/c/b0686aedc5f1343442d044bd64eeac7e7a391f4e https://git.kernel.org/stable/c/d925e9f7fb5a2dbefd1a73fc01061f38c •

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

In the Linux kernel, the following vulnerability has been resolved: gso: fix udp gso fraglist segmentation after pull from frag_list Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly. Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants. In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg->next)->dest. Detect invalid geometry due to pull, by checking head_skb size. Don't just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment. • https://git.kernel.org/stable/c/9fd1ff5d2ac7181844735806b0a703c942365291 https://git.kernel.org/stable/c/080e6c9a3908de193a48f646c5ce1bfb15676ffc https://git.kernel.org/stable/c/af3122f5fdc0d00581d6e598a668df6bf54c9daa https://git.kernel.org/stable/c/33e28acf42ee863f332a958bfc2f1a284a3659df https://git.kernel.org/stable/c/3cd00d2e3655fad3bda96dc1ebf17b6495f86fea https://git.kernel.org/stable/c/a1e40ac5b5e9077fe1f7ae0eb88034db0f9ae1ab •

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

In the Linux kernel, the following vulnerability has been resolved: uprobes: fix kernel info leak via "[uprobes]" vma xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn't really matter, debugger can read this memory anyway. • https://git.kernel.org/stable/c/d4b3b6384f98f8692ad0209891ccdbc7e78bbefe https://git.kernel.org/stable/c/f31f92107e5a8ecc8902705122c594e979a351fe https://git.kernel.org/stable/c/fe5e9182d3e227476642ae2b312e2356c4d326a3 https://git.kernel.org/stable/c/f561b48d633ac2e7d0d667020fc634a96ade33a0 https://git.kernel.org/stable/c/21cb47db1ec9765f91304763a24565ddc22d2492 https://git.kernel.org/stable/c/24141df5a8615790950deedd926a44ddf1dfd6d8 https://git.kernel.org/stable/c/5b981d8335e18aef7908a068529a3287258ff6d8 https://git.kernel.org/stable/c/2aa45f43709ba2082917bd2973d026870 •