An unpleasant local kernel vulnerability
If a process causes the kernel to leak 0x100000000 references to the same object, it can later cause the kernel to think the object is no longer referenced and consequently free the object. If the same process holds another legitimate reference and uses it after the kernel freed the object, it will cause the kernel to reference deallocated, or a reallocated memory. This way, we can achieve a use-after-free, by using the exact same bug from before. A lot has been written on use-after-free vulnerability exploitation in the kernel, so the following steps wouldn’t surprise an experienced vulnerability researcher." This bug, introduced in 3.8, looks like a good one to patch quickly; of course, for vast numbers of users of mobile and embedded systems, that may not be an option.
Posted Jan 19, 2016 14:59 UTC (Tue)
by arekm (guest, #4846)
[Link] (1 responses)
Posted Jan 19, 2016 17:05 UTC (Tue)
by derobert (subscriber, #89569)
[Link]
I would guess it's this one: https://anonscm.debian.org/cgit/kernel/linux.git/commit/?...
(Presumably, you can find the same from other distro's repositories, but I'm familiar with Debian.)
Posted Jan 19, 2016 15:07 UTC (Tue)
by torquay (guest, #92428)
[Link] (5 responses)
Posted Jan 19, 2016 15:19 UTC (Tue)
by jake (editor, #205)
[Link] (1 responses)
Presumably so. We looked at the PAX_REFCOUNT patch recently (http://lwn.net/Articles/668876/) which is a step toward protecting against this kind of thing for the mainline (derived from the PaX kernel).
jake
Posted Jan 20, 2016 9:17 UTC (Wed)
by paulj (subscriber, #341)
[Link]
Posted Jan 19, 2016 15:30 UTC (Tue)
by lorddoskias (subscriber, #95746)
[Link]
Posted Jan 19, 2016 16:37 UTC (Tue)
by pbonzini (subscriber, #60935)
[Link] (1 responses)
Posted Jan 19, 2016 16:46 UTC (Tue)
by PaXTeam (guest, #24616)
[Link]
Posted Jan 19, 2016 15:15 UTC (Tue)
by PaXTeam (guest, #24616)
[Link]
# ./cve_2016_0728 .cifs_idmap
# awk '/cifs_idmap/ {printf "%x\n", $3}' /proc/keys
extract from dmesg:
PAX: refcount overflow detected in: cve_2016_0728:28704, uid/euid: 0/0
[502201.161570] Call Trace:
Posted Jan 19, 2016 18:01 UTC (Tue)
by rsidd (subscriber, #2582)
[Link] (9 responses)
(Yes, I know the dark side to that bright side too.)
Posted Jan 19, 2016 23:55 UTC (Tue)
by BenHutchings (subscriber, #37955)
[Link] (8 responses)
Posted Jan 20, 2016 5:40 UTC (Wed)
by rsidd (subscriber, #2582)
[Link] (7 responses)
Posted Jan 20, 2016 9:55 UTC (Wed)
by tao (subscriber, #17563)
[Link] (6 responses)
Posted Jan 20, 2016 16:33 UTC (Wed)
by flussence (guest, #85566)
[Link] (5 responses)
Posted Jan 21, 2016 12:29 UTC (Thu)
by nye (subscriber, #51576)
[Link] (4 responses)
Lucky you! Samsung's current mid-range phone is still the S5 Mini, since they decided for whatever reason not to make an S6 Mini, and it's a fairly safe bet that that will never be updated to Android 5 outside of a handful of select markets (all with slightly different models, so it's not clear how safe it would be to apply an update for another region even if you wanted to).
This is a phone that they're not only still selling new, but have no newer model in its market segment.
>it runs kernel 3.0.
That's pretty weird though, given that 3.0 was the kernel used for Android 4.1, several releases earlier than 5. The fact that they've gone out of their way to give you an extra special old kernel version probably implies that some out of tree driver has never been updated, so the device may well be stuck on that kernel version for evermore(?)
Posted Feb 1, 2016 14:18 UTC (Mon)
by nye (subscriber, #51576)
[Link] (3 responses)
I take it all back! Samsung, I have unfairly maligned you!
This Friday, a couple of weeks after I'd finally given up hope - and a few months after the last peep from Samsung on the topic - suddenly the 5.1 update appeared out of the blue.
Posted Feb 1, 2016 21:08 UTC (Mon)
by apoelstra (subscriber, #75205)
[Link] (2 responses)
On samsung.com there is no indication that the S5 Mini even exists.
Posted Feb 1, 2016 23:18 UTC (Mon)
by johannbg (guest, #65743)
[Link]
Just do what the rest of the world has started to do since the market is beginning to be saturated and ditch Samsung and other vendors that have crappy update/upgrade policy and custom un-installable bandwith and battery draining bloatware.
The only reliable update/upgrade source is Google and with 2016 being the year of the Snapdragon 820 Processor then the next Nexus line up should be powered by those ( unless Google has gone off the rail ) and you should be good for next 3 - 5 years with those devices OS and Technology wise.
Posted Feb 4, 2016 15:10 UTC (Thu)
by nye (subscriber, #51576)
[Link]
Nothing better than johannbg posted, sorry - it just announced that there was an update available one day.
Posted Jan 19, 2016 18:41 UTC (Tue)
by flussence (guest, #85566)
[Link]
I guess I'll quietly abandon my attempts to get NFSv4 working on my LAN in that case...
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
we can achieve a use-after-free, by using the exact same bug from before. A lot has been written on use-after-free vulnerability exploitation in the kernel, so the following steps wouldn’t surprise an experienced vulnerability researcher.
Could any of the grsecurity patches have prevented this exploitation?
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
uid=0, euid=0
Increfing...
Killed
7fff2234
PAX: refcount overflow occured at: prepare_creds+0x7f/0xf0
CPU: 2 PID: 28704 Comm: cve_2016_0728 Tainted: G E 4.3.3-amd64-pax #8
RIP: 0010:[<ffffffff8210fbef>] [<ffffffff8210fbef>] prepare_creds+0x7f/0xf0
[502201.161601] [<ffffffff8242fce7>] join_session_keyring+0x17/0x150
[502201.161616] [<ffffffff8242d8ec>] keyctl_join_session_keyring+0x2c/0x50
[502201.161623] [<ffffffff8242f5a1>] SyS_keyctl+0x121/0x150
[502201.161634] [<ffffffff82e98e17>] entry_SYSCALL_64_fastpath+0x16/0x7c
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability
An unpleasant local kernel vulnerability