linux-kernel - Re: [PATCH v3 4.14 1/1] test_firmware: fix the memory leaks with the reqs buffer

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] [day] [month] [year] [list]

Date:   Tue, 8 Aug 2023 21:26:31 +0200
From:   Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
To:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     linux-kernel@...r.kernel.org, Luis Chamberlain <mcgrof@...nel.org>,
        Russ Weight <russell.h.weight@...el.com>,
        Tianfei Zhang <tianfei.zhang@...el.com>,
        Shuah Khan <shuah@...nel.org>,
        Colin Ian King <colin.i.king@...il.com>,
        Randy Dunlap <rdunlap@...radead.org>,
        linux-kselftest@...r.kernel.org, stable@...r.kernel.org,
        Dan Carpenter <error27@...il.com>, Takashi Iwai <tiwai@...e.de>
Subject: Re: [PATCH v3 4.14 1/1] test_firmware: fix the memory leaks with the
 reqs buffer



On 8/8/23 09:35, Greg Kroah-Hartman wrote:
> On Tue, Aug 08, 2023 at 08:24:43AM +0200, Mirsad Todorovac wrote:
>> On 8/8/23 06:28, Greg Kroah-Hartman wrote:
>>> On Mon, Aug 07, 2023 at 08:28:04PM +0200, Mirsad Todorovac wrote:
>>>> On 8/7/23 11:15, Greg Kroah-Hartman wrote:
>>>>> On Fri, Aug 04, 2023 at 07:00:18PM +0200, Mirsad Todorovac wrote:
>>>>>> [ commit be37bed754ed90b2655382f93f9724b3c1aae847 upstream ]
>>>>>>
>>>>>> Dan Carpenter spotted that test_fw_config->reqs will be leaked if
>>>>>> trigger_batched_requests_store() is called two or more times.
>>>>>> The same appears with trigger_batched_requests_async_store().
>>>>>>
>>>>>> This bug wasn't triggered by the tests, but observed by Dan's visual
>>>>>> inspection of the code.
>>>>>>
>>>>>> The recommended workaround was to return -EBUSY if test_fw_config->reqs
>>>>>> is already allocated.
>>>>>>
>>>>>> Fixes: c92316bf8e94 ("test_firmware: add batched firmware tests")
>>>>>> Cc: Luis Chamberlain <mcgrof@...nel.org>
>>>>>> Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
>>>>>> Cc: Russ Weight <russell.h.weight@...el.com>
>>>>>> Cc: Tianfei Zhang <tianfei.zhang@...el.com>
>>>>>> Cc: Shuah Khan <shuah@...nel.org>
>>>>>> Cc: Colin Ian King <colin.i.king@...il.com>
>>>>>> Cc: Randy Dunlap <rdunlap@...radead.org>
>>>>>> Cc: linux-kselftest@...r.kernel.org
>>>>>> Cc: stable@...r.kernel.org # v4.14
>>>>>> Suggested-by: Dan Carpenter <error27@...il.com>
>>>>>> Suggested-by: Takashi Iwai <tiwai@...e.de>
>>>>>> Link: https://lore.kernel.org/r/20230509084746.48259-2-mirsad.todorovac@alu.unizg.hr
>>>>>> Signed-off-by: Mirsad Todorovac <mirsad.todorovac@....unizg.hr>
>>>>>>
>>>>>> [ This fix is applied against the 4.14 stable branch. There are no changes to the ]
>>>>>> [ fix in code when compared to the upstread, only the reformatting for backport.  ]
>>>>>
>>>>> Thanks for all of these, now queued up.
>>>>
>>>> No problem, I should have done it right the first time to reduce your load.
>>>>
>>>> I really believe that backporting bug fix patches is important because many systems
>>>> cannot upgrade because of the legacy apps and hardware, to state the obvious.
>>>
>>> What "legacy apps" rely on a specific kernel version?
>>
>> Hi, Mr. Greg,
>>
>> Actually, in our particular case, it was the Eprints that required old mysql on Debian stretch
>> rather than MariaDB that came with Buster. So, the release required particular kernel version (4.9).
> 
> So what happens when this kernel becomes end-of-life?

I guess by now I could maintain the 4.19 line, with the bug fixes and the security fixes,
but it would impose significant overhead to already overwhelmed IT department.

I could use the same config and produce the same kernel, but w/o the testing as it would
happen w the distro kernels.

>> Of course, we can upgrade to any mainline kernel, but that is no longer a tested distro kernel,
>> and faults would be blamed on me entirely. Plus the overhead of regular patching ...
> 
> You should be doing regular patching for any LTS kernel as well, right?
> Same for testing, there should not be any difference in testing any
> kernel update be it on a LTS branch, or between major versions.

Sure, but apt-get dist-upgrade is easier than rebuilding the kernel. I say, we'd have to
get the necessary "blessings" to make this routine or procedure. Now we have the machines
that could build a recent kernel in less than an hour, but it wasn't always so :-)

We still do not have a twin test server for each single one of our production releases.

> anyway, good luck!

Thanks, I think we'll need it.

Kind regards,
Mirsad Todorovac