On 03/09/2015 09:49 PM, Fam Zheng wrote:
> + if (!cmds || ncmds <= 0 || ncmds > EP_MAX_BATCH)
> + return -EINVAL;
> + cmd_size = sizeof(struct epoll_ctl_cmd) * ncmds;
> + /* TODO: optimize for small arguments like select/poll with a stack
> + * allocated buffer */
> +
>
> + if (ncmds <= 0 || !cmds)
> + return -EINVAL;
> + cmd_size = sizeof(struct epoll_ctl_cmd) * ncmds;
> + kcmds = kmalloc(cmd_size, GFP_KERNEL);
You should probably fix the integer overflow in the calculation of the
cmd_size variable, unless you like root vulnerabilities.
On 10/08/2013 10:22 PM, Ryan Mallon wrote:
> Ah, I misread it. It does however check when kptr_restrict != 0, not
> just when kptr_restrict is 1. I've left the in_irq test as-is, but used
> a switch as suggested. I don't really care either way, I think the
> original check is quite readable. Anyway
On 09/29/2013 08:56 PM, Ryan Mallon wrote:
> Okay, this was just the simplest solution I could come up with that
> fixed the issue for me. Is that a tentative acked/reviewed-by? :-).
>
> ~Ryan
I'm interested to see if anyone else has alternative ideas, but for now:
Reviewed-
On 09/29/2013 07:41 PM, George Spelvin wrote:
>> Right, so the pppd application is actually doing the correct thing.
> And a CAP_SYSLOG setuid binary that *doesn't* DTRT seems like a more
> immediate security hole than leaking kernel addresses. After all
> kptr_restrict is optional precisely becau
6363] .base: 88023e60d540
>
> --
> Stevie Trujillo
The intent behind this behavior was to return "pK-error" in cases where the %pK
format specifier was used in interrupt context, because the CAP_SYSLOG check
wouldn't be meaningful. Clearly this should only apply when
6 matches
Mail list logo
