Page 13 of 6368 results (0.007 seconds)

CVSS: 5.5EPSS: 0%CPEs: 7EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flow rule object from commit path No need to postpone this to the commit release path, since no packets are walking over this object, this is accessed from control plane only. This helped uncovered UAF triggered by races with the netlink notifier. In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: release flow rule object from commit path No need to postpone this to the co... • https://git.kernel.org/stable/c/5b8d63489c3b701eb2a76f848ec94d8cbc9373b9 •

CVSS: 7.1EPSS: 0%CPEs: 6EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ipvs: fix WARNING in __ip_vs_cleanup_batch() During the initialization of ip_vs_conn_net_init(), if file ip_vs_conn or ip_vs_conn_sync fails to be created, the initialization is successful by default. Therefore, the ip_vs_conn or ip_vs_conn_sync file doesn't be found during the remove. The following is the stack information: name 'ip_vs_conn_sync' WARNING: CPU: 3 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Modules linked i... • https://git.kernel.org/stable/c/61b1ab4583e275af216c8454b9256de680499b19 •

CVSS: 5.5EPSS: 0%CPEs: 6EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: ipvs: fix WARNING in ip_vs_app_net_cleanup() During the initialization of ip_vs_app_net_init(), if file ip_vs_app fails to be created, the initialization is successful by default. Therefore, the ip_vs_app file doesn't be found during the remove in ip_vs_app_net_cleanup(). It will cause WRNING. The following is the stack information: name 'ip_vs_app' WARNING: CPU: 1 PID: 9 at fs/proc/generic.c:712 remove_proc_entry+0x389/0x460 Modules linked... • https://git.kernel.org/stable/c/457c4cbc5a3dde259d2a1f15d5f9785290397267 •

CVSS: 5.5EPSS: 0%CPEs: 9EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: rose: Fix NULL pointer dereference in rose_send_frame() The syzkaller reported an issue: KASAN: null-ptr-deref in range [0x0000000000000380-0x0000000000000387] CPU: 0 PID: 4069 Comm: kworker/0:15 Not tainted 6.0.0-syzkaller-02734-g0326074ff465 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022 Workqueue: rcu_gp srcu_invoke_callbacks RIP: 0010:rose_send_frame+0x1dd/0x2f0 net/rose/rose_link.c:101 Call... • https://git.kernel.org/stable/c/76885373129b13df35ecc9b4ee86ea5840f12133 •

CVSS: 5.5EPSS: 0%CPEs: 8EXPL: 0

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(). In the Linux kernel, the fol... • https://git.kernel.org/stable/c/1fa5ae857bb14f6046205171d98506d8112dd74e •

CVSS: 7.1EPSS: 0%CPEs: 7EXPL: 0

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: 7.1EPSS: 0%CPEs: 5EXPL: 0

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: 5.5EPSS: 0%CPEs: 8EXPL: 0

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. In the Linux kernel, the followi... • https://git.kernel.org/stable/c/442244c9633292a147ab2b29e7007a7c8a3909b2 •

CVSS: 5.5EPSS: 0%CPEs: 3EXPL: 0

01 May 2025 — In the Linux kernel, the following vulnerability has been resolved: netfilter: ipset: enforce documented limit to prevent allocating huge memory Daniel Xu reported that the hash:net,iface type of the ipset subsystem does not limit adding the same network with different interfaces to a set, which can lead to huge memory usage or allocation failure. The quick reproducer is $ ipset create ACL.IN.ALL_PERMIT hash:net,iface hashsize 1048576 timeout 0 $ for i in $(seq 0 100); do /sbin/ipset add ACL.IN.ALL_PERMIT 0... • https://git.kernel.org/stable/c/ccf0a4b7fc688561428290265e4effde41446668 •

CVSS: 7.1EPSS: 0%CPEs: 8EXPL: 0

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 •