Re: [BUG] net: tun: zero-copy path can expose uninitialized packet data

[Paolo Abeni <pabeni@redhat.com>]

On 10/22/26 11:18, Cheng Yongkang wrote:
> The experimental vhost-net TX zero-copy path can hand TUN a user buffer
> whose effective vhost virtio header size is smaller than the TUN
> device's configured vnet_hdr_sz.  TUN computes an skb copylen that
> remains larger than the bytes actually available after stripping its
> configured header, publishes skb->len from that copylen, and
> zerocopy_sg_from_iter() initializes only the real payload.
> 
> The resulting frame contains an uninitialized tail.  The tail can be
> read by userspace from the TAP peer through normal forwarding.
> 
> Observed on Linux v7.3, commit
> 08ab31164c55f20c7a2653de3186ae333470e2c1, with:
> 
>    init_on_alloc=0
>    vhost_net.experimental_zcopytx=1
>    TAP vnet_hdr_sz=200
>    vhost TX total length=256
>    real payload length=56
>    TUN copylen / skb len=128
> 
> The exact control with vnet_hdr_sz=10 delivered the expected 246-byte
> frame.  The corrected trigger delivered 128 bytes after submitting only
> 56 payload bytes.
> 
> Sixteen of sixteen corrected triggers produced the overlong skb.
> Eleven of sixteen had nonzero bytes in the 72-byte uninitialized tail.
> Several contained recognizable stale kernel allocation content from
> previous skbuff_small_head users, including fragments of environment
> entries.  Those bytes were never supplied in the virtio TX buffer.
> 
> This is a userspace-observable kernel-memory disclosure on a
> network-forwarding path.  It is configuration-gated by experimental
> zero-copy and an enlarged TAP vnet header, but the overlong skb occurs
> regardless of init_on_alloc; init_on_alloc=0 is needed to observe the
> stale tail in this test build.
> 
> This is distinct from candidate BR-023/BR-025, which exercise
> IFF_NAPI_FRAGS.  This reproducer uses the non-frags tun_alloc_skb() /
> zerocopy_sg_from_iter() branch.
> 
> I found no direct upstream fix or CVE.
> 
> The vhost ring reproducer and complete program/console logs are
> available on request.
> 
> This was found with a multi-agent workflow; the
> information disclosure was reproduced in QEMU/KVM.
Please stop this AI-generated test-walls dump: it's not very helpful
except for other agents consumption.

Really, please stop now.

Please instead ask your LLMs to try to generated fixes for each of them,
manually review the generate code if you have the skills, and share
the patches on the ML, at a very limited rated (no more than a couple
of series in flight at any given time, with no more than an handful of
patches overall).

Please consider collaborating with other already in place projects
(i.e. nebusec) to make you finding available to the community in a
responsible way.

Thanks,

Paolo