[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20170711.202514.815304234636661456.davem@davemloft.net>
Date: Tue, 11 Jul 2017 20:25:14 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: viro@...IV.linux.org.uk
Cc: netdev@...r.kernel.org
Subject: Re: [RFC] get_compat_msghdr(): get rid of field-by-field copyin
From: Al Viro <viro@...IV.linux.org.uk>
Date: Sat, 8 Jul 2017 19:21:00 +0100
> There are 3 commits in vfs.git#misc.compat I hadn't pushed to Linus yet;
> they touch net/* and I'd like to see at least "no objections" from networking
> folks before asking to pull that; all of those are about getting rid of
> field-by-field copyin. Please, review and comment.
>
> Signed-off-by: Al Viro <viro@...iv.linux.org.uk>
That weird sparc64 regression concerns me.
The commit referenced in that discussion:
d9e968cb9f849770288f5fde3d8d3a5f7e339052 ("getrlimit()/setrlimit(): move compat to native")
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.
Color me stumped, but cautious about ACK'ing these networking
compat changes.
Powered by blists - more mailing lists