The crash report showed that there was a local variable;
----iovstack.i@__sys_sendmmsg created at:
___sys_sendmsg net/socket.c:2388 [inline]
__sys_sendmmsg+0x6db/0xc90 net/socket.c:2480
that was left uninitialized.
The contents of iovstack are of interest, since the respective pointer
is passed down as an argument to sendmsg_copy_msghdr as well.
Initializing this contents of this stack prevents this bug from happening.
Since the memory that was initialized is freed at the end of the function
call, memory leaks are not likely to be an issue.
syzbot seems to have triggered this error by passing an array of 0's as
a parameter while making the initial system call.
Reported-by: [email protected]
Tested-by: [email protected]
Signed-off-by: Anant Thazhemadam <[email protected]>
---
net/socket.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/net/socket.c b/net/socket.c
index 0c0144604f81..d74443dfd73b 100644
--- a/net/socket.c
+++ b/net/socket.c
@@ -2396,6 +2396,7 @@ static int ___sys_sendmsg(struct socket *sock, struct user_msghdr __user *msg,
{
struct sockaddr_storage address;
struct iovec iovstack[UIO_FASTIOV], *iov = iovstack;
+ memset(iov, 0, UIO_FASTIOV);
ssize_t err;
msg_sys->msg_name = &address;
--
2.25.1
On Sun, Sep 13, 2020 at 11:26:39AM +0530, Anant Thazhemadam wrote:
> The crash report showed that there was a local variable;
>
> ----iovstack.i@__sys_sendmmsg created at:
> ___sys_sendmsg net/socket.c:2388 [inline]
> __sys_sendmmsg+0x6db/0xc90 net/socket.c:2480
>
> that was left uninitialized.
>
> The contents of iovstack are of interest, since the respective pointer
> is passed down as an argument to sendmsg_copy_msghdr as well.
> Initializing this contents of this stack prevents this bug from happening.
>
> Since the memory that was initialized is freed at the end of the function
> call, memory leaks are not likely to be an issue.
>
> syzbot seems to have triggered this error by passing an array of 0's as
> a parameter while making the initial system call.
>
> Reported-by: [email protected]
> Tested-by: [email protected]
> Signed-off-by: Anant Thazhemadam <[email protected]>
> ---
> net/socket.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/net/socket.c b/net/socket.c
> index 0c0144604f81..d74443dfd73b 100644
> --- a/net/socket.c
> +++ b/net/socket.c
> @@ -2396,6 +2396,7 @@ static int ___sys_sendmsg(struct socket *sock, struct user_msghdr __user *msg,
> {
> struct sockaddr_storage address;
> struct iovec iovstack[UIO_FASTIOV], *iov = iovstack;
> + memset(iov, 0, UIO_FASTIOV);
> ssize_t err;
>
> msg_sys->msg_name = &address;
I don't think you built this code change, otherwise you would have seen
that it adds a build warning to the system, right?
:(
On 13/09/20 11:43 am, Greg KH wrote:
> On Sun, Sep 13, 2020 at 11:26:39AM +0530, Anant Thazhemadam wrote:
>> The crash report showed that there was a local variable;
>>
>> ----iovstack.i@__sys_sendmmsg created at:
>> ___sys_sendmsg net/socket.c:2388 [inline]
>> __sys_sendmmsg+0x6db/0xc90 net/socket.c:2480
>>
>> that was left uninitialized.
>>
>> The contents of iovstack are of interest, since the respective pointer
>> is passed down as an argument to sendmsg_copy_msghdr as well.
>> Initializing this contents of this stack prevents this bug from happening.
>>
>> Since the memory that was initialized is freed at the end of the function
>> call, memory leaks are not likely to be an issue.
>>
>> syzbot seems to have triggered this error by passing an array of 0's as
>> a parameter while making the initial system call.
>>
>> Reported-by: [email protected]
>> Tested-by: [email protected]
>> Signed-off-by: Anant Thazhemadam <[email protected]>
>> ---
>> net/socket.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/net/socket.c b/net/socket.c
>> index 0c0144604f81..d74443dfd73b 100644
>> --- a/net/socket.c
>> +++ b/net/socket.c
>> @@ -2396,6 +2396,7 @@ static int ___sys_sendmsg(struct socket *sock, struct user_msghdr __user *msg,
>> {
>> struct sockaddr_storage address;
>> struct iovec iovstack[UIO_FASTIOV], *iov = iovstack;
>> + memset(iov, 0, UIO_FASTIOV);
>> ssize_t err;
>>
>> msg_sys->msg_name = &address;
> I don't think you built this code change, otherwise you would have seen
> that it adds a build warning to the system, right?
>
> :(
My apologies. I think I ended up overlooking the build warning. Thank you for pointing that out.
If everything else looks good, I'd be happy to send in a v2 that fixes this build warning.
Thanks,
Anant
From: Anant Thazhemadam <[email protected]>
Date: Sun, 13 Sep 2020 11:50:52 +0530
> My apologies. I think I ended up overlooking the build warning.
You "think" you overlooked the build warning? You don't actually
know?
If you aren't willing to even make sure the build is clean after your
changes, why should we be willing to review and integrate your changes?
This kind of carelessness costs other developers their valuable time,
please treat it with more respect than you have.
Thank you.
I can assure you that when I said "I think", I meant it in an assertive manner,
and not an assumptive one, but I can understand how that could easily get lost
in translation.
I wouldn't have sent in the patch if I had caught the build warning, and once
again, my apologies for not fixing it sooner, like I should have.
I didn't mean to disrespect or offend anyone, and it definitely wasn't my
intention to waste anybody's time. Needless to say, something like this won't
happen again from my end. :)
I have sent in a v2 for this, which doesn't add a build warning to the system.
Thank you for your time, and once again, my apologies.
Thanks,
Anant
From: Greg KH
> Sent: 13 September 2020 07:14
> On Sun, Sep 13, 2020 at 11:26:39AM +0530, Anant Thazhemadam wrote:
> > The crash report showed that there was a local variable;
> >
> > ----iovstack.i@__sys_sendmmsg created at:
> > ___sys_sendmsg net/socket.c:2388 [inline]
> > __sys_sendmmsg+0x6db/0xc90 net/socket.c:2480
> >
> > that was left uninitialized.
> >
> > The contents of iovstack are of interest, since the respective pointer
> > is passed down as an argument to sendmsg_copy_msghdr as well.
> > Initializing this contents of this stack prevents this bug from happening.
> >
> > Since the memory that was initialized is freed at the end of the function
> > call, memory leaks are not likely to be an issue.
> >
> > syzbot seems to have triggered this error by passing an array of 0's as
> > a parameter while making the initial system call.
> >
> > Reported-by: [email protected]
> > Tested-by: [email protected]
> > Signed-off-by: Anant Thazhemadam <[email protected]>
> > ---
> > net/socket.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/net/socket.c b/net/socket.c
> > index 0c0144604f81..d74443dfd73b 100644
> > --- a/net/socket.c
> > +++ b/net/socket.c
> > @@ -2396,6 +2396,7 @@ static int ___sys_sendmsg(struct socket *sock, struct user_msghdr __user *msg,
> > {
> > struct sockaddr_storage address;
> > struct iovec iovstack[UIO_FASTIOV], *iov = iovstack;
> > + memset(iov, 0, UIO_FASTIOV);
> > ssize_t err;
> >
> > msg_sys->msg_name = &address;
>
> I don't think you built this code change, otherwise you would have seen
> that it adds a build warning to the system, right?
Also it can't be the right 'fix' for whatever sysbot found.
(I can't find the sysbot report.)
Zeroing iov[] just slows down a path that is already too slow because
of the contorted functions used to read in iov[].
If it does need to be zerod then it would be needed in a lot
of other code paths that read in iov[].
If a zero length iov[] needs converting into a single entity
with a zero length - then that needs to be done elsewhere.
I've a patch series I might redo that changes the code that
reads in iov[] to return the address of any buffer that
needed to be malloced (more than UIV_FASTIO buffers) rather
than using the iov parameter to pass in the cache and
return the buffer to free.
It would be less confusing and error prone.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)