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: CLOSED ERRATA
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: F45BetaBlocker
TreeView+ depends on / blocked
 
Reported: 2026-08-27 13:14 UTC by Jaroslav Groman
Modified: 2026-09-10 20:04 UTC (History)
4 users (show)

Fixed In Version: kmscon-10.0.3-2.fc45
Clone Of:
Environment:
Last Closed: 2026-09-10 20:04:08 UTC
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 (Red Hat) 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.

Comment 15 Fedora Update System 2026-09-10 20:04:08 UTC
FEDORA-2026-756d8c0914 (kmscon-10.0.3-2.fc45) has been pushed to the Fedora 45 stable repository.
If problem still persists, please make note of it in this bug report.


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