linux-kernel - Re: [PATCH] staging: mt29f_spinand: fix memory leak while programming pages

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:   Thu, 2 Aug 2018 09:12:29 +0300
From:   Dan Carpenter <dan.carpenter@...cle.com>
To:     Jheng-Jhong Wu <goodwater.wu@...il.com>
Cc:     devel@...verdev.osuosl.org, gregkh@...uxfoundation.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] staging: mt29f_spinand: fix memory leak while
 programming pages

On Thu, Aug 02, 2018 at 11:42:30AM +0800, Jheng-Jhong Wu wrote:
> Dear Dan,
> 
> I know what you wrote, but before the spinand device is removed and
> freed memory automatically, programming pages may do many many times.
> Assume we erase and rewrite a large part of the flash, then
> spinand_program_page() might exhaust memory if memory is not large
> enough.
> In fact, OOM indeed occured when I tested programming multi-pages by
> mtd_debug tool.
> If OOM was not caused by devm_kzalloc() in spinand_program_page(),
> what may exhaust memory?
> 

Ok.  That makes sense.  I didn't look at it in context.  You should say
that sort of thing in your changelog.  Looking at it now, the devm_
model isn't right for this function so we should change it to use normal
kzalloc().

We should fix all the error paths as well.  It looks like if this
function starts returning errors, we are probably toasted, but it's
still good practice to avoid slow leaks.

regards,
dan carpenter