linux-kernel - Re: [PATCH v2 1/2] cxl/cdat: Handle cdat table build errors

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]

Message-ID: <20240108150318.00006eba@Huawei.com>
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
>