linux-cve-announce - CVE-2022-49872: net: gso: fix panic on frag

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <2025050151-CVE-2022-49872-0c67@gregkh>
Date: Thu,  1 May 2025 16:11:02 +0200
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: linux-cve-announce@...r.kernel.org
Cc: Greg Kroah-Hartman <gregkh@...nel.org>
Subject: CVE-2022-49872: net: gso: fix panic on frag_list with mixed head alloc types

From: Greg Kroah-Hartman <gregkh@...nel.org>

Description
===========

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 ("net: gso: Fix skb_segment splat when
splitting gso_size mangled skb having linear-headed frag_list"), it is
allowed to change gso_size of a GRO packet. However, that commit assumes
that "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".

It turns out this assumption does not hold. We'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_list.

(3) Walk the frag_list in skb_segment when determining whether
    NETIF_F_SG should be cleared. This of course slows things down.

This patch implements (3). To limit the performance impact in
skb_segment, the list is walked only for skbs with SKB_GSO_DODGY set
that have gso_size changed. Normal paths thus will not hit it.

We could check only the last skb but since we need to walk the whole
list anyway, let's stay on the safe side.

The Linux kernel CVE team has assigned CVE-2022-49872 to this issue.


Affected and fixed versions
===========================

	Issue introduced in 4.9.194 with commit 162a5a8c3aff15c449e6b38355cdf80ab4f77a5a and fixed in 4.9.334 with commit 5876b7f249a1ecbbcc8e35072c3828d6526d1c3a
	Issue introduced in 4.14.145 with commit 55fb612bef7fd237fb70068e2b6ff1cd1543a8ef and fixed in 4.14.300 with commit 0a9f56e525ea871d3950b90076912f5c7494f00f
	Issue introduced in 4.19.74 with commit 821302dd0c51d29269ef73a595bdff294419e2cd and fixed in 4.19.267 with commit bd5362e58721e4d0d1a37796593bd6e51536ce7a
	Issue introduced in 5.3 with commit 3dcbdb134f329842a38f0e6797191b885ab00a00 and fixed in 5.4.225 with commit 65ad047fd83502447269fda8fd26c99077a9af47
	Issue introduced in 5.3 with commit 3dcbdb134f329842a38f0e6797191b885ab00a00 and fixed in 5.10.155 with commit 50868de7dc4e7f0fcadd6029f32bf4387c102ee6
	Issue introduced in 5.3 with commit 3dcbdb134f329842a38f0e6797191b885ab00a00 and fixed in 5.15.79 with commit ad25a115f50800c6847e0d841c5c7992a9f7c1b3
	Issue introduced in 5.3 with commit 3dcbdb134f329842a38f0e6797191b885ab00a00 and fixed in 6.0.9 with commit 598d9e30927b15731e83797fbd700ecf399f42dd
	Issue introduced in 5.3 with commit 3dcbdb134f329842a38f0e6797191b885ab00a00 and fixed in 6.1 with commit 9e4b7a99a03aefd37ba7bb1f022c8efab5019165
	Issue introduced in 5.2.16 with commit 92984818ff8cfd97311a5e0ac27f148a00df2b54

Please see https://www.kernel.org for a full list of currently supported
kernel versions by the kernel community.

Unaffected versions might change over time as fixes are backported to
older supported kernel versions.  The official CVE entry at
	https://cve.org/CVERecord/?id=CVE-2022-49872
will be updated if fixes are backported, please check that for the most
up to date information about this issue.


Affected files
==============

The file(s) affected by this issue are:
	net/core/skbuff.c


Mitigation
==========

The Linux kernel CVE team recommends that you update to the latest
stable kernel version for this, and many other bugfixes.  Individual
changes are never tested alone, but rather are part of a larger kernel
release.  Cherry-picking individual commits is not recommended or
supported by the Linux kernel community at all.  If however, updating to
the latest release is impossible, the individual changes to resolve this
issue can be found at these commits:
	https://git.kernel.org/stable/c/5876b7f249a1ecbbcc8e35072c3828d6526d1c3a
	https://git.kernel.org/stable/c/0a9f56e525ea871d3950b90076912f5c7494f00f
	https://git.kernel.org/stable/c/bd5362e58721e4d0d1a37796593bd6e51536ce7a
	https://git.kernel.org/stable/c/65ad047fd83502447269fda8fd26c99077a9af47
	https://git.kernel.org/stable/c/50868de7dc4e7f0fcadd6029f32bf4387c102ee6
	https://git.kernel.org/stable/c/ad25a115f50800c6847e0d841c5c7992a9f7c1b3
	https://git.kernel.org/stable/c/598d9e30927b15731e83797fbd700ecf399f42dd
	https://git.kernel.org/stable/c/9e4b7a99a03aefd37ba7bb1f022c8efab5019165