CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2022-50002 – net/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READY
https://notcve.org/view.php?id=CVE-2022-50002
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: net/mlx5: LAG, fix logic over MLX5_LAG_FLAG_NDEVS_READY Only set MLX5_LAG_FLAG_NDEVS_READY if both netdevices are registered. Doing so guarantees that both ldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].dev have valid pointers when MLX5_LAG_FLAG_NDEVS_READY is set. The core issue is asymmetry in setting MLX5_LAG_FLAG_NDEVS_READY and clearing it. Setting it is done wrongly when both ldev->pf[MLX5_LAG_P0].dev and ldev->pf[MLX5_LAG_P1].de... • https://git.kernel.org/stable/c/8a66e45859797e5dd77ff17dd37781f99d5f5b9b •
CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0CVE-2022-50001 – netfilter: nft_tproxy: restrict to prerouting hook
https://notcve.org/view.php?id=CVE-2022-50001
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tproxy: restrict to prerouting hook TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this. This fixes a crash (null dereference) when using tproxy from e.g. output. In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_tproxy: restrict to prerouting hook TPROXY is only allowed from prerouting, but nft_tproxy doesn't check this. This fixes a crash (null dereference) when using t... • https://git.kernel.org/stable/c/4ed8eb6570a49931c705512060acd50058d61616 •
CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2022-50000 – netfilter: flowtable: fix stuck flows on cleanup due to pending work
https://notcve.org/view.php?id=CVE-2022-50000
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: flowtable: fix stuck flows on cleanup due to pending work To clear the flow table on flow table free, the following sequence normally happens in order: 1) gc_step work is stopped to disable any further stats/del requests. 2) All flow table entries are set to teardown state. 3) Run gc_step which will queue HW del work for each flow table entry. 4) Waiting for the above del work to finish (flush). 5) Run gc_step again, deleting all... • https://git.kernel.org/stable/c/c29f74e0df7a02b8303bcdce93a7c0132d62577a •
CVSS: 7.1EPSS: 0%CPEs: 3EXPL: 0CVE-2022-49999 – btrfs: fix space cache corruption and potential double allocations
https://notcve.org/view.php?id=CVE-2022-49999
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix space cache corruption and potential double allocations When testing space_cache v2 on a large set of machines, we encountered a few symptoms: 1. "unable to add free space :-17" (EEXIST) errors. 2. Missing free space info items, sometimes caught with a "missing free space info for X" error. 3. Double-accounted space: ranges that were allocated in the extent tree and also marked as free in the free space tree, ranges that were mar... • https://git.kernel.org/stable/c/d0c2f4fa555e70324ec2a129b822ab58f172cc62 •
CVSS: 5.5EPSS: 0%CPEs: 4EXPL: 0CVE-2022-49998 – rxrpc: Fix locking in rxrpc's sendmsg
https://notcve.org/view.php?id=CVE-2022-49998
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: rxrpc: Fix locking in rxrpc's sendmsg Fix three bugs in the rxrpc's sendmsg implementation: (1) rxrpc_new_client_call() should release the socket lock when returning an error from rxrpc_get_call_slot(). (2) rxrpc_wait_for_tx_window_intr() will return without the call mutex held in the event that we're interrupted by a signal whilst waiting for tx space on the socket or relocking the call mutex afterwards. Fix this by: (a) moving the unlock/... • https://git.kernel.org/stable/c/bc5e3a546d553e5223851fc199e69040eb70f68b •
CVSS: 5.5EPSS: 0%CPEs: 5EXPL: 0CVE-2022-49997 – net: lantiq_xrx200: restore buffer if memory allocation failed
https://notcve.org/view.php?id=CVE-2022-49997
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: net: lantiq_xrx200: restore buffer if memory allocation failed In a situation where memory allocation fails, an invalid buffer address is stored. When this descriptor is used again, the system panics in the build_skb() function when accessing memory. In the Linux kernel, the following vulnerability has been resolved: net: lantiq_xrx200: restore buffer if memory allocation failed In a situation where memory allocation fails, an invalid buffe... • https://git.kernel.org/stable/c/7ea6cd16f1599c1eac6018751eadbc5fc736b99a •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2022-49996 – btrfs: fix possible memory leak in btrfs_get_dev_args_from_path()
https://notcve.org/view.php?id=CVE-2022-49996
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix possible memory leak in btrfs_get_dev_args_from_path() In btrfs_get_dev_args_from_path(), btrfs_get_bdev_and_sb() can fail if the path is invalid. In this case, btrfs_get_dev_args_from_path() returns directly without freeing args->uuid and args->fsid allocated before, which causes memory leak. To fix these possible leaks, when btrfs_get_bdev_and_sb() fails, btrfs_put_dev_args_from_path() is called to clean up the memory. In the L... • https://git.kernel.org/stable/c/321a81835b4aed4f717f89921286f6544ffa8be9 •
CVSS: 7.8EPSS: 0%CPEs: 3EXPL: 0CVE-2022-49995 – writeback: avoid use-after-free after removing device
https://notcve.org/view.php?id=CVE-2022-49995
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: writeback: avoid use-after-free after removing device When a disk is removed, bdi_unregister gets called to stop further writeback and wait for associated delayed work to complete. However, wb_inode_writeback_end() may schedule bandwidth estimation dwork after this has completed, which can result in the timer attempting to access the just freed bdi_writeback. Fix this by checking if the bdi_writeback is alive, similar to when scheduling wri... • https://git.kernel.org/stable/c/45a2966fd64147518dc5bca25f447bd0fb5359ac •
CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0CVE-2022-49994 – bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem
https://notcve.org/view.php?id=CVE-2022-49994
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: bootmem: remove the vmemmap pages from kmemleak in put_page_bootmem The vmemmap pages is marked by kmemleak when allocated from memblock. Remove it from kmemleak when freeing the page. Otherwise, when we reuse the page, kmemleak may report such an error and then stop working. kmemleak: Cannot insert 0xffff98fb6eab3d40 into the object search tree (overlaps existing) kmemleak: Kernel memory leak detector disabled kmemleak: Object 0xffff98fb6b... • https://git.kernel.org/stable/c/f41f2ed43ca5258d70d53290d1951a21621f95c8 •
CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0CVE-2022-49993 – loop: Check for overflow while configuring loop
https://notcve.org/view.php?id=CVE-2022-49993
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: loop: Check for overflow while configuring loop The userspace can configure a loop using an ioctl call, wherein a configuration of type loop_config is passed (see lo_ioctl()'s case on line 1550 of drivers/block/loop.c). This proceeds to call loop_configure() which in turn calls loop_set_status_from_info() (see line 1050 of loop.c), passing &config->info which is of type loop_info64*. This function then sets the appropriate values, like the ... • https://git.kernel.org/stable/c/18e28817cb516b39de6281f6db9b0618b2cc7b42 •