linux-kernel - Re: [PATCH 2/2] vduse: fix compat handling for VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260203053142-mutt-send-email-mst@kernel.org>
Date: Tue, 3 Feb 2026 05:35:20 -0500
From: "Michael S. Tsirkin" <mst@...hat.com>
To: Arnd Bergmann <arnd@...db.de>
Cc: Eugenio Pérez <eperezma@...hat.com>,
	Arnd Bergmann <arnd@...nel.org>, Jason Wang <jasowang@...hat.com>,
	Xie Yongji <xieyongji@...edance.com>,
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>,
	Anders Roxell <anders.roxell@...aro.org>,
	Marco Crivellari <marco.crivellari@...e.com>,
	virtualization@...ts.linux.dev, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] vduse: fix compat handling for
 VDUSE_IOTLB_GET_FD/VDUSE_VQ_GET_INFO

On Mon, Feb 02, 2026 at 11:54:17PM +0100, Arnd Bergmann wrote:
> On Mon, Feb 2, 2026, at 17:45, Michael S. Tsirkin wrote:
> > On Mon, Feb 02, 2026 at 12:59:03PM +0100, Arnd Bergmann wrote:
> >
> > I think .compat_ioctl would be cleaner frankly. Just look at
> > all the ifdefery. And who knows what broken-ness userspace
> > comes up with with this approach. Better use the standard approach.
> 
> Sent now.
> 
> I'm not sure it's much better because there is quite a bit of
> code duplication, and reducing that would be a larger rework.

yes but on the flip side, we can put it all inside ifdef CONFIG_COMPAT
(which this code did not do, but should IMHO).

> It may be best to hold off on patch 2 for the coming merge window
> since the compat ioctl code has apparently always been broken for
> x86 here.

And it needs testing.

> I hope we can at least get patch 1/2 merged along with the
> new code though, otherwise it would get a lot harder to sort
> it out properly, with the v2 struct members overlapping the
> old padding fields.
> 
>      Arnd

Along with it or no, surely before the release.
Given 32 on 64 with this apparently has been broken forever,
I will merge this just based on even you did not bother testing compat, I am
inclined to say I am merging this but not rebasing because
of this.

Oh and we got lucky this didn't leak kernel stack info.

Eugenio, note for the future: please help make sure UAPI
structs do not have hidden padding.

-- 
MST