Re: [PATCH v4 2/5] io_uring/cmd: zero-init pdu in io_uring_cmd_prep() to avoid UB

[Sidong Yang <sidong.yang@furiosa.ai>]

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