CVSS: 5.5EPSS: 0%CPEs: 2EXPL: 0CVE-2022-50015 – ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware boot
https://notcve.org/view.php?id=CVE-2022-50015
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: ASoC: SOF: Intel: hda-ipc: Do not process IPC reply before firmware boot It is not yet clear, but it is possible to create a firmware so broken that it will send a reply message before a FW_READY message (it is not yet clear if FW_READY will arrive later). Since the reply_data is allocated only after the FW_READY message, this will lead to a NULL pointer dereference if not filtered out. The issue was reported with IPC4 firmware but the same... • https://git.kernel.org/stable/c/6e9cde974863dc9d9c6cdb178f625e410c5be3d0 •
CVSS: 7.1EPSS: 0%CPEs: 2EXPL: 0CVE-2022-50014 – mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW
https://notcve.org/view.php?id=CVE-2022-50014
18 Jun 2025 — In the Linux kernel, the following vulnerability has been resolved: mm/gup: fix FOLL_FORCE COW security issue and remove FOLL_COW Ever since the Dirty COW (CVE-2016-5195) security issue happened, we know that FOLL_FORCE can be possibly dangerous, especially if there are races that can be exploited by user space. Right now, it would be sufficient to have some code that sets a PTE of a R/O-mapped shared page dirty, in order for it to erroneously become writable by FOLL_FORCE. The implications of setting a wri... • https://git.kernel.org/stable/c/9ae0f87d009ca6c4aab2882641ddfc319727e3db •
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: 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 •