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... > Color me stumped, but cautious about ACK'ing these networking > compat changes.
