A nasty local kernel vulnerability

> at worst a sarcastic comment would have achieved some education

there you go: https://lwn.net/Articles/539942/ (in case it's still not obvious, 'supported' refers to 'supported by the exploit' because it was castrated before publication, something that should have been obvious to anyone who bothered to read the README).

so the first conclusion is that you missed that opportunity of enlightenment. let's see how you fared next:

> Some of us don't touch kernel stuff precisely because [...]

right, so you admit to not understand anything about the exploit, the exploited bug, the affected kernels, etc. and you never read the README either (you don't need to be a programmer to understand it). and you didn't read the explot log to which you responded either else you'd have noticed the very clear discrepancy between the to-be-exploited kernel's version and what the exploit itself offered. *yet* you felt utterly compelled to share your non-existent wisdom with the rest of us and managed to actively mislead the poor OP at the same time (we call it giving someone a false sense of security). what do you think of yourself in that light? what i think is that the proverbial road to hell is clearly paved with arrogant incompetence.

one would think at this point you'd have realized the errors of your way, but clearly that's assuming too much of your intellect. watch this:

> The explanation you were after "It hard-codes memory addresses for known
> kernels".

so what did i post almost an hour before your first rant (not that it wasn't already in the published sources that you could have read as well)? that's right, these very pesky hard-coded memory addresses for known kernels (known to the trimmed down exploit, that is).

> The logical next question is then: How hard is it to find those
> addresses for the kernel in the example above, and test the exploit
> properly?

the logical next answer is that you go look at the exploit source code (did i say that too many times already?) and read what those addresses are and realize that they're a grep away.

> Hell, if I was in your place,

hell, i wish you weren't, you'd do too much damage due to incompetence.

> [...]I'd make a working exploit for a particular kernel if it's that
> easy to do so from the code given, and demonstrate your skills rather
> than mouth off about them

actually, there was nothing mouthing off about anyone's skill, or it was at most about the lack thereof (that'd be your reading comprehension ;). and why on earth would i give people a loaded gun when i've never done it in the past? as you can see, the average person is way too careless, the only reason the OP's box didn't get erased is because the exploit publisher was kind enough, which is a rather rare occurance these days as most dangerous stuff stays private and public 'leaks' often come with some extra baggage you really don't wish to run.

> (You'll notice that your "explanatory" post was posted after my initial post above

and also before your rant, yes.

> and still that doesn't demonstrate that a newer kernel is or is not
> vulnerable, only that some well-known kernels have values hardcoded).

a kernel is not vulnerable because an exploit exists against it. a kernel is vulnerable because it has an exploitable bug. and we know that 1) such a bug does exist in this case, 2) which kernels are affected (did you even read the article itself?). so if you want to know if you're vulnerable, you go check you kernel version, you don't need an exploit for that. if you're a curious cat or have other nefarious intents, get off your butt and at least read the code you're about to run and figure out what needs adjustment. and no, i'm still not giving you that loaded gun, i hinted at enough details already that should get you going if you really want to.

last but not least, if i cared about your opinion, you'd think i'd have shown some results by now. clearly, i don't give a shit but then i guess it won't stop you from trying (what was that Einstein quote about insanity again? ;).