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 <[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.
I don't have very strong opinion, I will add this!
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
