CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-48946 – udf: Fix preallocation discarding at indirect extent boundary
https://notcve.org/view.php?id=CVE-2022-48946
In the Linux kernel, the following vulnerability has been resolved: udf: Fix preallocation discarding at indirect extent boundary When preallocation extent is the first one in the extent block, the code would corrupt extent tree header instead. Fix the problem and use udf_delete_aext() for deleting extent to avoid some code duplication. • https://git.kernel.org/stable/c/c8b6fa4511a7900db9fb0353b630d4d2ed1ba99c https://git.kernel.org/stable/c/7665857f88557c372da35534165721156756f77f https://git.kernel.org/stable/c/72f651c96c8aadf087fd782d551bf7db648a8c2e https://git.kernel.org/stable/c/4d835efd561dfb9bf5409f11f4ecd428d5d29226 https://git.kernel.org/stable/c/1a075f4a549481ce6e8518d8379f193ccec6b746 https://git.kernel.org/stable/c/63dbbd8f1499b0a161e701a04aa50148d60bd1f7 https://git.kernel.org/stable/c/ae56d9a017724f130cf1a263dd82a78d2a6e3852 https://git.kernel.org/stable/c/12a88f572d6d94b5c0b72e2d1782cc2e9 •
CVSS: -EPSS: %CPEs: 4EXPL: 0CVE-2024-50065 – ntfs3: Change to non-blocking allocation in ntfs_d_hash
https://notcve.org/view.php?id=CVE-2024-50065
In the Linux kernel, the following vulnerability has been resolved: ntfs3: Change to non-blocking allocation in ntfs_d_hash d_hash is done while under "rcu-walk" and should not sleep. __get_name() allocates using GFP_KERNEL, having the possibility to sleep when under memory pressure. Change the allocation to GFP_NOWAIT. • https://git.kernel.org/stable/c/58ebd50d22529f79d2497abbb006137a7c7f5336 https://git.kernel.org/stable/c/d392e85fd1e8d58e460c17ca7d0d5c157848d9c1 https://git.kernel.org/stable/c/2e83375fd95b81be0e9ca457cc7c3f23e3575768 https://git.kernel.org/stable/c/c556e72cea2a1131ae418be017dd6fc76fffe2fb https://git.kernel.org/stable/c/d0c710372e238510db08ea01e7b8bd81ed995dd6 https://git.kernel.org/stable/c/589996bf8c459deb5bbc9747d8f1c51658608103 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-50064 – zram: free secondary algorithms names
https://notcve.org/view.php?id=CVE-2024-50064
In the Linux kernel, the following vulnerability has been resolved: zram: free secondary algorithms names We need to kfree() secondary algorithms names when reset zram device that had multi-streams, otherwise we leak memory. [senozhatsky@chromium.org: kfree(NULL) is legal] Link: https://lkml.kernel.org/r/20240917013021.868769-1-senozhatsky@chromium.org • https://git.kernel.org/stable/c/001d9273570115b2eb360d5452bbc46f6cc063a1 https://git.kernel.org/stable/c/6272936fd242ca1f784c3e21596dfb3859dff276 https://git.kernel.org/stable/c/ef35cc0d15b89dd013e1bb829fe97db7b1ab79eb https://git.kernel.org/stable/c/684826f8271ad97580b138b9ffd462005e470b99 •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2024-50063 – bpf: Prevent tail call between progs attached to different hooks
https://notcve.org/view.php?id=CVE-2024-50063
In the Linux kernel, the following vulnerability has been resolved: bpf: Prevent tail call between progs attached to different hooks bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed. For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2's prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed. Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. • https://git.kernel.org/stable/c/5d5e3b4cbe8ee16b7bf96fd73a421c92a9da3ca1 https://git.kernel.org/stable/c/88c2a10e6c176c2860cd0659f4c0e9d20b3f64d1 https://git.kernel.org/stable/c/28ead3eaabc16ecc907cfb71876da028080f6356 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2024-50062 – RDMA/rtrs-srv: Avoid null pointer deref during path establishment
https://notcve.org/view.php?id=CVE-2024-50062
In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-srv: Avoid null pointer deref during path establishment For RTRS path establishment, RTRS client initiates and completes con_num of connections. After establishing all its connections, the information is exchanged between the client and server through the info_req message. During this exchange, it is essential that all connections have been established, and the state of the RTRS srv path is CONNECTED. So add these sanity checks, to make sure we detect and abort process in error scenarios to avoid null pointer deref. • https://git.kernel.org/stable/c/394b2f4d5e014820455af3eb5859eb328eaafcfd https://git.kernel.org/stable/c/b5d4076664465487a9a3d226756995b12fb73d71 https://git.kernel.org/stable/c/ccb8e44ae3e2391235f80ffc6be59bec6b889ead https://git.kernel.org/stable/c/b720792d7e8515bc695752e0ed5884e2ea34d12a https://git.kernel.org/stable/c/d0e62bf7b575fbfe591f6f570e7595dd60a2f5eb •