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

[Louis Chauvet <louis.chauvet@bootlin.com>]

On 12/18/25 18:58, Luca Ceresoli wrote:
> 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.

I don't have very strong opinion, I will add this!

> Luca
> 
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com