lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 8 Jan 2024 15:03:18 +0000
From: Jonathan Cameron <Jonathan.Cameron@...wei.com>
To: Ira Weiny <ira.weiny@...el.com>
CC: fan <nifan.cxl@...il.com>, Dave Jiang <dave.jiang@...el.com>,
	<linux-cxl@...r.kernel.org>, <linux-kernel@...r.kernel.org>, Huai-Cheng Kuo
	<hchkuo@...ry-design.com.tw>
Subject: Re: [PATCH v2 1/2] cxl/cdat: Handle cdat table build errors

On Wed, 20 Dec 2023 11:55:33 -0800
Ira Weiny <ira.weiny@...el.com> wrote:

> fan wrote:
> > On Wed, Nov 29, 2023 at 05:33:03PM -0800, Ira Weiny wrote:  
> > > The callback for building CDAT tables may return negative error codes.
> > > This was previously unhandled and will result in potentially huge
> > > allocations later on in ct3_build_cdat()
> > > 
> > > Detect the negative error code and defer cdat building.
> > > 
> > > Fixes: f5ee7413d592 ("hw/mem/cxl-type3: Add CXL CDAT Data Object Exchange")
> > > Cc: Huai-Cheng Kuo <hchkuo@...ry-design.com.tw>
> > > Reviewed-by: Dave Jiang <dave.jiang@...el.com>
> > > Signed-off-by: Ira Weiny <ira.weiny@...el.com>
> > > ---
> > >  hw/cxl/cxl-cdat.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/hw/cxl/cxl-cdat.c b/hw/cxl/cxl-cdat.c
> > > index 639a2db3e17b..24829cf2428d 100644
> > > --- a/hw/cxl/cxl-cdat.c
> > > +++ b/hw/cxl/cxl-cdat.c
> > > @@ -63,7 +63,7 @@ static void ct3_build_cdat(CDATObject *cdat, Error **errp)
> > >      cdat->built_buf_len = cdat->build_cdat_table(&cdat->built_buf,
> > >                                                   cdat->private);
> > >  
> > > -    if (!cdat->built_buf_len) {
> > > +    if (cdat->built_buf_len <= 0) {
> > >          /* Build later as not all data available yet */
> > >          cdat->to_update = true;
> > >          return;
> > >   
> > 
> > The fix looks good to me. Just curious how to really build cdat table
> > again when an error occurs, for example, the memory allocation fails.  
> 
> I did not go that far as I am unsure as well.
Memory allocations in qemu don't fail (well if they do it crashes)
Side effect of using glib which makes for simpler cases.
https://docs.gtk.org/glib/func.malloc.html

There shouldn't even be any checks :(  I'll fix that up at somepoint
across all the CXL emulation.  Sometimes reviewers noticed and
we dropped it at earlier stages, but clearly didn't catch them all.

Which come to think of it is why this error condition is in practice
not actually buggy as the code won't ever manage to return -ENOMEM and
I don't think there are other error codes.

Jonathan

> 
> Ira
> 


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