[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DB7PR04MB42527E9FB192076FE7B1881D8B2C0@DB7PR04MB4252.eurprd04.prod.outlook.com>
Date: Thu, 2 Aug 2018 17:05:38 +0000
From: Vakul Garg <vakul.garg@....com>
To: Dave Watson <davejwatson@...com>
CC: "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"borisp@...lanox.com" <borisp@...lanox.com>,
"aviadye@...lanox.com" <aviadye@...lanox.com>,
"davem@...emloft.net" <davem@...emloft.net>
Subject: RE: [PATCH net-next] net/tls: Mark the end in scatterlist table
> -----Original Message-----
> From: Dave Watson [mailto:davejwatson@...com]
> Sent: Thursday, August 2, 2018 10:17 PM
> To: Vakul Garg <vakul.garg@....com>
> Cc: netdev@...r.kernel.org; borisp@...lanox.com;
> aviadye@...lanox.com; davem@...emloft.net
> Subject: Re: [PATCH net-next] net/tls: Mark the end in scatterlist table
>
> On 08/02/18 08:43 PM, Vakul Garg wrote:
> > Function zerocopy_from_iter() unmarks the 'end' in input sgtable while
> > adding new entries in it. The last entry in sgtable remained unmarked.
> > This results in KASAN error report on using apis like sg_nents().
> > Before returning, the function needs to mark the 'end' in the last
> > entry it adds.
> >
> > Signed-off-by: Vakul Garg <vakul.garg@....com>
>
> Looks good to me, it looks like the fallback path should unmark the end
> appropriately.
>
In case zerocopy_from_iter() fails, 'end' won't get marked.
So fallback path is fine.
> Which codepath is calling sg_nents()?
While testing my WIP implementation of combined dynamic memory allocation for
(aead_req || sgin || sgout || aad || iv), I was getting random kernel crashes.
To debug it I had inserted sg_nents() in my code. The KASAN then immediately
complained that sg_nents() went beyond the allocated memory for scatterlist.
This led me to find that scatterlist table end has not been marked.
> Acked-by: Dave Watson <davejwatson@...com>
Powered by blists - more mailing lists