On Mon Nov 17, 2025 at 10:56 AM CET, Louis Chauvet wrote: > > > On 11/13/25 14:21, José Expósito wrote: >> On Wed, Oct 29, 2025 at 03:36:43PM +0100, Louis Chauvet wrote: >>> Planes can have name, create a plane attribute to configure it. Currently >>> plane name is mainly used in logs. >>> >>> Signed-off-by: Louis Chauvet <[email protected]> >>> --- >>> Documentation/gpu/vkms.rst | 3 ++- >>> drivers/gpu/drm/vkms/vkms_configfs.c | 32 ++++++++++++++++++++++++++++++++ >>> 2 files changed, 34 insertions(+), 1 deletion(-) >>> >>> diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst >>> index 3574e01b928d..1fe6e420c963 100644 >>> --- a/Documentation/gpu/vkms.rst >>> +++ b/Documentation/gpu/vkms.rst >>> @@ -87,10 +87,11 @@ Start by creating one or more planes:: >>> >>> sudo mkdir /config/vkms/my-vkms/planes/plane0 >>> >>> -Planes have 1 configurable attribute: >>> +Planes have 2 configurable attributes: >>> >>> - type: Plane type: 0 overlay, 1 primary, 2 cursor (same values as those >>> exposed by the "type" property of a plane) >>> +- name: Name of the plane >> >> I'd like to mention again my comment on limiting the name to a set of >> well-known characters [1]. >> >> The reason is that, in libinput, we had a format string vulnerability >> due to the kernel exposing devices with names containing strings like >> "%s" in the name (CVE-2022-1215): >> https://gitlab.freedesktop.org/libinput/libinput/-/issues/752 >> >> In my opinion, we should avoid surprising user-space too much and allow >> only a set of "safe" characters. >> >> Maybe I'm too cautious, as this is valid code, but I'd like to bring up >> the discussion again to see if someone else agrees or disagrees. >> >> [1] https://lore.kernel.org/all/aPtgCUX5kixTh2ua@fedora/ > > Sorry, I completely forgot to send my mail drafts for your comments... > It was mainly "Will do for v2" except here: > > > For me this should not be a kernel concern, when the userspace read a > file/folder name, it can be anything, so the userspace should do the > proper sanitization. > > For libinput it was "easy" to exploit because unauthenticated users can > create any device name, but for VKMS, you must already be a > "privilegied" user (can write to configfs). I don't see the added value > for a kernel-side limitation, it will be more code for almost no > security improvement. > > If you really think this is important, do you know if the kernel have a > helper to do this kind of checks? I did not found anything in strings.h > and I don't want to implement it in VKMS.
I tend to agree with José here, being strict on accepted input is good. I guess you can stick to [A-Za-z0-9_-], then if there is a good reason to relax the constraint it can be done later. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
