Re: [PATCH net v3 2/4] psp: support ipv6 extension headers in psp_dev_rcv() decap

["Daniel Zahka" <daniel.zahka@gmail.com>]

On Mon Oct 26, 2026 at 6:05 PM EDT, Todd Bert Freed wrote:
>> [Severity: High]
>>
>> The PSP ICV doesn't cover the outer IPv6 header or its extension headers.
>> An on-path attacker could take a captured PSP packet, insert one of these
>> headers, and set saddr to an address they control. This assumes the
>> device authenticates such packets, which this patch's premise implies.
>>
>> Several of those handlers reply with an ICMPv6 error that quotes the
>> packet. With default sysctls, this happens for an unrecognized routing
>> header type (type 0, for example) with segments_left != 0:
>>
>> Before this patch, all of these packets were dropped at the is_udp check.
>> Forwarding the decrypted skb itself looks blocked by
>> sk_validate_xmit_skb() ("unencrypted skb with no associated socket -
>> dropping"). That leaves the ICMP error path as the open channel.
>
> Agree with this finding.
>
> Ok, this puts me back in mind of the approach in v0 of this series ; just drop
> packets with extension headers. Actual support for extension headers can be
> done separately from this fix.
>
> pw-bot: cr
>
> -Todd

Like Jakub points out, this equally could affect tls offload. We need to
be careful with any features that can result in device-decrypted data
being sent back onto the network. Another gap that exists currently is
xdp tx or redirect. That would also affect both PSP and TLS offload. I
think we should try and make these features work with crypto offload,
rather than building up more and more defensive checks.