Comment by vlovich123
Comment by vlovich123 3 days ago
> We disclosed this vulnerability to the kernel security team through responsible disclosure. The patch on the mailing list is visible here.
The patch is dated today. Isn’t responsible disclosure to wait a bit until the security update can work its way into some actual distributions (or heck even a kernel release) and not publish a detailed 0-day for all Linux kernels?
Edit: reading the exploit description more fully:
> On most (or even all) distributions this strategy doesn’t work.
Only impacts vanilla builds using the default config.
> > On most (or even all) distributions this strategy doesn’t work.
> The vulnerability itself does affect major distributions, but we are not publishing a blueprint for how to perform that exploit.
so no it doesn't only affect vanilla builds, the limitation is only for the specific way the vulnerability is exploited in the post, but not the vulnerability itself
> Isn’t responsible disclosure to wait a bit
Yes, but its also based on waiting a bit after reporting it not after it's fixed. People would even say it's irresponsibility to guarantee you wait until it's fixed + some time as history has shown this will reliably lead to some companies not fixing issues.
So the patch date doesn't matter the report date does (which I we do not know as a proper timeline is missing, something which is absent from the disclosure).
EDIT: Also to be clear while it isn't uncommon to extend disclosure deadlines for sever vulnerabilities if there is clear process/work/intend in fixing it this isn't a sever vulnerability. Most distros set /proc/sys/kernel/perf_event_paranoid by default to 2 which means you need privileges to use perf events at all. And some (Android & Debian) even to 3 which per-se disables perf events even for root users (hence why the article says Android and Debian are not affected).