https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Tue, 29 Sep 2026 13:05:42 +0000 https://vulnerability.circl.lu/vuln/cve-2023-53549 <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfilter: ipset: Rework long task execution when adding/deleting entries</p> <p>When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51bf09ba (&#34;netfilter: ipset: Limit the maximal range of consecutive elements to add/delete&#34;) tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step.</p> <p>The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel.</p> <p><strong>Affected:</strong> Linux</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>netfilter: ipset: Rework long task execution when adding/deleting entries</p> <p>When adding/deleting large number of elements in one step in ipset, it can take a reasonable amount of time and can result in soft lockup errors. The patch 5f7b51bf09ba (&#34;netfilter: ipset: Limit the maximal range of consecutive elements to add/delete&#34;) tried to fix it by limiting the max elements to process at all. However it was not enough, it is still possible that we get hung tasks. Lowering the limit is not reasonable, so the approach in this patch is as follows: rely on the method used at resizing sets and save the state when we reach a smaller internal batch limit, unlock/lock and proceed from the saved state. Thus we can avoid long continuous tasks and at the same time removed the limit to add/delete large number of elements in one step.</p> <p>The nfnl mutex is held during the whole operation which prevents one to issue other ipset commands in parallel.</p> https://vulnerability.circl.lu/vuln/cve-2023-53549 https://vulnerability.circl.lu/vuln/rhsa-2023:2951 <p>hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: when setting font with malicious data by ioctl PIO_FONT, kernel will write memory out of bounds kernel: mm/slub: actually fix freelist pointer vs redzoning kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: possible race condition in drivers/tty/tty_buffers.c kernel: use-after-free in ath9k_htc_probe_device() could cause an escalation of privileges kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: KVM: nVMX: missing IBPB when exiting from nested guest can lead to Spectre v2 attacks kernel: netfilter: nf_conntrack_irc message handling issue kernel: race condition in xfrm_probe_algs can lead to OOB read/write kernel: media: em28xx: initialize refcount before kref_get kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() kernel: use-after-free caused by l2cap_reassemble_sdu() in net/bluetooth/l2cap_core.c kernel: data races around icsk-&gt;icsk_af_ops in do_ipv6_setsockopt kernel: data races around sk-&gt;sk_prot kernel: memory leak in l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c kernel: denial of service in follow_page_pte in mm/gup.c due to poisoned pte entry kernel: use-after-free after failed devlink reload in devlink_param_get kernel: USB-accessible buffer overflow in brcmfmac kernel: Double-free in split_…</p> <p>hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: when setting font with malicious data by ioctl PIO_FONT, kernel will write memory out of bounds kernel: mm/slub: actually fix freelist pointer vs redzoning kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: possible race condition in drivers/tty/tty_buffers.c kernel: use-after-free in ath9k_htc_probe_device() could cause an escalation of privileges kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: KVM: nVMX: missing IBPB when exiting from nested guest can lead to Spectre v2 attacks kernel: netfilter: nf_conntrack_irc message handling issue kernel: race condition in xfrm_probe_algs can lead to OOB read/write kernel: media: em28xx: initialize refcount before kref_get kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() kernel: use-after-free caused by l2cap_reassemble_sdu() in net/bluetooth/l2cap_core.c kernel: data races around icsk-&gt;icsk_af_ops in do_ipv6_setsockopt kernel: data races around sk-&gt;sk_prot kernel: memory leak in l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c kernel: denial of service in follow_page_pte in mm/gup.c due to poisoned pte entry kernel: use-after-free after failed devlink reload in devlink_param_get kernel: USB-accessible buffer overflow in brcmfmac kernel: Double-free in split_…</p> https://vulnerability.circl.lu/vuln/rhsa-2023:2951