Fedora Account System
Red Hat Associate
Red Hat Customer
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);
PR submitted: https://github.com/kmscon/kmscon/pull/513
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)
Fix verified working on my HW.
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
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
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.
Jaroslav, can you test this one too? Again, easiest thing to do is likely just to test next Rawhide compose.
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.
Created attachment 2156525 [details] Fedora-Xfce-Disk-Rawhide-20260903.n.0.aarch64 bootlog
Did you file new bugs for the newly-exposed issues? Thanks!
(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.
Created attachment 2156692 [details] Fedora-Minimal-45_Beta-1.2.aarch64 bootlog
Setting as verified per comment 11
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.