Short version:
It would be nice if we could render “disk fill via logging” vulnerabilities unexploitable by introducing a mitigation like the one suggested in the “up for grabs” PR #19995. That PR was Concept ACK:ed by @naumenkogs, @laanwj and @jnewbery, but unfortunately closed due to lack of time. Volunteers welcome!
Long version:
A disk fill attack is an attack where an untrusted party (such as a peer) is able to cheaply make your node log to disk excessively. The excessive logging may fill your disk and thus make your node crash either cleanly (best case: if disk fill rate is relatively slow) or uncleanly (worst case: if disk fill rate is relatively fast).
It is easy to accidentally introduce a disk fill vulnerability: all it takes is a LogPrintf in a code path which is easily and cheaply triggered by a remote attacker.
It would be nice if we could kill this vulnerability bug class by introducing a general mitigation mechanism which would remove the ability exploit such such a misplaced LogPrintf. (Our first line of defence would obviously be to never misplace a LogPrintf, but realistically logging mistakes happen and that’s where mitigations kick in as a second line of defence.)
One possible mitigation was suggested in PR #19995 which received Concept ACKs from @naumenkogs, @laanwj and @jnewbery. The reviewers came up with some good ideas for improvements which need to be implemented. Unfortunately I don’t have time to implement those changes myself, but if someone is looking for “up for grabs” PRs then #19995 would be a very good choice. It is seldom one gets the chance to kill an entire vulnerability bug class :) I’d be glad to review and help out.
The solution suggested in the referenced PR is one of many possible solutions, but regardless of which solution we choose I think we need some disk fill attack mitigation to kill this bug class once and for all :)