[PATCH net-next] ipv6: discard fragment queue if middle fragment is not 8 bytes aligned

[PATCH net-next] ipv6: discard fragment queue if middle fragment is not 8 bytes aligned

[Fernando Fernandez Mancera]

Currently the kernel IPv6 implementation is not dicarding the fragment
queue upon receiving a IPv6 fragment that is not 8 bytes aligned. It
relies on queue expiration to free the queue.

While RFC 8200 section 4.5 does not explicitly mention that the rest of
fragments must be discarded, it does not make sense to keep them. The
parameter problem message is sent regardless that. In addition, if the
sender is able to re-compose the datagram so it is 8 bytes aligned it
would qualify as a new whole datagram not fitting into the same fragment
queue.

The sooner we can free resources during reassembly, the better.

Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
---
 net/ipv6/reassembly.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
index 25ec8001898d..8b0bc0ba56f4 100644
--- a/net/ipv6/reassembly.c
+++ b/net/ipv6/reassembly.c
@@ -163,6 +163,9 @@ static int ip6_frag_queue(struct net *net,
 			 * this case. -DaveM
 			 */
 			*prob_offset = offsetof(struct ipv6hdr, payload_len);
+			inet_frag_kill(&fq->q, refs);
+			__IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
+					IPSTATS_MIB_REASMFAILS);
 			return -1;
 		}
 		if (end > fq->q.len) {
-- 
2.53.0

Re: [PATCH net-next] ipv6: discard fragment queue if middle fragment is not 8 bytes aligned

[Eric Dumazet]

On Mon, Feb 23, 2026 at 4:19 PM Fernando Fernandez Mancera
<fmancera@suse.de> wrote:
>
> Currently the kernel IPv6 implementation is not dicarding the fragment
> queue upon receiving a IPv6 fragment that is not 8 bytes aligned. It
> relies on queue expiration to free the queue.
>
> While RFC 8200 section 4.5 does not explicitly mention that the rest of
> fragments must be discarded, it does not make sense to keep them. The
> parameter problem message is sent regardless that. In addition, if the
> sender is able to re-compose the datagram so it is 8 bytes aligned it
> would qualify as a new whole datagram not fitting into the same fragment
> queue.
>
> The sooner we can free resources during reassembly, the better.

Ok, but there is another situation we could do the same ?

 if ((unsigned int)end > IPV6_MAXPLEN) {
   ...
   return -1;
}



>
> Signed-off-by: Fernando Fernandez Mancera <fmancera@suse.de>
> ---
>  net/ipv6/reassembly.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/net/ipv6/reassembly.c b/net/ipv6/reassembly.c
> index 25ec8001898d..8b0bc0ba56f4 100644
> --- a/net/ipv6/reassembly.c
> +++ b/net/ipv6/reassembly.c
> @@ -163,6 +163,9 @@ static int ip6_frag_queue(struct net *net,
>                          * this case. -DaveM
>                          */
>                         *prob_offset = offsetof(struct ipv6hdr, payload_len);
> +                       inet_frag_kill(&fq->q, refs);
> +                       __IP6_INC_STATS(net, ip6_dst_idev(skb_dst(skb)),
> +                                       IPSTATS_MIB_REASMFAILS);
>                         return -1;
>                 }
>                 if (end > fq->q.len) {
> --
> 2.53.0
>

Re: [PATCH net-next] ipv6: discard fragment queue if middle fragment is not 8 bytes aligned

[Fernando Fernandez Mancera]

On 2/23/26 4:42 PM, Eric Dumazet wrote:
> On Mon, Feb 23, 2026 at 4:19 PM Fernando Fernandez Mancera
> <fmancera@suse.de> wrote:
>>
>> Currently the kernel IPv6 implementation is not dicarding the fragment
>> queue upon receiving a IPv6 fragment that is not 8 bytes aligned. It
>> relies on queue expiration to free the queue.
>>
>> While RFC 8200 section 4.5 does not explicitly mention that the rest of
>> fragments must be discarded, it does not make sense to keep them. The
>> parameter problem message is sent regardless that. In addition, if the
>> sender is able to re-compose the datagram so it is 8 bytes aligned it
>> would qualify as a new whole datagram not fitting into the same fragment
>> queue.
>>
>> The sooner we can free resources during reassembly, the better.
> 
> Ok, but there is another situation we could do the same ?
> 
>   if ((unsigned int)end > IPV6_MAXPLEN) {
>     ...
>     return -1;
> }
> 

Hi Eric,

Yes. That is right. I missed it when reviewing the function. Will handle 
that case in a V2.


Thanks,
Fernando.