CVE-2024-26921

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> inet: inet_defrag: prevent sk release while still in use<br /> <br /> ip_local_out() and other functions can pass skb-&gt;sk as function argument.<br /> <br /> If the skb is a fragment and reassembly happens before such function call<br /> returns, the sk must not be released.<br /> <br /> This affects skb fragments reassembled via netfilter or similar<br /> modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.<br /> <br /> Eric Dumazet made an initial analysis of this bug. Quoting Eric:<br /> Calling ip_defrag() in output path is also implying skb_orphan(),<br /> which is buggy because output path relies on sk not disappearing.<br /> <br /> A relevant old patch about the issue was :<br /> 8282f27449bf ("inet: frag: Always orphan skbs inside ip_defrag()")<br /> <br /> [..]<br /> <br /> net/ipv4/ip_output.c depends on skb-&gt;sk being set, and probably to an<br /> inet socket, not an arbitrary one.<br /> <br /> If we orphan the packet in ipvlan, then downstream things like FQ<br /> packet scheduler will not work properly.<br /> <br /> We need to change ip_defrag() to only use skb_orphan() when really<br /> needed, ie whenever frag_list is going to be used.<br /> <br /> Eric suggested to stash sk in fragment queue and made an initial patch.<br /> However there is a problem with this:<br /> <br /> If skb is refragmented again right after, ip_do_fragment() will copy<br /> head-&gt;sk to the new fragments, and sets up destructor to sock_wfree.<br /> IOW, we have no choice but to fix up sk_wmem accouting to reflect the<br /> fully reassembled skb, else wmem will underflow.<br /> <br /> This change moves the orphan down into the core, to last possible moment.<br /> As ip_defrag_offset is aliased with sk_buff-&gt;sk member, we must move the<br /> offset into the FRAG_CB, else skb-&gt;sk gets clobbered.<br /> <br /> This allows to delay the orphaning long enough to learn if the skb has<br /> to be queued or if the skb is completing the reasm queue.<br /> <br /> In the former case, things work as before, skb is orphaned. This is<br /> safe because skb gets queued/stolen and won&amp;#39;t continue past reasm engine.<br /> <br /> In the latter case, we will steal the skb-&gt;sk reference, reattach it to<br /> the head skb, and fix up wmem accouting when inet_frag inflates truesize.