APPLIED: [SRU][J 0/1, F 0/3] CVE-2024-26921

[Stefan Bader]

On 30.07.24 01:51, Vinicius Peixoto wrote:
> [Impact]
> 
> ip_local_out() and other functions can pass skb->sk as function argument.
> 
> If the skb is a fragment and reassembly happens before such function call
> returns, the sk must not be released.
> 
> This affects skb fragments reassembled via netfilter or similar
> modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
> 
> Eric Dumazet made an initial analysis of this bug.  Quoting Eric:
>    Calling ip_defrag() in output path is also implying skb_orphan(),
>    which is buggy because output path relies on sk not disappearing.
> 
>    A relevant old patch about the issue was :
>    8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")
> 
>    [..]
> 
>    net/ipv4/ip_output.c depends on skb->sk being set, and probably to an
>    inet socket, not an arbitrary one.
> 
>    If we orphan the packet in ipvlan, then downstream things like FQ
>    packet scheduler will not work properly.
> 
>    We need to change ip_defrag() to only use skb_orphan() when really
>    needed, ie whenever frag_list is going to be used.
> 
> Eric suggested to stash sk in fragment queue and made an initial patch.
> However there is a problem with this:
> 
> If skb is refragmented again right after, ip_do_fragment() will copy
> head->sk to the new fragments, and sets up destructor to sock_wfree.
> IOW, we have no choice but to fix up sk_wmem accouting to reflect the
> fully reassembled skb, else wmem will underflow.
> 
> This change moves the orphan down into the core, to last possible moment.
> As ip_defrag_offset is aliased with sk_buff->sk member, we must move the
> offset into the FRAG_CB, else skb->sk gets clobbered.
> 
> This allows to delay the orphaning long enough to learn if the skb has
> to be queued or if the skb is completing the reasm queue.
> 
> In the former case, things work as before, skb is orphaned.  This is
> safe because skb gets queued/stolen and won't continue past reasm engine.
> 
> In the latter case, we will steal the skb->sk reference, reattach it to
> the head skb, and fix up wmem accouting when inet_frag inflates truesize.
> 
> [Fix]
> 
> Noble: fix released (6.8.0-38.38)
> Jammy: backported (fixed context conflicts from unrelated commits)
> Focal: backported (same as Jammy + clean cherry-picks for the prereqs)
> Bionic: needed
> Xenial: needed
> 
> Jammy and Focal are missing the following commits:
> 
> 2e47eece158a ("ipv4: remove unnecessary type castings")
> 8672406eb5d7 ("net: ip: Handle delivery_time in ip defrag")
> 
> They introduce context conflicts in net/ipv4/inet_fragment.c but
> aren't related to the fix and are relatively straightforward to adjust.
> 
> Focal is also missing the following two commits:
> 
> f1260ff15a71 ("skbuff: introduce skb_expand_head()")
> 7f678def99d2 ("skb_expand_head() adjust skb->truesize incorrectly")
> 
> They are necessary to introduce net/core/sock_destructor.h, which is
> used in the defrag handling refactor that fixes CVE-2024-26921. The
> prerequisite commits were included for Focal.
> 
> [Test]
> Compile/boot tested, also tested with the kernel selftests in
> tools/testing/selftests/net to ensure basic functionality wasn't
> compromised.
> 
> [Where problems could occur]
> Since this affects the handling of fragmented IP packets, any
> problems here would impact networking on affected systems.
> 
> Florian Westphal (1):
>    inet: inet_defrag: prevent sk release while still in use
> 
>   include/linux/skbuff.h                  |  5 +-
>   net/ipv4/inet_fragment.c                | 70 ++++++++++++++++++++-----
>   net/ipv4/ip_fragment.c                  |  2 +-
>   net/ipv6/netfilter/nf_conntrack_reasm.c |  2 +-
>   4 files changed, 60 insertions(+), 19 deletions(-)
> 

Applied to jammy,focal:linux/master-next. Thanks.

-Stefan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_0xE8675DEECBEECEA3.asc
Type: application/pgp-keys
Size: 48643 bytes
Desc: OpenPGP public key
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240731/ea74e182/attachment-0001.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20240731/ea74e182/attachment-0001.sig>