All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andreas Hindborg <a.hindborg@kernel.org>
To: "Breno Leitao" <leitao@debian.org>,
	"Miguel Ojeda" <ojeda@kernel.org>,
	"Boqun Feng" <boqun@kernel.org>,
	"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
	"Benno Lossin" <lossin@kernel.org>,
	"Alice Ryhl" <aliceryhl@google.com>,
	"Trevor Gross" <tmgross@umich.edu>,
	"Danilo Krummrich" <dakr@kernel.org>,
	"Daniel Almeida" <daniel.almeida@collabora.com>,
	"Tamir Duberstein" <tamird@kernel.org>,
	"Alexandre Courbot" <acourbot@nvidia.com>,
	"Onur Özkan" <work@onurozkan.dev>
Cc: Gary Guo <gary@garyguo.net>,
	Priya Bala Govindasamy <pgovind2@uci.edu>,
	rust-for-linux@vger.kernel.org, linux-kernel@vger.kernel.org,
	kernel-team@meta.com, Breno Leitao <leitao@debian.org>
Subject: Re: [PATCH] configfs: zero the write buffer on allocation
Date: Mon, 19 Oct 2026 14:35:06 +0200	[thread overview]
Message-ID: <87cxt5dg1x.fsf@kernel.org> (raw)
In-Reply-To: <20261015-b4-configfs_kzalloc-v1-1-17c1ba6db062@debian.org>

Breno Leitao <leitao@debian.org> writes:

> fill_write_buffer() allocates the per-open buffer page with kmalloc()
> and initializes only the bytes copied from userspace plus the
> terminating NUL. fill_read_buffer() reuses that page if it is already
> allocated.
>
> After a write, a read on the same file descriptor therefore passes
> ->show() a page that still holds stale heap data. A ->show() that
> returns only what it wrote never notices, but one that returns a length
> covering bytes it did not write leaks that data to userspace.
>
> The Rust bindings are exposed more directly: ->show() receives the page
> as an &mut [u8; PAGE_SIZE], so a driver can read the uninitialized
> bytes.
>
> fill_read_buffer() already allocates the same page with kzalloc(). Do
> the same here, so the page is initialized whichever path allocates it.
> The cost is zeroing one page the first time a file is written.
>
> Link: https://lore.kernel.org/r/cover.1790981219.git.pgovind2@uci.edu
> Suggested-by: Andreas Hindborg <a.hindborg@kernel.org>
> Signed-off-by: Breno Leitao <leitao@debian.org>

Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>


Best regards,
Andreas Hindborg



      reply	other threads:[~2026-10-19 12:35 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-15 13:20 [PATCH] configfs: zero the write buffer on allocation Breno Leitao
2026-10-19 12:35 ` Andreas Hindborg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87cxt5dg1x.fsf@kernel.org \
    --to=a.hindborg@kernel.org \
    --cc=acourbot@nvidia.com \
    --cc=aliceryhl@google.com \
    --cc=bjorn3_gh@protonmail.com \
    --cc=boqun@kernel.org \
    --cc=dakr@kernel.org \
    --cc=daniel.almeida@collabora.com \
    --cc=gary@garyguo.net \
    --cc=kernel-team@meta.com \
    --cc=leitao@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lossin@kernel.org \
    --cc=ojeda@kernel.org \
    --cc=pgovind2@uci.edu \
    --cc=rust-for-linux@vger.kernel.org \
    --cc=tamird@kernel.org \
    --cc=tmgross@umich.edu \
    --cc=work@onurozkan.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.