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

[Willem de Bruijn]

Paolo Abeni wrote:
> 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.

+1, see the documentation on how to report and help address potential
vulnerabilities at

    https://docs.kernel.org/process/security-bugs.html 

Do not just send reports of unfixed bugs to a public list.