Linux añade un nuevo taint para frenar los informes basura que generan los bots de fuzzing
El kernel marcará con TAINT_FORCED_BIND cualquier sistema donde se haya usado bind/unbind por sysfs, una señal para descartar bugs artificiales de Syzbot y compañía.
Greg Kroah-Hartman ha introducido una nueva bandera de taint en el kernel de Linux, TAINT_FORCED_BIND, que se activa cuando alguien escribe en los ficheros bind o unbind de sysfs para un driver. El objetivo no es vigilancia ni telemetría: es que cualquiera que lea un informe de fallo sepa de un vistazo que ese kernel se ha manipulado por una vía que no es un flujo de trabajo normal.
El mecanismo lleva décadas en el árbol. Los atributos bind y unbind permiten desligar un dispositivo de su driver en caliente y ligarlo a otro distinto usando su bus ID, sin recompilar nada. Sirve para resetear hardware, para pasar un dispositivo a una máquina virtual y para que un desarrollador pruebe un driver nuevo contra una tarjeta que tiene delante. El problema es que la API acepta cualquier combinación de dispositivo y driver, y ahí es donde entró Syzbot.
Combinaciones absurdas, parches absurdos
El bot de fuzzing decidió probar combinaciones aleatorias: coger un dispositivo cualquiera y ligarlo a un driver con el que no tiene nada que ver. El resultado es una cascada de errores que solo existen porque alguien forzó ese emparejamiento, y que acaban convertidos en parches enviados a la lista por desarrolladores novatos que no saben de dónde sale el fallo. Kroah-Hartman lo explica así: la capacidad de añadir y quitar dispositivos de un driver desde sysfs se creó hace décadas para que los desarrolladores del kernel iteraran más rápido y para depurar sin recompilar, pero "esta API se ha abusado a lo largo de los años y recientemente ha sufrido un ataque masivo de fuzzing" con herramientas como syzbot, que "decidió intentar ligar aleatoriamente cualquier driver a cualquier tipo de dispositivo, provocando montones de errores innecesarios y parches sin sentido generados por desarrolladores nuevos que no sospechan nada".
Con el taint ya en marcha, una herramienta puede además usar panic_on_taint para provocar un kernel panic en cuanto el sistema quede marcado y cortar así una tanda de pruebas inútil. Es el mismo patrón que ya se usa con otras banderas de taint: no cambia el comportamiento del kernel, solo deja constancia de que el entorno está contaminado por una operación forzada.
El parche con la implementación ya está en la rama driver-core-next, así que va camino del ciclo de Linux 7.4.
Qué implica operativamente
Para quien administra sistemas, el cambio es de bajo impacto y conviene conocerlo igual. Si en algún momento se ha usado bind unbind a mano o desde un script de automatización, el kernel aparecerá tainted y cualquier informe de fallo posterior llevará esa marca, lo que puede hacer que un desarrollador descarte el reporte. No hay ruptura de compatibilidad ni ficheros que desaparezcan, pero sí una etiqueta más que revisar antes de dar por bueno un bug y que conviene tener en cuenta si se automatizan resets de hardware o passthrough de dispositivos a máquinas virtuales. La duda que queda es si el taint será suficiente disuasión para los bots o si el siguiente paso será restringir directamente quién puede escribir en esas interfaces.