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
| ||
|
Date: Mon, 1 Jun 2020 13:21:27 +0800 (GMT+08:00) From: dinghao.liu@....edu.cn To: "Ben Skeggs" <skeggsb@...il.com> Cc: kjlu@....edu, "David Airlie" <airlied@...ux.ie>, "ML nouveau" <nouveau@...ts.freedesktop.org>, LKML <linux-kernel@...r.kernel.org>, "ML dri-devel" <dri-devel@...ts.freedesktop.org>, "Ben Skeggs" <bskeggs@...hat.com>, Markus.Elfring@....de Subject: Re: Re: Re: [PATCH] drm/nouveau/clk/gm20b: Fix memory leak in gm20b_clk_new > > If there's *any* error, it'll check the pointer, if it's non-NULL, > > it'll call the destructor. If kzalloc() fails, the pointer will be > > NULL, there's no double-free bug. *every* subdev is written this way > > to avoid duplicating cleanup logic. > Actually, gm20b_clk_new_speedo0() may have a bug here if kzalloc() > fails as it doesn't overwrite the previous pointer from > gm20b_clk_new(). That whole ctor() sequence is written a little > strangely. > It's clear to me, thank your for your explanation! As for gm20b_clk_new_speedo0(), I think its bug pattern is not very clear. Maybe we should keep it until we find an use chain that could lead to a bug. Regards, Dinghao
Powered by blists - more mailing lists