Summary: | Heap overflow in geom ioctl handler | ||||||
---|---|---|---|---|---|---|---|
Product: | Base System | Reporter: | CTurt <ecturt> | ||||
Component: | kern | Assignee: | freebsd-geom (Nobody) <geom> | ||||
Status: | New --- | ||||||
Severity: | Affects Only Me | CC: | delphij, emaste, mav, op, pjd, ryan, shawn.webb | ||||
Priority: | --- | ||||||
Version: | CURRENT | ||||||
Hardware: | Any | ||||||
OS: | Any | ||||||
Attachments: |
|
Description
CTurt
2016-04-27 22:41:05 UTC
Created attachment 172625 [details]
Fix for 209113
A problem existed where a g_malloc call would allocate a buffer length specified by a 32 bit integer. Then copyin would write a 64 bit integer worth of data into the buffer.
By changing g_malloc()'s len argument to be a size_t (matching malloc) the buffer will always be large enough for copyin.
It is still possible to hang the process while waiting for a large enough allocation, so the M_NOWAIT flag has replaced the M_WAITOK flag.
-secteam@. This is not exploitable by non-root. (In reply to rday from comment #1) I don't really like the M_NOWAIT part -- shouldn't we place a hard limit on how much the userland may request instead? I think you're right, a hard limit would be better. I can't find a maximum parameter count or a maximum parameter size in the documentation though. I don't think I'm familiar enough with the system to come up with a value. On the other hand, if root issues a malicious ioctl() then root's process just waits(using M_WAITOK). This doesn't seem like much of a concern. Lacking a sufficient hard limit, would it be best to simply change the `size` parameter's type to size_t? Removing the M_NOWAIT change? |