CVSS: -EPSS: 0%CPEs: 5EXPL: 0CVE-2022-48933 – netfilter: nf_tables: fix memory leak during stateful obj update
https://notcve.org/view.php?id=CVE-2022-48933
In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix memory leak during stateful obj update stateful objects can be updated from the control plane. The transaction logic allocates a temporary object for this purpose. The ->init function was called for this object, so plain kfree() leaks resources. We must call ->destroy function of the object. nft_obj_destroy does this, but it also decrements the module refcount, but the update path doesn't increment it. To avoid special-casing the update object release, do module_get for the update case too and release it via nft_obj_destroy(). • https://git.kernel.org/stable/c/d62d0ba97b5803183e70cfded7f7b9da76893bf5 https://git.kernel.org/stable/c/53026346a94c43f35c32b18804041bc483271d87 https://git.kernel.org/stable/c/7e9880e81d3fd6a43c202f205717485290432826 https://git.kernel.org/stable/c/e96e204ee6fa46702f6c94c3c69a09e69e0eac52 https://git.kernel.org/stable/c/34bb90e407e3288f610558beaae54ecaa32b11c4 https://git.kernel.org/stable/c/dad3bdeef45f81a6e90204bcc85360bb76eccec7 •
CVSS: -EPSS: 0%CPEs: 2EXPL: 0CVE-2022-48932 – net/mlx5: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fte
https://notcve.org/view.php?id=CVE-2022-48932
In the Linux kernel, the following vulnerability has been resolved: net/mlx5: DR, Fix slab-out-of-bounds in mlx5_cmd_dr_create_fte When adding a rule with 32 destinations, we hit the following out-of-band access issue: BUG: KASAN: slab-out-of-bounds in mlx5_cmd_dr_create_fte+0x18ee/0x1e70 This patch fixes the issue by both increasing the allocated buffers to accommodate for the needed actions and by checking the number of actions to prevent this issue when a rule with too many actions is provided. • https://git.kernel.org/stable/c/1ffd498901c1134a7cbecf5409e12c064c39cef9 https://git.kernel.org/stable/c/4ad319cdfbe555b4ff67bc608736c46a6930c848 https://git.kernel.org/stable/c/0aec12d97b2036af0946e3d582144739860ac07b •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48931 – configfs: fix a race in configfs_{,un}register_subsystem()
https://notcve.org/view.php?id=CVE-2022-48931
In the Linux kernel, the following vulnerability has been resolved: configfs: fix a race in configfs_{,un}register_subsystem() When configfs_register_subsystem() or configfs_unregister_subsystem() is executing link_group() or unlink_group(), it is possible that two processes add or delete list concurrently. Some unfortunate interleavings of them can cause kernel panic. One of cases is: A --> B --> C --> D A <-- B <-- C <-- D delete list_head *B | delete list_head *C --------------------------------|----------------------------------- configfs_unregister_subsystem | configfs_unregister_subsystem unlink_group | unlink_group unlink_obj | unlink_obj list_del_init | list_del_init __list_del_entry | __list_del_entry __list_del | __list_del // next == C | next->prev = prev | | next->prev = prev prev->next = next | | // prev == B | prev->next = next Fix this by adding mutex when calling link_group() or unlink_group(), but parent configfs_subsystem is NULL when config_item is root. So I create a mutex configfs_subsystem_mutex. • https://git.kernel.org/stable/c/7063fbf2261194f72ee75afca67b3b38b554b5fa https://git.kernel.org/stable/c/40805099af11f68c5ca7dbcfacf455da8f99f622 https://git.kernel.org/stable/c/d1654de19d42f513b6cfe955cc77e7f427e05a77 https://git.kernel.org/stable/c/a37024f7757c25550accdebf49e497ad6ae239fe https://git.kernel.org/stable/c/b7e2b91fcb5c78c414e33dc8d50642e307ca0c5a https://git.kernel.org/stable/c/a7ab53d3c27dfe83bb594456b9f38a37796ec39b https://git.kernel.org/stable/c/e7a66dd2687758718eddd79b542a95cf3aa488cc https://git.kernel.org/stable/c/3aadfd46858b1f64d4d6a0654b863e21a •
CVSS: -EPSS: 0%CPEs: 8EXPL: 0CVE-2022-48930 – RDMA/ib_srp: Fix a deadlock
https://notcve.org/view.php?id=CVE-2022-48930
In the Linux kernel, the following vulnerability has been resolved: RDMA/ib_srp: Fix a deadlock Remove the flush_workqueue(system_long_wq) call since flushing system_long_wq is deadlock-prone and since that call is redundant with a preceding cancel_work_sync() • https://git.kernel.org/stable/c/ef6c49d87c3418c442a22e55e3ce2f91b163d69e https://git.kernel.org/stable/c/8cc342508f9e7fdccd2e9758ae9d52aff72dab7f https://git.kernel.org/stable/c/4752fafb461821f8c8581090c923ababba68c5bd https://git.kernel.org/stable/c/d7997d19dfa7001ca41e971cd9efd091bb195b51 https://git.kernel.org/stable/c/901206f71e6ad2b2e7accefc5199a438d173c25f https://git.kernel.org/stable/c/99eb8d694174c777558dc902d575d1997d5ca650 https://git.kernel.org/stable/c/c8b56e51aa91b8e7df3a98388dce3fdabd15c1d4 https://git.kernel.org/stable/c/98d056603ce55ceb90631b3927151c190 •
CVSS: -EPSS: 0%CPEs: 4EXPL: 0CVE-2022-48929 – bpf: Fix crash due to out of bounds access into reg2btf_ids.
https://notcve.org/view.php?id=CVE-2022-48929
In the Linux kernel, the following vulnerability has been resolved: bpf: Fix crash due to out of bounds access into reg2btf_ids. When commit e6ac2450d6de ("bpf: Support bpf program calling kernel function") added kfunc support, it defined reg2btf_ids as a cheap way to translate the verifier reg type to the appropriate btf_vmlinux BTF ID, however commit c25b2ae13603 ("bpf: Replace PTR_TO_XXX_OR_NULL with PTR_TO_XXX | PTR_MAYBE_NULL") moved the __BPF_REG_TYPE_MAX from the last member of bpf_reg_type enum to after the base register types, and defined other variants using type flag composition. However, now, the direct usage of reg->type to index into reg2btf_ids may no longer fall into __BPF_REG_TYPE_MAX range, and hence lead to out of bounds access and kernel crash on dereference of bad pointer. • https://git.kernel.org/stable/c/e8efe8369944c6199f124e3b50662ad05a048b60 https://git.kernel.org/stable/c/931e56be527fb2672556e3c00c57ff2a5f5de43e https://git.kernel.org/stable/c/35ab8c9085b0af847df7fac9571ccd26d9f0f513 https://git.kernel.org/stable/c/77459bc4d5e2c6f24db845780b4d9d60cf82d06a https://git.kernel.org/stable/c/8c39925e98d498b9531343066ef82ae39e41adae https://git.kernel.org/stable/c/f0ce1bc9e0235dd7412240be493d7ea65ed9eadc https://git.kernel.org/stable/c/45ce4b4f9009102cd9f581196d480a59208690c1 •