From: Al Viro <v...@zeniv.linux.org.uk> Date: Fri, 14 Jul 2017 02:37:50 +0100
> On Tue, Jul 11, 2017 at 08:25:14PM -0700, David Miller wrote: > >> looks harmless, or if there is a bug in there I can't see it. >> >> But whatever it is, that same problem could be hiding in some of these >> other transformations as well. >> >> I think the bug might be that we are corrupting the user's stack >> somehow. But the two user copies in that commit look perfectly fine >> to my eyes. >> >> There shouldn't be any padding in that compat_rlimit structure, so >> it's not like we're copying extra bytes. Well, we'd be exposing >> kernel stack memory if that were the case. > > There isn't any padding in compat_rlimit; unfortunately, it was > mistakenly declared as struct rlimit instead. Which, of course, > has different member sizes - otherwise we wouldn't have needed > a compat syscall there in the first place. > > It was harder to spot since I combined move and a transformation > into one commit. Shouldn't have done so... Had those been two > separate commits, the bug would've stood out immediately. Shouldn't > be the case here... Ok, I'll ack these patches then: Acked-by: David S. Miller <da...@davemloft.net>
