CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-49915 – mISDN: fix possible memory leak in mISDN_register_device()
https://notcve.org/view.php?id=CVE-2022-49915
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: mISDN: fix possible memory leak in mISDN_register_device() Afer commit 1fa5ae857bb1 ("driver core: get rid of struct device's bus_id string array"), the name of device is allocated dynamically, add put_device() to give up the reference, so that the name can be freed in kobject_cleanup() when the refcount is 0. Set device class before put_device() to avoid null release() function WARN message in device_release(). • https://git.kernel.org/stable/c/1fa5ae857bb14f6046205171d98506d8112dd74e •
CVSS: -EPSS: %CPEs: 7EXPL: 0CVE-2022-49914 – btrfs: fix inode list leak during backref walking at resolve_indirect_refs()
https://notcve.org/view.php?id=CVE-2022-49914
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at resolve_indirect_refs() During backref walking, at resolve_indirect_refs(), if we get an error we jump to the 'out' label and call ulist_free() on the 'parents' ulist, which frees all the elements in the ulist - however that does not free any inode lists that may be attached to elements, through the 'aux' field of a ulist node, so we end up leaking lists if we have any attached to the uno... • https://git.kernel.org/stable/c/3301958b7c1dae8f0f5ded63aa881e0b71e78464 •
CVSS: -EPSS: %CPEs: 5EXPL: 0CVE-2022-49913 – btrfs: fix inode list leak during backref walking at find_parent_nodes()
https://notcve.org/view.php?id=CVE-2022-49913
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix inode list leak during backref walking at find_parent_nodes() During backref walking, at find_parent_nodes(), if we are dealing with a data extent and we get an error while resolving the indirect backrefs, at resolve_indirect_refs(), or in the while loop that iterates over the refs in the direct refs rbtree, we end up leaking the inode lists attached to the direct refs we have in the direct refs rbtree that were not yet added to ... • https://git.kernel.org/stable/c/86d5f994425252d8a40e2184c94a2682ae8ecfbf •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-49912 – btrfs: fix ulist leaks in error paths of qgroup self tests
https://notcve.org/view.php?id=CVE-2022-49912
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix ulist leaks in error paths of qgroup self tests In the test_no_shared_qgroup() and test_multiple_refs() qgroup self tests, if we fail to add the tree ref, remove the extent item or remove the extent ref, we are returning from the test function without freeing the "old_roots" ulist that was allocated by the previous calls to btrfs_find_all_roots(). Fix that by calling ulist_free() before returning. • https://git.kernel.org/stable/c/442244c9633292a147ab2b29e7007a7c8a3909b2 •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-49910 – Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu
https://notcve.org/view.php?id=CVE-2022-49910
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: Fix use-after-free caused by l2cap_reassemble_sdu Fix the race condition between the following two flows that run in parallel: 1. l2cap_reassemble_sdu -> chan->ops->recv (l2cap_sock_recv_cb) -> __sock_queue_rcv_skb. 2. bt_sock_recvmsg -> skb_recv_datagram, skb_free_datagram. An SKB can be queued by the first flow and immediately dequeued and freed by the second flow, therefore the callers of l2cap_reassemble_sdu can't use ... • https://git.kernel.org/stable/c/4b51dae96731c9d82f5634e75ac7ffd3b9c1b060 •
CVSS: -EPSS: %CPEs: 9EXPL: 0CVE-2022-49909 – Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del()
https://notcve.org/view.php?id=CVE-2022-49909
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: Bluetooth: L2CAP: fix use-after-free in l2cap_conn_del() When l2cap_recv_frame() is invoked to receive data, and the cid is L2CAP_CID_A2MP, if the channel does not exist, it will create a channel. However, after a channel is created, the hold operation of the channel is not performed. In this case, the value of channel reference counting is 1. As a result, after hci_error_reset() is triggered, l2cap_conn_del() invokes the close hook functio... • https://git.kernel.org/stable/c/d255c861e268ba342e855244639a15f12d7a0bf2 •
CVSS: -EPSS: %CPEs: 8EXPL: 0CVE-2022-49907 – net: mdio: fix undefined behavior in bit shift for __mdiobus_register
https://notcve.org/view.php?id=CVE-2022-49907
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: net: mdio: fix undefined behavior in bit shift for __mdiobus_register Shifting signed 32-bit value by 31 bits is undefined, so changing significant bit to unsigned. The UBSAN warning calltrace like below: UBSAN: shift-out-of-bounds in drivers/net/phy/mdio_bus.c:586:27 left shift of 1 by 31 places cannot be represented in type 'int' Call Trace:
CVSS: -EPSS: %CPEs: 6EXPL: 0CVE-2022-49903 – ipv6: fix WARNING in ip6_route_net_exit_late()
https://notcve.org/view.php?id=CVE-2022-49903
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ipv6: fix WARNING in ip6_route_net_exit_late() During the initialization of ip6_route_net_init_late(), if file ipv6_route or rt6_stats fails to be created, the initialization is successful by default. Therefore, the ipv6_route or rt6_stats file doesn't be found during the remove in ip6_route_net_exit_late(). It will cause WRNING. The following is the stack information: name 'rt6_stats' WARNING: CPU: 0 PID: 9 at fs/proc/generic.c:712 remove_... • https://git.kernel.org/stable/c/cdb1876192dbe680b3ac955717fdf7f863c1762d •
CVSS: -EPSS: %CPEs: 3EXPL: 0CVE-2022-49898 – btrfs: fix tree mod log mishandling of reallocated nodes
https://notcve.org/view.php?id=CVE-2022-49898
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: btrfs: fix tree mod log mishandling of reallocated nodes We have been seeing the following panic in production kernel BUG at fs/btrfs/tree-mod-log.c:677! invalid opcode: 0000 [#1] SMP RIP: 0010:tree_mod_log_rewind+0x1b4/0x200 RSP: 0000:ffffc9002c02f890 EFLAGS: 00010293 RAX: 0000000000000003 RBX: ffff8882b448c700 RCX: 0000000000000000 RDX: 0000000000008000 RSI: 00000000000000a7 RDI: ffff88877d831c00 RBP: 0000000000000002 R08: 000000000000009... • https://git.kernel.org/stable/c/bd989ba359f2acb8bc5f5490e19010fc0a6f8356 •
CVSS: -EPSS: %CPEs: 1EXPL: 0CVE-2022-49897 – fscrypt: fix keyring memory leak on mount failure
https://notcve.org/view.php?id=CVE-2022-49897
01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: fscrypt: fix keyring memory leak on mount failure Commit d7e7b9af104c ("fscrypt: stop using keyrings subsystem for fscrypt_master_key") moved the keyring destruction from __put_super() to generic_shutdown_super() so that the filesystem's block device(s) are still available. Unfortunately, this causes a memory leak in the case where a mount is attempted with the test_dummy_encryption mount option, but the mount fails after the option has alr... • https://git.kernel.org/stable/c/ccd30a476f8e864732de220bd50e6f372f5ebcab •