CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-49987 – bpftool: Fix undefined behavior in qsort(NULL, 0, ...)
https://notcve.org/view.php?id=CVE-2024-49987
In the Linux kernel, the following vulnerability has been resolved: bpftool: Fix undefined behavior in qsort(NULL, 0, ...) When netfilter has no entry to display, qsort is called with qsort(NULL, 0, ...). This results in undefined behavior, as UBSan reports: net.c:827:2: runtime error: null pointer passed as argument 1, which is declared to never be null Although the C standard does not explicitly state whether calling qsort with a NULL pointer when the size is 0 constitutes undefined behavior, Section 7.1.4 of the C standard (Use of library functions) mentions: "Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, or a pointer to non-modifiable storage when the corresponding parameter is not const-qualified) or a type (after promotion) not expected by a function with variable number of arguments, the behavior is undefined." To avoid this, add an early return when nf_link_info is NULL to prevent calling qsort with a NULL pointer. • https://git.kernel.org/stable/c/c2d9f9a7837ab29ccae0c42252f17d436bf0a501 https://git.kernel.org/stable/c/2e0f6f33f2aa87493b365a38a8fd87b8854b7734 https://git.kernel.org/stable/c/c208b02827eb642758cef65641995fd3f38c89af https://git.kernel.org/stable/c/f04e2ad394e2755d0bb2d858ecb5598718bf00d5 •
CVSS: -EPSS: 0%CPEs: 9EXPL: 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/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 •
CVSS: -EPSS: 0%CPEs: 7EXPL: 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/9e52ff544e0bfa09ee339fd7b0937ee3c080c24e https://git.kernel.org/stable/c/43e46ee5efc03990b223f7aa8b77aa9c3d3acfdf https://git.kernel.org/stable/c/7ea9260874b779637aff6d24c344b8ef4ac862a0 https://git.kernel.org/stable/c/ae267989b7b7933dfedcd26468d0a88fc3a9da9e 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: 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 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2024-49971 – drm/amd/display: Increase array size of dummy_boolean
https://notcve.org/view.php?id=CVE-2024-49971
In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Increase array size of dummy_boolean [WHY] dml2_core_shared_mode_support and dml_core_mode_support access the third element of dummy_boolean, i.e. hw_debug5 = &s->dummy_boolean[2], when dummy_boolean has size of 2. Any assignment to hw_debug5 causes an OVERRUN. [HOW] Increase dummy_boolean's array size to 3. This fixes 2 OVERRUN issues reported by Coverity. • https://git.kernel.org/stable/c/e9e48b7bb9cf3b78f0305ef0144aaf61da0a83d8 https://git.kernel.org/stable/c/6d64d39486197083497a01b39e23f2f8474b35d3 •