linux-kernel - Re: [BUG] selftests/firmware: copious kernel memory leaks in test_fw_run_batch

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: <26fd581a-1b9f-4960-8457-61d725511cee@kili.mountain>
Date:   Tue, 28 Mar 2023 13:06:50 +0300
From:   Dan Carpenter <error27@...il.com>
To:     Mirsad Todorovac <mirsad.todorovac@....unizg.hr>,
        Luis Chamberlain <mcgrof@...nel.org>
Cc:     linux-kselftest@...r.kernel.org,
        LKML <linux-kernel@...r.kernel.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Russ Weight <russell.h.weight@...el.com>,
        Takashi Iwai <tiwai@...e.de>,
        Tianfei zhang <tianfei.zhang@...el.com>,
        Shuah Khan <shuah@...nel.org>,
        Colin Ian King <colin.i.king@...il.com>,
        Randy Dunlap <rdunlap@...radead.org>
Subject: Re: [BUG] selftests/firmware: copious kernel memory leaks in
 test_fw_run_batch_request()

On Tue, Mar 28, 2023 at 11:23:00AM +0200, Mirsad Todorovac wrote:
> The leaks are in chunks of 1024 bytes (+ overhead), but so far I could not
> reproduce w/o root privileges, as tests refuse to run as unprivileged user.
> (This is not the proof of non-existence of an unprivileged automated exploit
> that would exhaust the kernel memory at approx. rate 4 MB/hour on our setup.
> 
> This would mean about 96 MB / day or 3 GB / month (of kernel memory).

This is firmware testing stuff.  In the real world people aren't going
to run their test scripts in a loop for days.

There is no security implications.  This is root only.  Also if the
user could load firmware then that would be the headline.  Once someone
is can already load firmware then who cares if they leak 100MB per day?

It looks like if you call trigger_batched_requests_store() twice in a
row then it will leak memory.  Definitely test_fw_config->reqs is leaked.
That's different from what the bug report is complaining about, but the
point is that there are some obvious leaks.  It looks like you're
supposed to call trigger_batched_requests_store() in between runs?

There are other races like config_num_requests_store() should hold the
mutex over the call to test_dev_config_update_u8() instead of dropping
and retaking it.

regards,
dan carpenter