https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 20:35:21 +0000 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0529 certfr-2025-avi-0529 https://cve.radiocsirt.org/vuln/certfr-2025-avi-0529 https://cve.radiocsirt.org/vuln/euvd-2026-344797 EUVD-2026-344797 https://cve.radiocsirt.org/vuln/euvd-2026-344797 https://cve.radiocsirt.org/vuln/fkie_cve-2022-49872 <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: gso: fix panic on frag_list with mixed head alloc types</p> <p>Since commit 3dcbdb134f32 (&#34;net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list&#34;), it is allowed to change gso_size of a GRO packet. However, that commit assumes that &#34;checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too&#34;.</p> <p>It turns out this assumption does not hold. We&#39;ve seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced.</p> <p>There are three different locations where this can be fixed:</p> <p>(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.</p> <p>(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the fr…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: gso: fix panic on frag_list with mixed head alloc types</p> <p>Since commit 3dcbdb134f32 (&#34;net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list&#34;), it is allowed to change gso_size of a GRO packet. However, that commit assumes that &#34;checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too&#34;.</p> <p>It turns out this assumption does not hold. We&#39;ve seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced.</p> <p>There are three different locations where this can be fixed:</p> <p>(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.</p> <p>(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the fr…</p> https://cve.radiocsirt.org/vuln/fkie_cve-2022-49872 https://cve.radiocsirt.org/vuln/ghsa-v832-47wf-r9vp <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: gso: fix panic on frag_list with mixed head alloc types</p> <p>Since commit 3dcbdb134f32 (&#34;net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list&#34;), it is allowed to change gso_size of a GRO packet. However, that commit assumes that &#34;checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too&#34;.</p> <p>It turns out this assumption does not hold. We&#39;ve seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced.</p> <p>There are three different locations where this can be fixed:</p> <p>(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.</p> <p>(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the fr…</p> <p>In the Linux kernel, the following vulnerability has been resolved:</p> <p>net: gso: fix panic on frag_list with mixed head alloc types</p> <p>Since commit 3dcbdb134f32 (&#34;net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list&#34;), it is allowed to change gso_size of a GRO packet. However, that commit assumes that &#34;checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too&#34;.</p> <p>It turns out this assumption does not hold. We&#39;ve seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced.</p> <p>There are three different locations where this can be fixed:</p> <p>(1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem.</p> <p>(2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the fr…</p> https://cve.radiocsirt.org/vuln/ghsa-v832-47wf-r9vp https://cve.radiocsirt.org/vuln/rhsa-2023:2458 <p>hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: ext4: kernel bug in ext4_write_inline_data_end() kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path kernel: possible race condition in drivers/tty/tty_buffers.c kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: use-after-free in free_pipe_info() could lead to privilege escalation 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: out-of-bounds read in fib_nh_match of the file net/ipv4/fib_semantics.c kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() 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 relo…</p> <p>hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: ext4: kernel bug in ext4_write_inline_data_end() kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path kernel: possible race condition in drivers/tty/tty_buffers.c kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: use-after-free in free_pipe_info() could lead to privilege escalation 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: out-of-bounds read in fib_nh_match of the file net/ipv4/fib_semantics.c kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() 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 relo…</p> https://cve.radiocsirt.org/vuln/rhsa-2023:2458 https://cve.radiocsirt.org/vuln/suse-su-2025:01983-1 <p>Security update for the Linux Kernel</p> <p>Security update for the Linux Kernel</p> https://cve.radiocsirt.org/vuln/suse-su-2025:01983-1 https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49872 <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux, Ubuntu:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.4 and 138 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: net: gso: fix panic on frag_list with mixed head alloc types Since commit 3dcbdb134f32 (&#34;net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list&#34;), it is allowed to change gso_size of a GRO packet. However, that commit assumes that &#34;checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too&#34;. It turns out this assumption does not hold. We&#39;ve seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced. There are three different locations where this can be fixed: (1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem. (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_lis…</p> <p><strong>Affected:</strong> Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux, Ubuntu:18.04:LTS: linux-aws, Ubuntu:18.04:LTS: linux-aws-5.4 and 138 more</p> <p>In the Linux kernel, the following vulnerability has been resolved: net: gso: fix panic on frag_list with mixed head alloc types Since commit 3dcbdb134f32 (&#34;net: gso: Fix skb_segment splat when splitting gso_size mangled skb having linear-headed frag_list&#34;), it is allowed to change gso_size of a GRO packet. However, that commit assumes that &#34;checking the first list_skb member suffices; i.e if either of the list_skb members have non head_frag head, then the first one has too&#34;. It turns out this assumption does not hold. We&#39;ve seen BUG_ON being hit in skb_segment when skbs on the frag_list had differing head_frag with the vmxnet3 driver. This happens because __netdev_alloc_skb and __napi_alloc_skb can return a skb that is page backed or kmalloced depending on the requested size. As the result, the last small skb in the GRO packet can be kmalloced. There are three different locations where this can be fixed: (1) We could check head_frag in GRO and not allow GROing skbs with different head_frag. However, that would lead to performance regression on normal forward paths with unmodified gso_size, where !head_frag in the last packet is not a problem. (2) Set a flag in bpf_skb_net_grow and bpf_skb_net_shrink indicating that NETIF_F_SG is undesirable. That would need to eat a bit in sk_buff. Furthermore, that flag can be unset when all skbs on the frag_list are page backed. To retain good performance, bpf_skb_net_grow/shrink would have to walk the frag_lis…</p> https://cve.radiocsirt.org/vuln/ubuntu-cve-2022-49872