• File: sys/dev/misc/kbd/kbd.c
• Lines: 839, 841, 853, 854
• Severity: Low
• CVSS: CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H
• CWE: CWE-476 NULL Pointer Dereference
• Confidence: likely

Summary

genkbdkqfilter and genkbdfiltdetach dereference dev->si_drv1 without a NULL check, unlike their sibling genkbdfilter (kbd.c:867-869) which correctly tests (sc == NULL).

kbd_detach frees and NULLs si_drv1 unconditionally (kbd.c:598-600) without checking whether the device is open or has knotes registered.

If the keyboard is detached while a process still holds /dev/kbdN open with a registered EVFILT_READ knote, the next kqfilter-attach or kq-close dereferences NULL and panics.

Root cause

sys/dev/misc/kbd/kbd.c:839-841 (genkbdkqfilter):

sc = dev->si_drv1;
klist = &sc->gkb_rkq.ki_note;
knote_insert(klist, kn);

— sc is dereferenced immediately.

kbd.c:853-854 (genkbdfiltdetach): same pattern.

Contrast with kbd.c:867-869 (genkbdfilter):

sc = dev->si_drv1;
...
if ((sc == NULL) || (kbd == NULL) || !KBD_IS_VALID(kbd)) { ... }

kbd.c:597-602 (kbd_detach) frees and NULLs si_drv1 without consulting KB_BUSY, the open count, or the knote list.

Threat

Trigger requires (a) an open fd on /dev/kbdN (which requires root + RESTRICTEDROOT per genkbdopen kbd.c:672) and (b) the underlying keyboard to be detached while that fd is live — plausible for USB keyboards on unplug (ukbd disconnect path) or for an administrator forcing kldunload of an atkbd/kbdmux module.

The open fd continues to reference the cdev_t because devfs reference-counts it past dev_ops_remove_minor (kbd.c:604).

A subsequent kqfilter(2) on the fd, or close of the kq after the keyboard went away, dereferences NULL sc and panics the kernel.

Pure local DoS; no memory corruption.

Exploit / PoC

On DragonFlyBSD as root:

1. int fd = open("/dev/kbd0", O_RDWR); int kq = kqueue(); struct kevent e; EV_SET(&e, fd, EVFILT_READ, EV_ADD, 0, 0, NULL); kevent(kq, &e, 1, NULL, 0, NULL); (registers a knote while the keyboard is still attached — genkbdkqfilter succeeds).
2. Force the keyboard to detach: kldunload atkbd (or unplug a USB keyboard whose ukbd was the backing device). kbd_detach runs, si_drv1 becomes NULL.
3. Close the kq: close(kq);. The kernel invokes genkbdfiltdetach, which executes sc = dev->si_drv1; klist = &sc->gkb_rkq.ki_note; and panics with fatal trap 12: page fault at *(NULL + offsetof(gkb_rkq)).

If kldunload is refused because the device is busy, the USB-unplug variant is the realistic trigger.

If knote registration is attempted after detach instead of before, genkbdkqfilter itself is the deref site.

Recommended fix

Mirror the defensive pattern already used in genkbdfilter.

--- a/sys/dev/misc/kbd/kbd.c
+++ b/sys/dev/misc/kbd/kbd.c
@@ -827,6 +827,12 @@ genkbdkqfilter(struct dev_kqfilter_args *ap)

    ap->a_result = 0;

+   sc = dev->si_drv1;
+   if (sc == NULL) {
+       ap->a_result = ENXIO;
+       return (0);
+   }
+
    switch (kn->kn_filter) {
    case EVFILT_READ:
        kn->kn_fop = &genkbdfiltops;
@@ -836,9 +842,8 @@ genkbdkqfilter(struct dev_kqfilter_args *ap)
        return (0);
    }

-   sc = dev->si_drv1;
    klist = &sc->gkb_rkq.ki_note;
    knote_insert(klist, kn);
@@ -852,6 +857,11 @@ genkbdfiltdetach(struct knote *kn)
    struct klist *klist;

    sc = dev->si_drv1;
+   /* the keyboard may have been detached under us */
+   if (sc == NULL) {
+       knote_revoke(kn);
+       return;
+   }
    klist = &sc->gkb_rkq.ki_note;
    knote_remove(klist, kn);

(If knote_revoke is not the correct primitive on this tree, simply returning without removing — the knote was never inserted into a live klist because si_drv1 was NULL — is sufficient; knote_insert runs under the same open-fd precondition, so a NULL sc at detach time means the knote was either never inserted or has already been invalidated.)

Related findings

• DF-1503 (sibling): SETFKEY signed flen overflow in same file.
• DF-1504 (sibling): genkbd_get_fkeystr off-by-one in same file.