CVSS: -EPSS: 0%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: 0%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: 0%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 •
CVSS: -EPSS: 0%CPEs: 3EXPL: 0CVE-2024-50061 – i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition
https://notcve.org/view.php?id=CVE-2024-50061
In the Linux kernel, the following vulnerability has been resolved: i3c: master: cdns: Fix use after free vulnerability in cdns_i3c_master Driver Due to Race Condition In the cdns_i3c_master_probe function, &master->hj_work is bound with cdns_i3c_master_hj. And cdns_i3c_master_interrupt can call cnds_i3c_master_demux_ibis function to start the work. If we remove the module which will call cdns_i3c_master_remove to make cleanup, it will free master->base through i3c_master_unregister while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows: CPU0 CPU1 | cdns_i3c_master_hj cdns_i3c_master_remove | i3c_master_unregister(&master->base) | device_unregister(&master->dev) | device_release | //free master->base | | i3c_master_do_daa(&master->base) | //use master->base Fix it by ensuring that the work is canceled before proceeding with the cleanup in cdns_i3c_master_remove. • https://git.kernel.org/stable/c/ea0256e393e0072e8c80fd941547807f0c28108b https://git.kernel.org/stable/c/687016d6a1efbfacdd2af913e2108de6b75a28d5 https://git.kernel.org/stable/c/609366e7a06d035990df78f1562291c3bf0d4a12 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2024-50060 – io_uring: check if we need to reschedule during overflow flush
https://notcve.org/view.php?id=CVE-2024-50060
In the Linux kernel, the following vulnerability has been resolved: io_uring: check if we need to reschedule during overflow flush In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it'll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while. Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There's no state to maintain here as overflows always prune from head-of-list, hence it's fine to drop and reacquire the locks at the end of the loop. • https://git.kernel.org/stable/c/a2493904e95ce94bbec819d8f7f03b99976eb25c https://git.kernel.org/stable/c/f4ce3b5d26ce149e77e6b8e8f2058aa80e5b034e https://git.kernel.org/stable/c/c2eadeafce2d385b3f6d26a7f31fee5aba2bbbb0 https://git.kernel.org/stable/c/eac2ca2d682f94f46b1973bdf5e77d85d77b8e53 •