Hello. > This is a very strange reasoning. I can say that restarting on an IO error > (that can happen in normal situations) could cause another security issue, > such as DoS. EIO is not a data integrity error; it can happen even higher > in the storage stack... and the application should handle it anyway.
In the default mode of operation, there should be no panic/reboot on an I/O error. The issue and the proposed patch affect the non-default modes: panic_on_corruption and restart_on_corruption. Users relying on one of those two modes expect the system to crash if something goes wrong [1]. So, DoS is expected here. Returning I/O errors to the reader isn't something that is expected here (see [1]). The issue allows the attacker to "downgrade" the "panic_on_corruption" and "restart_on_corruption" modes to the default one by creating unreadable sectors on the underlying media (e.g., through the Write Uncorrectable command). References: 1. https://github.com/flatcar/Flatcar/issues/422
