Bug 2524952 - kmscon: NULL pointer dereference in seat_monitor_hotplug_dev when DRM device fails to initialize
Summary: kmscon: NULL pointer dereference in seat_monitor_hotplug_dev when DRM device ...
Keywords:
Status: VERIFIED
Alias: None
Product: Fedora
Classification: Fedora
Component: kmscon
Version: 45
Hardware: Unspecified
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Jocelyn Falempe
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: AcceptedBlocker
Depends On:
Blocks: BetaBlocker, F45BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2026-08-27 13:14 UTC by Jaroslav Groman
Modified: 2026-09-05 02:16 UTC (History)
4 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed:
Type: ---
Embargoed:


Attachments (Terms of Use)
Fedora-Xfce-Disk-Rawhide-20260903.n.0.aarch64 bootlog (208.09 KB, text/plain)
2026-09-03 08:46 UTC, Jaroslav Groman
no flags Details
Fedora-Minimal-45_Beta-1.2.aarch64 bootlog (224.58 KB, text/plain)
2026-09-04 10:51 UTC, Jaroslav Groman
no flags Details

Description Jaroslav Groman 2026-08-27 13:14:20 UTC
kmscon crashes with SIGSEGV when a udev "change" (hotplug) event arrives for
a DRM device that failed to initialize. The crash occurs because neither
seat_monitor_hotplug_dev() nor kmscon_seat_poll_video() check for NULL
dev_data before dereferencing it.

When a DRM device fails seat_video_init() during the initial scan,
kmscon_seat_add_video() correctly sets dev->data to NULL and frees the
kmscon_video struct. The device remains in the monitor's device list. When
udev subsequently sends a "change" event for that device (e.g., HDMI hotplug),
monitor_udev_change() calls:

    sdev->mon->cb.hotplug_dev(sdev->mon->data, sdev->type, sdev->data);

with sdev->data == NULL, which reaches:

    static void seat_monitor_hotplug_dev(..., void *dev_data)
    {
        if (type == UTERM_MONITOR_DRM || type == UTERM_MONITOR_FBDEV)
            kmscon_seat_poll_video(dev_data);  // dev_data is NULL
    }

    static void kmscon_seat_poll_video(void *data)
    {
        struct kmscon_video *vid = data;  // NULL
        video_poll(vid->video);           // SIGSEGV
    }

This is easily reproducible on Raspberry Pi 4 which has a V3D render-only
DRM device (/dev/dri/card1) that lacks dumb buffer support, causing
seat_video_init() to fail with -EOPNOTSUPP.

Version-Release number of selected component:
kmscon-10.0.2-2.fc45.aarch64


Reproducible: Always

Steps to Reproduce:
1. Boot aarch Xfce Fedora 45 Branched 20260826.n.0 on Raspberry Pi 4 Model B
2. kmscon starts (either kmsconvt@tty1 or via initial-setup.service)
3. kmscon fails to init /dev/dri/card1 (V3D, no dumb buffer support)
4. udev sends a "change" event for card1 (e.g., hotplug notification)
5. kmscon crashes with SIGSEGV in monitor_udev_event

Actual Results:
kmscon crashes with SIGSEGV in monitor_udev_event preventing whatever was running in it from completion

Expected Results:
kmscon does not crash

Additional Information:
Crash stack trace:
#0  monitor_udev_event (kmscon + 0x192ec)
#1  ev_eloop_dispatch (kmscon + 0xd318)
#2  main (kmscon + 0x9fac)

Relevant journal output:
kmscon: ERROR: video_drm2d: driver does not support dumb buffers
kmscon: ERROR: seat: cannot create video device /dev/dri/card1 on seat seat0: -95

Suggested fix in src/seat.c:

1. Add NULL check in seat_monitor_hotplug_dev():

    if (type == UTERM_MONITOR_DRM || type == UTERM_MONITOR_FBDEV)
   -    kmscon_seat_poll_video(dev_data);
   +    if (dev_data)
   +        kmscon_seat_poll_video(dev_data);

