CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2024-49977 – net: stmmac: Fix zero-division error when disabling tc cbs
https://notcve.org/view.php?id=CVE-2024-49977
In the Linux kernel, the following vulnerability has been resolved: net: stmmac: Fix zero-division error when disabling tc cbs The commit b8c43360f6e4 ("net: stmmac: No need to calculate speed divider when offload is disabled") allows the "port_transmit_rate_kbps" to be set to a value of 0, which is then passed to the "div_s64" function when tc-cbs is disabled. This leads to a zero-division error. When tc-cbs is disabled, the idleslope, sendslope, and credit values the credit values are not required to be configured. Therefore, adding a return statement after setting the txQ mode to DCB when tc-cbs is disabled would prevent a zero-division error. • https://git.kernel.org/stable/c/b4bca4722fda928810d024350493990de39f1e40 https://git.kernel.org/stable/c/2145583e5995598f50d66f8710c86bb1e910ac46 https://git.kernel.org/stable/c/521d42a1c24d638241220d4b9fa7e7a0ed02b88e https://git.kernel.org/stable/c/a71b686418ee6bcb6d6365f7f6d838d9874d9c64 https://git.kernel.org/stable/c/b8c43360f6e424131fa81d3ba8792ad8ff25a09e https://git.kernel.org/stable/c/f01782804147a8c21f481b3342c83422c041d2c0 https://git.kernel.org/stable/c/e33fe25b1efe4f2e6a5858786dbc82ae4c44ed4c https://git.kernel.org/stable/c/b0da9504a528f05f97d926b4db74ff219 •
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: 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: 8EXPL: 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/64648ae8c97ec5a3165021627f5a1658ebe081ca 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/585c048d15ed559f20cb94c8fa2f30077 •
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 •