Re: [PATCH v4 2/5] io_uring/cmd: zero-init pdu in io_uring_cmd_prep() to avoid UB
From: Sidong Yang
Date: Sat Apr 11 2026 - 08:20:53 EST
On Thu, Apr 09, 2026 at 07:27:18AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 08, 2026 at 01:59:59PM +0000, Sidong Yang wrote:
> > The pdu field in io_uring_cmd may contain stale data when a request
> > object is recycled from the slab cache. Accessing uninitialized or
> > garbage memory can lead to undefined behavior in users of the pdu.
>
> Who accesses this? If that happens, then yes this is a problem, but if
> not, then there's no need for this change, right (i.e. either this is a
> bug to be fixed now or not.)
Hi Greg,
Thank you for the review.
You are right, this patch is not fixing an existing bug. I added it
because the Rust abstraction provides read_pdu() which reads from the
PDU, and without zero-initialization a Rust caller could observe stale
data from a recycled slab object. While "stale but valid" might be
harmless in C, in Rust we want to guarantee a clean initial state.
That said, I realize this is a C-side change that is only motivated by
the Rust side. I will drop this patch from the series and handle
zero-initialization within the Rust miscdevice vtable wrapper instead
(which the current code already does).
Thanks,
Sidong
>
> > Ensure the pdu buffer is cleared during io_uring_cmd_prep() so that
> > each command starts from a well-defined state. This avoids exposing
> > uninitialized memory and prevents potential misinterpretation of data
> > from previous requests.
>
> Where is the memory exposed and who misinterprets it?
>
> > No functional change is intended other than guaranteeing that pdu is
> > always zero-initialized before use.
>
> This strongly implies that this is not needed at all.
>
> thanks,
>
> greg k-h