| Message ID | 20170728123127.27921-1-olaf@aepfle.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 07/28/2017 07:31 AM, Olaf Hering wrote: > g_malloc0_n is available since glib-2.24. To allow build with older glib > versions use the generic g_malloc0, which is already used in many other > places in the code. > > Fixes commit 3284fad728 ("xen-disk: add support for multi-page shared rings") > > Signed-off-by: Olaf Hering <olaf@aepfle.de> > --- > hw/block/xen_disk.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c > index d42ed7070d..71deec17b0 100644 > --- a/hw/block/xen_disk.c > +++ b/hw/block/xen_disk.c > @@ -1232,7 +1232,7 @@ static int blk_connect(struct XenDevice *xendev) > return -1; > } > > - domids = g_malloc0_n(blkdev->nr_ring_ref, sizeof(uint32_t)); > + domids = g_malloc0(blkdev->nr_ring_ref * sizeof(uint32_t)); This version is prone to multiplication overflow (well, maybe not, but you have to audit for that). Wouldn't it be better to use: domids = g_new0(blkdev->nr_ring_ref, uint32_t) which preserves the safety of g_malloc0_n?
On Fri, Jul 28, Eric Blake wrote: > This version is prone to multiplication overflow (well, maybe not, but > you have to audit for that). Wouldn't it be better to use: What could go wrong? qemu will die either way, I think. Olaf
On Fri, Jul 28, 2017 at 07:43:59AM -0500, Eric Blake wrote: > On 07/28/2017 07:31 AM, Olaf Hering wrote: > > g_malloc0_n is available since glib-2.24. To allow build with older glib > > versions use the generic g_malloc0, which is already used in many other > > places in the code. > > > > Fixes commit 3284fad728 ("xen-disk: add support for multi-page shared rings") > > > > Signed-off-by: Olaf Hering <olaf@aepfle.de> > > --- > > hw/block/xen_disk.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c > > index d42ed7070d..71deec17b0 100644 > > --- a/hw/block/xen_disk.c > > +++ b/hw/block/xen_disk.c > > @@ -1232,7 +1232,7 @@ static int blk_connect(struct XenDevice *xendev) > > return -1; > > } > > > > - domids = g_malloc0_n(blkdev->nr_ring_ref, sizeof(uint32_t)); > > + domids = g_malloc0(blkdev->nr_ring_ref * sizeof(uint32_t)); > > This version is prone to multiplication overflow (well, maybe not, but > you have to audit for that). Wouldn't it be better to use: > > domids = g_new0(blkdev->nr_ring_ref, uint32_t) You mean g_new0(uint32_t, blkdev->nr_ring_ref) but yeah, g_new0 is better than g_malloc0 pretty much every time. Regards, Daniel
On 07/28/2017 07:48 AM, Olaf Hering wrote: > On Fri, Jul 28, Eric Blake wrote: > >> This version is prone to multiplication overflow (well, maybe not, but >> you have to audit for that). Wouldn't it be better to use: > > What could go wrong? > qemu will die either way, I think. Dying immediately due to provable multiplication overflow is MUCH better than successfully allocating too-little and then having who-knows-what go wrong down the road because you didn't check for overflow. The latter can sometimes be exploited into CVEs. And maybe you can't overflow, but having to do a non-local audit to prove that is more time spent than just using the right interface from the get-go.
Olaf Hering <olaf@aepfle.de> writes: > On Fri, Jul 28, Eric Blake wrote: > >> This version is prone to multiplication overflow (well, maybe not, but >> you have to audit for that). Wouldn't it be better to use: > > What could go wrong? > qemu will die either way, I think. An overflow in the size argument of malloc(), realloc(), etc. is a heap overrun waiting to happen.
diff --git a/hw/block/xen_disk.c b/hw/block/xen_disk.c index d42ed7070d..71deec17b0 100644 --- a/hw/block/xen_disk.c +++ b/hw/block/xen_disk.c @@ -1232,7 +1232,7 @@ static int blk_connect(struct XenDevice *xendev) return -1; } - domids = g_malloc0_n(blkdev->nr_ring_ref, sizeof(uint32_t)); + domids = g_malloc0(blkdev->nr_ring_ref * sizeof(uint32_t)); for (i = 0; i < blkdev->nr_ring_ref; i++) { domids[i] = blkdev->xendev.dom; }
g_malloc0_n is available since glib-2.24. To allow build with older glib versions use the generic g_malloc0, which is already used in many other places in the code. Fixes commit 3284fad728 ("xen-disk: add support for multi-page shared rings") Signed-off-by: Olaf Hering <olaf@aepfle.de> --- hw/block/xen_disk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)