2. Add NULL check in kmscon_seat_poll_video() as defense-in-depth:

    struct kmscon_video *vid = data;
   +if (!vid)
   +    return;
    log_debug("poll video device %s on seat %s", vid->node, vid->seat->name);
    video_poll(vid->video);

Comment 1 Jaroslav Groman 2026-08-28 10:43:36 UTC
PR submitted: https://github.com/kmscon/kmscon/pull/513

Comment 2 Fedora Blocker Bugs Application 2026-08-31 15:33:09 UTC
Proposed as a Freeze Exception for 45-beta by Fedora user jgroman using the blocker tracking app because:

 Fixes kmscon crashes with initial-setup on RPi4 (and possibly some other specific HW)

Comment 3 Jaroslav Groman 2026-08-31 16:04:56 UTC
Fix verified working on my HW.

Comment 4 Lukas Ruzicka (Red Hat) 2026-08-31 17:54:31 UTC
AGREED AcceptedBetaBlocker

Discussed at the 2026-08-31 (blocker / freeze exception) review meeting:

This is accepted as a blocker (not FE) because it can easily cause text mode initial setup to crash before a user account can be created, rendering the system inaccessible. Text mode initial setup is used in the release-blocking aarch64 minimal disk image.

https://meetbot-raw.fedoraproject.org//blocker-review_matrix_fedoraproject-org/2026-08-31/f45-blocker-review.2026-08-31-16.01.log.txt

Comment 5 Fedora Update System 2026-09-01 12:13:35 UTC
FEDORA-2026-45ebe41ba6 (kmscon-10.0.3-1.fc45) has been submitted as an update to Fedora 45.
https://bodhi.fedoraproject.org/updates/FEDORA-2026-45ebe41ba6

Comment 6 Fedora Update System 2026-09-02 02:21:54 UTC
FEDORA-2026-45ebe41ba6 has been pushed to the Fedora 45 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-45ebe41ba6`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-45ebe41ba6

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 7 Adam Williamson (Fedora) 2026-09-02 17:17:14 UTC
Jaroslav, can you test this one too? Again, easiest thing to do is likely just to test next Rawhide compose.

Comment 8 Jaroslav Groman 2026-09-03 08:46:07 UTC
Yes, I can confirm that on Fedora-Xfce-Disk-Rawhide-20260903.n.0.aarch64 this problem is fixed.
The source of the "hotplug" event is likely late-loading vc4 driver.

kmscon apparently needs a few more SELinux tweaks on this image, but it is not crashing anymore.
Also weston spawned through kmscon seems to not have access to DRM devices so initial-setup still
does not work but this is outside of scope of this bug.

Attaching boot log.

Comment 9 Jaroslav Groman 2026-09-03 08:46:55 UTC
Created attachment 2156525 [details]
Fedora-Xfce-Disk-Rawhide-20260903.n.0.aarch64 bootlog

Comment 10 Adam Williamson (Fedora) 2026-09-03 15:48:12 UTC
Did you file new bugs for the newly-exposed issues? Thanks!

Comment 11 Jaroslav Groman 2026-09-04 10:50:42 UTC
(In reply to Adam Williamson (Fedora) from comment #10)
> Did you file new bugs for the newly-exposed issues? Thanks!

I think the problem would  belong to https://bugzilla.redhat.com/show_bug.cgi?id=2358688
I'll update it with the latest status.

Also verified the fix on Fedora-Minimal-45_Beta-1.2.aarch64, attaching bootlog.

Comment 12 Jaroslav Groman 2026-09-04 10:51:16 UTC
Created attachment 2156692 [details]
Fedora-Minimal-45_Beta-1.2.aarch64 bootlog

Comment 13 Kamil Páral 2026-09-04 11:26:53 UTC
Setting as verified per comment 11

Comment 14 Fedora Update System 2026-09-05 02:16:14 UTC
FEDORA-2026-756d8c0914 has been pushed to the Fedora 45 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2026-756d8c0914`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2026-756d8c0914

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.


Note You need to log in before you can comment on or make changes to this bug.