Re: [PATCH v6 2/6] bpf: refactor masks for ADJ_ROOM flags and encap validation

[Hudson, Nick]

> On May 4, 2026, at 12:03 PM, bot+bpf-ci@xxxxxxxxxx wrote:
> 
> !-------------------------------------------------------------------|
>  This Message Is From an External Sender
>  This message came from outside your organization.
> |-------------------------------------------------------------------!
> 
>> diff --git a/net/core/filter.c b/net/core/filter.c
>> --- a/net/core/filter.c
>> +++ b/net/core/filter.c
>> @@ -3484,15 +3484,20 @@ #define BPF_F_ADJ_ROOM_ENCAP_L3_MASK	(BPF_F_ADJ_ROOM_ENCAP_L3_IPV4 | \
>> #define BPF_F_ADJ_ROOM_DECAP_L3_MASK	(BPF_F_ADJ_ROOM_DECAP_L3_IPV4 | \
>> 					 BPF_F_ADJ_ROOM_DECAP_L3_IPV6)
>> 
>> -#define BPF_F_ADJ_ROOM_MASK		(BPF_F_ADJ_ROOM_FIXED_GSO | \
>> -					 BPF_F_ADJ_ROOM_ENCAP_L3_MASK | \
>> +#define BPF_F_ADJ_ROOM_ENCAP_MASK	(BPF_F_ADJ_ROOM_ENCAP_L3_MASK | \
>> 					 BPF_F_ADJ_ROOM_ENCAP_L4_GRE | \
>> 					 BPF_F_ADJ_ROOM_ENCAP_L4_UDP | \
>> 					 BPF_F_ADJ_ROOM_ENCAP_L2_ETH | \
>> 					 BPF_F_ADJ_ROOM_ENCAP_L2( \
>> -					  BPF_ADJ_ROOM_ENCAP_L2_MASK) | \
>> -					 BPF_F_ADJ_ROOM_DECAP_L3_MASK)
>> +					  BPF_ADJ_ROOM_ENCAP_L2_MASK))
>> +
>> +#define BPF_F_ADJ_ROOM_DECAP_MASK	(BPF_F_ADJ_ROOM_DECAP_L3_MASK)
>> 
>> +#define BPF_F_ADJ_ROOM_MASK		(BPF_F_ADJ_ROOM_FIXED_GSO | \
>> +					 BPF_F_ADJ_ROOM_ENCAP_MASK | \
>> +					 BPF_F_ADJ_ROOM_DECAP_MASK | \
>> +					 BPF_F_ADJ_ROOM_NO_CSUM_RESET)
>> +
>> static int bpf_skb_net_grow(struct sk_buff *skb, u32 off, u32 len_diff,
>> 			    u64 flags)
>> {
> 
> [ ... ]
> 
>> @@ -3614,8 +3619,8 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32 off, u32 len_diff,
>> 	bool decap = flags & BPF_F_ADJ_ROOM_DECAP_L3_MASK;
>> 	int ret;
>> 
>> -	if (unlikely(flags & ~(BPF_F_ADJ_ROOM_FIXED_GSO |
>> -			       BPF_F_ADJ_ROOM_DECAP_L3_MASK |
>> +	if (unlikely(flags & ~(BPF_F_ADJ_ROOM_DECAP_MASK |
>> +			       BPF_F_ADJ_ROOM_FIXED_GSO |
>> 			       BPF_F_ADJ_ROOM_NO_CSUM_RESET)))
>> 		return -EINVAL;
>> 
>> @@ -3627,6 +3632,9 @@ static int bpf_skb_net_shrink(struct sk_buff *skb, u32 off, u32 len_diff,
>> 	if (decap) {
>> 		/* Match skb->protocol to new outer l3 protocol */
>> 		if (flags & BPF_F_ADJ_ROOM_DECAP_L3_IPV6)
> 
> Martin KaFai Lau raised a concern in v5 about whether non-GSO packets
> properly handle decapsulation state clearing when bpf_skb_adjust_room()
> is used to decapsulate them. He noted this has been asked multiple
> times by AI review bots but has been ignored.
> 
> The concern is that BPF programs can call bpf_skb_adjust_room() to
> decapsulate non-GSO packets, but if skb->encapsulation remains set after
> tunnel headers are stripped, downstream network stack components could
> misinterpret the packet as still being encapsulated.
> 
> Martin noted that bpf_skb_net_grow() sets encapsulation regardless of
> skb_is_gso. Looking at the v6 patch series, the code that handles
> decapsulation state still only operates inside the skb_is_gso() block.
> 
> Should the decapsulation state clearing logic handle non-GSO packets as
> well?

It is in v6 patch 5/6.


> 
> Lore reference: https://urldefense.com/v3/__https://lore.kernel.org/bpf/2026427201356.-eYM.martin.lau@xxxxxxxxx/__;!!GjvTz_vk!XiUrW_lWa52Z6SyFVv-QsFfLyqS__CgaUR6OMrziMJ7mU0H6IHuWUsUlMlgqK4gFTRXAqFfWlwBCEnuvvZc$ 
> Reviewer: Martin KaFai Lau
> Date: Mon, 27 Apr 2026 15:19:53 -0700
> 
> [ ... ]
> 
> 
> ---
> AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
> See: https://urldefense.com/v3/__https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md__;!!GjvTz_vk!XiUrW_lWa52Z6SyFVv-QsFfLyqS__CgaUR6OMrziMJ7mU0H6IHuWUsUlMlgqK4gFTRXAqFfWlwBCf2uNDbQ$ 
> 
> CI run summary: https://urldefense.com/v3/__https://github.com/kernel-patches/bpf/actions/runs/25314425016__;!!GjvTz_vk!XiUrW_lWa52Z6SyFVv-QsFfLyqS__CgaUR6OMrziMJ7mU0H6IHuWUsUlMlgqK4gFTRXAqFfWlwBCGL7F3Rk$

Attachment: smime.p7s
Description: S/MIME cryptographic signature