CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2024-49978 – gso: fix udp gso fraglist segmentation after pull from frag_list
https://notcve.org/view.php?id=CVE-2024-49978
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: 7EXPL: 0CVE-2024-49975 – uprobes: fix kernel info leak via "[uprobes]" vma
https://notcve.org/view.php?id=CVE-2024-49975
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/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/2aa45f43709ba2082917bd2973d02687075b6eee https://git.kernel.org/stable/c/9634e8dc964a4adafa7e1535147abd7ec29441a6 https://git.kernel.org/stable/c/34820304cc2cd1804ee1f8f3504ec7781 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-49974 – NFSD: Limit the number of concurrent async COPY operations
https://notcve.org/view.php?id=CVE-2024-49974
In the Linux kernel, the following vulnerability has been resolved: NFSD: Limit the number of concurrent async COPY operations Nothing appears to limit the number of concurrent async COPY operations that clients can start. In addition, AFAICT each async COPY can copy an unlimited number of 4MB chunks, so can run for a long time. Thus IMO async COPY can become a DoS vector. Add a restriction mechanism that bounds the number of concurrent background COPY operations. Start simple and try to be fair -- this patch implements a per-namespace limit. An async COPY request that occurs while this limit is exceeded gets NFS4ERR_DELAY. The requesting client can choose to send the request again after a delay or fall back to a traditional read/write style copy. If there is need to make the mechanism more sophisticated, we can visit that in future patches. • https://git.kernel.org/stable/c/b4e21431a0db4854b5023cd5af001be557e6c3db https://git.kernel.org/stable/c/6a488ad7745b8f64625c6d3a24ce7e448e83f11b https://git.kernel.org/stable/c/aadc3bbea163b6caaaebfdd2b6c4667fbc726752 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 0CVE-2024-49973 – r8169: add tally counter fields added with RTL8125
https://notcve.org/view.php?id=CVE-2024-49973
In the Linux kernel, the following vulnerability has been resolved: r8169: add tally counter fields added with RTL8125 RTL8125 added fields to the tally counter, what may result in the chip dma'ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it. • https://git.kernel.org/stable/c/f1bce4ad2f1cee6759711904b9fffe4a3dd8af87 https://git.kernel.org/stable/c/991e8b0bab669b7d06927c3e442b3352532e8581 https://git.kernel.org/stable/c/21950321ad33d7613b1453f4c503d7b1871deb61 https://git.kernel.org/stable/c/fe44b3bfbf0c74df5712f44458689d0eccccf47d https://git.kernel.org/stable/c/1c723d785adb711496bc64c24240f952f4faaabf https://git.kernel.org/stable/c/92bc8647b4d65f4d4bf8afdb206321c1bc55a486 https://git.kernel.org/stable/c/585c048d15ed559f20cb94c8fa2f30077efa4fbc https://git.kernel.org/stable/c/ced8e8b8f40accfcce4a2bbd8b150aa76 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49972 – drm/amd/display: Deallocate DML memory if allocation fails
https://notcve.org/view.php?id=CVE-2024-49972
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Deallocate DML memory if allocation fails [Why] When DC state create DML memory allocation fails, memory is not deallocated subsequently, resulting in uninitialized structure that is not NULL. [How] Deallocate memory if DML memory allocation fails. • https://git.kernel.org/stable/c/80345daa5746184195f2d383a2f1bad058f0f94c https://git.kernel.org/stable/c/892abca6877a96c9123bb1c010cafccdf8ca1b75 •