Re: [PATCH RESEND v2 06/32] drm/vkms: Introduce configfs for plane name

Luca Ceresoli
2025-12-18T17:58:51Z

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 <louis.chauvet@bootlin.com>
>>> ---
>>> 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