From: Al Viro
Date: Wed, 30 Jan 2019 15:40:09 +
> On Mon, Jan 28, 2019 at 10:32:30PM +0100, Johannes Berg wrote:
>
>> At the same time, fixing all this _completely_ is not very realistic, it
>> would require passing the ifreq size through to lots of places and
>> making the user copy there t
On Mon, Jan 28, 2019 at 10:32:30PM +0100, Johannes Berg wrote:
> At the same time, fixing all this _completely_ is not very realistic, it
> would require passing the ifreq size through to lots of places and
> making the user copy there take the size rather than sizeof(ifreq),
> obviously the very
From: Johannes Berg
Date: Mon, 28 Jan 2019 22:32:30 +0100
> Al, care to speak up about this here?
I'll give Al one day to respond.
I'll apply this series if he agrees or fails to give feedback.
On Mon, 2019-01-28 at 11:22 -0800, David Miller wrote:
> I see some back and forth between you and Al, where do we stand at
> this point?
I don't really know. I think neither of us _likes_ this code, in
particular the whole copy_in_user() thing is quite a mess. The
copy_in_user() also means that
From: Johannes Berg
Date: Fri, 25 Jan 2019 22:43:16 +0100
> Back a long time ago, I already fixed a few of these by passing
> the size of the struct ifreq to do_sock_ioctl(). However, Robert
> found more cases, and now it won't be as simple because we'd have
> to pass that down all the way to e.g
Back a long time ago, I already fixed a few of these by passing
the size of the struct ifreq to do_sock_ioctl(). However, Robert
found more cases, and now it won't be as simple because we'd have
to pass that down all the way to e.g. bond_do_ioctl() which isn't
really feasible.
Therefore, restore t
