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

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

[Cheng Yongkang]

Hi all,

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.

Thanks,
Cheng Yongkang

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

[Paolo Abeni]

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