Page 80 of 3075 results (0.013 seconds)

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

In the Linux kernel, the following vulnerability has been resolved: null_blk: fix validation of block size Block size should be between 512 and PAGE_SIZE and be a power of 2. The current check does not validate this, so update the check. Without this patch, null_blk would Oops due to a null pointer deref when loaded with bs=1536 [1]. [axboe: remove unnecessary braces and != 0 check] • https://git.kernel.org/stable/c/9625afe1dd4a158a14bb50f81af9e2dac634c0b1 https://git.kernel.org/stable/c/9b873bdaae64bddade9d8c6df23c8a31948d47d0 https://git.kernel.org/stable/c/2772ed2fc075eef7df3789906fc9dae01e4e132e https://git.kernel.org/stable/c/08f03186b96e25e3154916a2e70732557c770ea7 https://git.kernel.org/stable/c/f92409a9da02f27d05d713bff5f865e386cef9b3 https://git.kernel.org/stable/c/c462ecd659b5fce731f1d592285832fd6ad54053 https://access.redhat.com/security/cve/CVE-2024-41077 https://bugzilla.redhat.com/show_bug.cgi?id=2300454 • CWE-476: NULL Pointer Dereference •

CVSS: 3.3EPSS: 0%CPEs: 4EXPL: 0

In the Linux kernel, the following vulnerability has been resolved: NFSv4: Fix memory leak in nfs4_set_security_label We leak nfs_fattr and nfs4_label every time we set a security xattr. A vulnerability was found in the nfs4_set_security_label() in the Linux kernel, where the function fails to free the nfs_fattr attribute before exiting, leaving said memory allocation present. As the nfs4_set_security_label() is called repeatedly over time, this may lead to memory exhaustion. • https://git.kernel.org/stable/c/899604a7c958771840941caff9ee3dd8193d984c https://git.kernel.org/stable/c/b98090699319e64f5de1e8db5bb75870f1eb1c6e https://git.kernel.org/stable/c/d130220ccc94d74d70da984a199477937e7bf03c https://git.kernel.org/stable/c/aad11473f8f4be3df86461081ce35ec5b145ba68 https://access.redhat.com/security/cve/CVE-2024-41076 https://bugzilla.redhat.com/show_bug.cgi?id=2300453 • CWE-401: Missing Release of Memory after Effective Lifetime •

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

In the Linux kernel, the following vulnerability has been resolved: cachefiles: add consistency check for copen/cread This prevents malicious processes from completing random copen/cread requests and crashing the system. Added checks are listed below: * Generic, copen can only complete open requests, and cread can only complete read requests. * For copen, ondemand_id must not be 0, because this indicates that the request has not been read by the daemon. * For cread, the object corresponding to fd and req should be the same. • https://git.kernel.org/stable/c/3b744884c0431b5a62c92900e64bfd0ed61e8e2a https://git.kernel.org/stable/c/36d845ccd7bf527110a65fe953886a176c209539 https://git.kernel.org/stable/c/8aaa6c5dd2940ab934d6cd296175f43dbb32b34a https://git.kernel.org/stable/c/a26dc49df37e996876f50a0210039b2d211fdd6f •

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

In the Linux kernel, the following vulnerability has been resolved: cachefiles: Set object to close if ondemand_id < 0 in copen If copen is maliciously called in the user mode, it may delete the request corresponding to the random id. And the request may have not been read yet. Note that when the object is set to reopen, the open request will be done with the still reopen state in above case. As a result, the request corresponding to this object is always skipped in select_req function, so the read request is never completed and blocks other process. Fix this issue by simply set object to close if its id < 0 in copen. • https://git.kernel.org/stable/c/703bea37d13e4ccdafd17ae7c4cb583752ba7663 https://git.kernel.org/stable/c/c32ee78fbc670e6f90989a45d340748e34cad333 https://git.kernel.org/stable/c/0845c553db11c84ff53fccd59da11b6d6ece4a60 https://git.kernel.org/stable/c/4f8703fb3482f92edcfd31661857b16fec89c2c0 •

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

In the Linux kernel, the following vulnerability has been resolved: nvme: avoid double free special payload If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free will result. Clear the RQF_SPECIAL_LOAD when the request is cleaned. A flaw was found in the Linux kernel, where the following issue has been resolved: nvme: avoid double free special payload. If a discard request needs to be retried, and that retry may fail before a new special payload is added, a double free occurs. Clear the RQF_SPECIAL_LOAD when the request is cleaned. • https://git.kernel.org/stable/c/c5942a14f795de957ae9d66027aac8ff4fe70057 https://git.kernel.org/stable/c/f3ab45aacd25d957547fb6d115c1574c20964b3b https://git.kernel.org/stable/c/ae84383c96d6662c24697ab6b44aae855ab670aa https://git.kernel.org/stable/c/1b9fd1265fac85916f90b4648de02adccdb7220b https://git.kernel.org/stable/c/e5d574ab37f5f2e7937405613d9b1a724811e5ad https://access.redhat.com/security/cve/CVE-2024-41073 https://bugzilla.redhat.com/show_bug.cgi?id=2301637 • CWE-415: Double Free •