TAINT_FORCED_BIND. It would mark a running kernel whenever someone uses the driver-core bind or unbind sysfs files to manually attach a device to a driver or detach it. He says he wants this because fuzzers such as syzbot have been using those files to create driver and device pairings nobody would ever run. As of September 24, 2026, this is still a patch series under review on the kernel mailing lists. It has gone through at least three revisions since August 26, and nothing reviewed here confirms it has been merged or names a kernel release that will ship it. The idea is simple: if a crash happens after someone forced a device onto a driver, the crash report should say so. That helps kernel maintainers, but the same flag would also land on hosts that use these files for VFIO passthrough and user-space networking, and that side effect is where the argument is.
Why Greg Kroah-Hartman wants TAINT_FORCED_BIND in the driver core
The reasoning appears in every version of the cover letter. Kroah-Hartman writes that the bind and unbind files were created all those decades ago as a way that kernel developers can iterate faster, and provide a debugging way for users to attempt to add a new device to a driver without having to rebuild their kernel. Then comes the complaint: the API has been abused and recently come under a major fuzzing "attack" through tools like syzbot which decided that it would attempt to just randomly bind any driver to any type of device, causing loads of unneeded errors and pointless kernel patches to be generated by unsuspecting new developers.
"Unneeded" and "pointless" are Kroah-Hartman's words. Nobody has published a count showing how many syzbot reports came from bind/unbind abuse, or how many were worthless. Phoronix, which first reported the patch on September 24, calls the bug reports impractical and irrelevant to any real use case. That reading comes straight from the cover letter.
The fix is to tag the event, not to block it. The patch adds a new taint flag, TAINT_FORCED_BIND, which will be set on the driver if the bind/unbind sysfs files are ever written to. In his words, this lets kernel developers "know" that a user is attempting to do something that is not normal, and as such, if the kernel breaks they get to keep the shiny pieces laying around on the floor.
How the sysfs bind and unbind files work today
Every driver registered with the Linux driver core has a directory in sysfs, and that directory holds two write-only files, bind and unbind. Writing a device's bus ID (for a PCI device, its bus address) to a driver's unbind file detaches the device from that driver. Writing the same ID to another driver's bind file asks that driver to take the device.
Kroah-Hartman added bind himself in June 2005, alongside the existing unbind file. His patch then said that if the bus ID matches a device with no driver, the probe sequence starts. He also noted that the driver has to be willing to accept the device, usually through its device-ID table, and that the patch "does not make it possible to override the driver's id table." In other words, the interface was never meant to make any driver bind to any hardware. It gave developers and testers a way to trigger probing and removal from user space without rebooting or rebuilding.
That history explains why he treats fuzzer reports built on this interface as edge cases. If syzbot pairs a driver with a device it was never written for and the kernel falls over, the crash may be real code misbehaving. It may also be a configuration no real system would produce.
What the Y taint records, and when it is set
Linux taint flags are bits in a single kernel-wide value, and each bit records a condition developers want to know about when they read a crash. The kernel's own documentation says a taint stays set even after the condition that caused it is undone. Taint status also shows up in bug, oops and panic messages, which is why it works as a triage tool.
The proposal adds one entry to the documented taint table. Bit 20, numeric value 1,048,576, log character Y, described as device was manually bound or unbound from a driver. That description is from the patch's documentation. Kroah-Hartman chose the letter because it was unused, and can remembered as the user is "yeeting" the device being operated on here (thrown with force without regard for the thing being thrown). The patch also updates the tools/debugging/kernel-chktaint decoder script and the module trace events so the new flag appears in their output.
The timing is deliberate. The taint flag gets set BEFORE the bind/unbind callback happens, as many times crashes/oops/warnings/failures happen within the callback, and the taint flag needs to be there to show what was being attempted. If it were to be set after the callback happens, the oops report would not properly reflect what foolishness was being attempted.
The code shows exactly when the flag fires. In drivers/base/bus.c, the unbind path sets the taint once it finds the named device and confirms that device is bound to this driver, just before detaching it. The bind path sets it once the device is found and driver_match_device() accepts the pairing, just before device_driver_attach() runs. A write that names a nonexistent device, or a device the driver doesn't match, leaves the kernel untainted. A bind that passes the match check and then fails in the driver's probe routine does leave the flag set, because the taint comes first.
The wording changed between versions. The first version's cover letter said the flag would be set if the files are ever successfully written to, and the added documentation still says userspace "successfully bound or removed a device." The v2 and v3 cover letters drop "successfully." The code in both versions shows the practical rule: the flag is set when the operation is allowed to go ahead, whether or not it then completes.
One more mechanical detail matters for anyone reading crash output. The patch uses add_taint_module() against the driver's owning module, and that function sets both the global taint and a taint bit on the specific module. The first patch in the two-part series makes that helper public so the driver core can call it. On builds without loadable modules, it falls back to plain add_taint().
Where VFIO, DPDK and USB/IP administrators see risk
The review thread shows the proposal is not settled. The kernel's automated AI reviewer, Sashiko, flagged the v3 patch with a high-severity concern: Tainting the kernel unconditionally on any sysfs bind/unbind operation marks legitimate, standard virtualization and networking setups as tainted. The review names VFIO PCI passthrough, DPDK and USB over IP as setups that use the unbind file as documented user-space API. It warns that such systems could be marked tainted for good, that their valid bug reports could be ignored, and that hosts running with panic_on_taint enabled could panic.
Kroah-Hartman rejected the framing. He replied that That is not a "standard" setup (or really shouldn't be, it's an abuse of the api...) The v2 cover letter is sharper still. It says workflows that use bind/unbind to avoid upgrading to a kernel that supports the hardware, or to avoid sending device IDs to driver authors, will keep working, but the kernel will be flagged so those users might reconsider.
So the proposal makes a policy call as well as a technical one. It doesn't distinguish a fuzzer from an administrator, and it doesn't try to. A Y in a crash report means someone manually moved a device between drivers. It doesn't say who did it, why, or whether the resulting bug is real.
Kroah-Hartman concedes that last point. The v2 cover letter says bind/unbind can expose genuine use-after-free bugs by forcing driver removal in software, that those bugs should still be fixed, and that the taint helps developers decide which reports are worth looking at. The flag is meant to add context to a report, not to throw it out.
The series has picked up support. On v2, Johan Hovold is credited with Reviewed-by and Tested-by tags. Aaron Tomlin offered his Reviewed-by once a stray comma in the add_taint_module() stub for !CONFIG_MODULES builds was fixed. A merge still hasn't happened in the material reviewed here.
How syzbot and other fuzzers are expected to respond
The proposal gives fuzzing systems a specific instruction. Fuzzing tools like syzbot, that doesn't have hand-crafted rules to keep the tool from hitting bind/unbind, should be run with panic_on_taint enabled so that they fall over and don't continue on, instead of carrying on as if they had found an ordinary bug.
This is Kroah-Hartman's recommendation to fuzzer operators, not an upstream rule that tainted reports get discarded. The kernel documentation already warns that reports from tainted kernels may be ignored or may need to be reproduced on an untainted kernel. The new flag adds one more reason to that list. Whether syzbot changes its configuration to stop at bit 20 or to avoid the bind files entirely is up to its operators.
The practical result for kernel maintainers is quicker triage. A syzbot crash with Y in the taint string points straight to a forced binding, so someone can decide in minutes whether the driver/device pairing could ever happen on real hardware. Without the flag, a newer contributor might write a patch to harden a probe path that only fails when a fuzzer attaches the wrong device.
What this means for Linux admins running passthrough hosts
Nothing changes on any production kernel yet, so the only decision today is whether to prepare. If you run Linux virtualization hosts, including homelab boxes that pass GPUs or NICs to Windows guests through VFIO, check whether your setup writes to bind or unbind. If this series is merged in its current form, those hosts would show a Y taint after the first such write, and it would stay until reboot.
You can check today's taint state on any Linux system by reading /proc/sys/kernel/tainted. Zero means clean. Any other number is a bitfield, and the kernel's kernel-chktaint script decodes it. With the patch applied, bit 20 would show up as Y along with the line "device was manually bound or unbound from a driver (#20)".
TAINT_FORCED_BINDis a proposed patch with at least three revisions posted between August 26 and early September 2026, and no kernel release containing it has been confirmed.- The flag would be set on bit 20, letter
Y, before a permitted bind or unbind runs, so it also marks binds whose probe then fails. - Writes that name a missing device, or one the driver doesn't match, don't trigger the taint under the posted code.
- VFIO passthrough, DPDK and USB/IP hosts that use the sysfs files would be tainted too, and Kroah-Hartman has said that is intended.
- If you boot with
panic_on_taint, review its bitmask once a kernel carrying this patch reaches your distribution, so a routine passthrough bind can't panic the host. - A
Yin a crash report adds context, and it doesn't prove the bug is fake. The series author himself says real use-after-free bugs found this way should still be fixed.
The next milestone is a merge decision in Kroah-Hartman's driver-core tree, followed by a mainline merge window. If the patch lands as written, maintainers get a quick way to set aside fuzzer crashes built on driver pairings no real system would use. Administrators who pass hardware through with bind and unbind get a permanent Y in their taint string, and they will need to explain it when they file their own bug reports.