Messages in this thread | | | From | Kees Cook <> | Date | Sat, 9 Jul 2016 10:07:34 -0700 | Subject | Re: [kernel-hardening] Re: [PATCH 9/9] mm: SLUB hardened usercopy support |
| |
On Fri, Jul 8, 2016 at 11:17 PM, <Valdis.Kletnieks@vt.edu> wrote: > Yeah, 'ping' dies with a similar traceback going to rawv6_setsockopt(), > and 'trinity' dies a horrid death during initialization because it creates > some sctp sockets to fool around with. The problem in all these cases is that > setsockopt uses copy_from_user() to pull in the option value, and the allocation > isn't tagged with USERCOPY to whitelist it.
Just a note to clear up confusion: this series doesn't include the whitelist protection, so this appears to be either bugs in the slub checker or bugs in the code using the cfq_io_cq cache. I suspect the former. :)
-Kees
-- Kees Cook Chrome OS & Brillo Security
| |