What each bug does to a running system, what the report shows, and what has to be worked out to fix it properly.
EASY
A USB hub freed while its interrupt is still using it
CVE-2026-80830 · drivers/usb
A USB 3 device behind an external hub wakes the computer at the same instant the hub is unplugged. The USB 3 controller's interrupt handler tells the USB core about the wakeup, and the core reaches into the hub's data. But on another CPU the hub is being torn down and its memory freed. The interrupt reads freed memory: a use-after-free, the class of bug most often turned into a kernel exploit.
What the report shows
A KASAN use-after-free inside the USB core's wakeup notification, called from the xHCI interrupt, and the hub-disconnect path that freed the memory. It names both sides of the race but not why they collide.
What has to be worked out
- What protects a hub's data while it is being disconnected, and whether the interrupt path honours it
- Every caller of the wakeup notification, and whether any of them can run in interrupt context
- A fix that is safe to take from inside an interrupt handler
BUG: KASAN: slab-use-after-free in usb_wakeup_notification
Call Trace: <IRQ> usb_wakeup_notification ← handle_port_status [xhci_hcd] ← xhci_irq
Freed by: kfree ← hub_disconnect ← usb_unbind_interface ← … ← usb_disconnect ← hub_event
Why this is impressive
The USB core and the xHCI driver together are over 52,000 lines, and the hub file alone is 6,500. The crash line looks perfectly ordinary. Seeing the bug means knowing the rule the rest of the USB core follows when it touches a hub that might be disappearing, and noticing the one path, running in an interrupt, that skips it. Nothing at the crash site states that rule; it has to be discovered from how the rest of the code behaves.
Result: solved. In under six minutes and 89K tokens of context SuperSmart Coder found the cause and wrote a fix that matches the fix the kernel developers shipped: the same lock, held over the same lines. The decisive step was checking every one of the 262 places across the kernel that touch the hub's port count, in 7 seconds. That showed a single writer, which holds the hub lock, against 16 reads in interrupt context that do not, this one among them. That is what turns a plausible fix into a complete one: there is no other writer anywhere to worry about. To be fair, this is the easy bug: both halves of the race are in one file, and the report names both functions, so careful reading could have found it too. The kernel-wide check is what grep cannot give you.
MEDIUM
A crafted request that corrupts a filesystem's dirty-page list
CVE-2026-80807 · fs/nilfs2
nilfs2 is a log-structured filesystem with a garbage collector that runs partly in user space. A program can ask the kernel to move blocks during cleaning. If it passes a block number at the very top of the 64-bit range, the kernel happily caches a page at index ULONG_MAX. Later, when the filesystem's background thread writes dirty pages back, the page search wraps around past the end of the index space, finds the same page twice, and adds the same buffer to a list twice. The kernel stops with a list-corruption BUG.
What the report shows
The crash, in the background write-out thread of segment.c. Nothing in the trace mentions a user request, a garbage collector or an ioctl. The only hint is that the reproducer "issues ioctls".
What has to be worked out
- How one page could be found twice by a search that should see each page once
- Which of the filesystem's 26 ioctl commands lets a user decide where a page is cached
- Exactly which fields need a range check, and what the safe limit is
list_add double add … kernel BUG at lib/list_debug.c:35!
Call Trace: nilfs_lookup_dirty_data_buffers ← nilfs_segctor_scan_file ← … ← nilfs_segctor_thread ← kthread
(stack as we reconstructed it; see the result below)
Why this is impressive
The crash and the cause happen at different times, in different threads, in different files (2,900 lines of segment.c on one side, 1,350 lines of ioctl.c on the other), joined only through the kernel's page cache. Searching the code for the crashing function leads nowhere near the bug. Getting there means reasoning backwards from "this page appears twice" to "which user-controlled value decides a page's position", across a 21,000-line filesystem and the memory-management code beneath it.
Result: partly solved. In twelve minutes SuperSmart Coder worked out the exact mechanism the kernel developers described: a page cached at the very last index, a search that wraps around and finds it twice, the same buffer added twice. It then traced a way for a crafted disk image to plant that page during mount, and fixed that path; the fix compiles and passes the checks. The developers fixed a different entry point, the garbage-collection request. SuperSmart Coder found that path too and recommended bounding it, but set it aside because the stack trace we supplied did not match it. That trace was our reconstruction, not syzbot's original, and it pointed the wrong way. One of SuperSmart's checks also failed to follow the user's request into the page index, which would have led straight to the developers' fix. That is now the first thing on our list to improve.
HARD
A cluster filesystem that sleeps while holding a spinlock
CVE-2026-89491 · fs/ocfs2/cluster
OCFS2 is a filesystem shared by several machines at once. Each node writes a heartbeat to shared disks so the cluster knows who is alive. When a volume is mounted, the heartbeat code pins its disk regions so nobody can remove them, and does it while holding a spinlock, a lock that forbids sleeping. Somewhere far below, pinning has to take a lock that can sleep. With the kernel's debug checks on, that is an immediate BUG; without them, it is a latent hang. The same code also creates a lock-order inversion with configfs that can deadlock, and leaks a counter when pinning fails halfway.
What the report shows
Only the warning text: a sleeping function was called from an invalid context, during mount and when removing a heartbeat region. No stack trace. A vague lockdep complaint about configfs inode locks. And "regions stay unprotected after a failed mount".
What has to be worked out
- Which of the 29 places in the heartbeat code that take this spinlock leads to something that sleeps
- The full call chain from the cluster code, through the node manager, into configfs, where the sleep actually happens
- A fix that drops the spinlock safely, keeps pin and unpin from racing, does not invert lock order, and does not leak on failure
BUG: sleeping function called from invalid context (in a sleeping lock)
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2231, name: mount.ocfs2
(no stack trace captured)
Why this is impressive
Nothing at the scene looks wrong: the function that sleeps is in configfs, a different directory, and the function holding the spinlock never sleeps itself. Whether a call can sleep is a property of everything it might call, all the way down, across an 83,000-line filesystem and the subsystems under it. Answering that by reading means opening file after file and following every branch by hand. This bug also has three intertwined defects, and a fix that addresses only the obvious one leaves the deadlock and the leak in place.
Result: starting shortly.
