Re: [PATCH RFC net-next 4/9] net: reuse skb_shared_hwtstamps for BPF Timestamping v2

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] net: BPF start_time breaks SOF_TIMESTAMPING_RAW_HARDWARE and namespace isolation
- [Medium] net: hardware TX timestamps overwrite start_time breaking BPF latency tracking
--

commit a3500c380740df14fa2b49c448a409fd50a64d25
Author: Jason Xing <kerneljasonxing@gmail.com>

net: reuse skb_shared_hwtstamps for BPF Timestamping v2

This commit reuses the hwtstamp field in skb_shared_hwtstamps to store a
software start time for BPF Timestamping V2. A start_time union member is
added that shares storage with hwtstamp.

> diff --git a/include/linux/skbuff.h b/include/linux/skbuff.h
> index 0f4a4f4bafb2a..275c797f6a4b5 100644
> --- a/include/linux/skbuff.h
> +++ b/include/linux/skbuff.h
[ ... ]
> @@ -462,6 +468,7 @@ static inline bool skb_frag_must_loop(struct page *p)
>  struct skb_shared_hwtstamps {
>  	union {
>  		ktime_t	hwtstamp;
> +		ktime_t	start_time;

[Severity: High]
Could unioning start_time and hwtstamp impact SOF_TIMESTAMPING_RAW_HARDWARE
and namespace isolation?

When BPF Timestamping v2 is enabled via bpfts_v2_needed_key,
net_timestamp_check() populates start_time for received packets lacking a
hardware timestamp. Because they share memory, __sock_recv_timestamp() sees
this as a non-zero hwtstamp.

Applications requesting SOF_TIMESTAMPING_RAW_HARDWARE (such as PTP daemons)
will erroneously receive the software-generated start_time as a real hardware
timestamp in tss.ts[2], which could corrupt clock servos.

Furthermore, skb_scrub_packet() clears skb->tstamp to prevent timing leaks
across namespaces, but it does not clear skb_hwtstamps(). Smuggling a
software timestamp in the hardware timestamp union appears to bypass
namespace isolation.

[Severity: Medium]
Will hardware TX timestamps overwrite start_time and affect BPF latency
tracking?

BPF Timestamping V2 intends to measure latency by stamping start_time upon
packet enqueue. When a hardware TX timestamp is received, __skb_tstamp_tx()
calls skb_tstamp_tx_report_bpf_timestamping(), which assigns:

    *skb_hwtstamps(skb) = *hwtstamps;

before invoking the BPF program via bpf_skops_tx_timestamping().

Because start_time shares the same union as hwtstamp, this assignment
overwrites the enqueue start_time with the TX completion time before the BPF
program runs on the BPF_SOCK_OPS_TSTAMP_SND_HW_CB hook.

Could this cause the BPF program to read the hardware timestamp instead of
the original start_time, preventing correct latency calculations?

>  		void *netdev_data;
>  	};
>  };

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260919143732.11772-1-kerneljasonxing@gmail.com?part=4