linux-kernel - Re: [PATCH] staging: media: atomisp: Fix premature setting of HMM_BO_DEVICE

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: <836dc6b6-2821-47fc-8f24-0838f979af76@kernel.org>
Date: Tue, 1 Jul 2025 15:54:45 +0200
From: Hans de Goede <hansg@...nel.org>
To: Andy Shevchenko <andriy.shevchenko@...el.com>,
 Abdelrahman Fekry <abdelrahmanfekry375@...il.com>
Cc: Andy Shevchenko <andy.shevchenko@...il.com>, andy@...nel.org,
 hdegoede@...hat.com, mchehab@...nel.org, sakari.ailus@...ux.intel.com,
 gregkh@...uxfoundation.org, linux-kernel-mentees@...ts.linux.dev,
 linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
 linux-staging@...ts.linux.dev, skhan@...uxfoundation.com,
 dan.carpenter@...aro.org
Subject: Re: [PATCH] staging: media: atomisp: Fix premature setting of
 HMM_BO_DEVICE_INITED flag

Hi,

On 1-Jul-25 2:45 PM, Andy Shevchenko wrote:
> On Tue, Jul 01, 2025 at 02:58:43PM +0300, Abdelrahman Fekry wrote:
>> Hello Andy,
>> On Sat, Jun 28, 2025 at 10:52 PM Andy Shevchenko
>> <andy.shevchenko@...il.com> wrote:
>>> On Sat, Jun 28, 2025 at 8:26 AM Abdelrahman Fekry
>>> <abdelrahmanfekry375@...il.com> wrote:
> 
>>>> The HMM_BO_DEVICE_INITED flag was being set in hmm_bo_device_init()
>>>> before key initialization steps like kmem_cache_create(),
>>>> kmem_cache_alloc(), and __bo_init().
>>>>
>>>> This means that if any of these steps fail, the flag remains set,
>>>> misleading other parts of the driver (e.g. hmm_bo_alloc())
>>>> into thinking the device is initialized. This could lead
>>>> to undefined behavior or invalid memory use.
>>>
>>> Nice. Can you make some fault injection (temporary by modifying the
>>> code to always fail, for example) and actually prove this in practice?
>>> If so, the few (important) lines from the given Oops would be nice to
>>> have here.
> 
>> I have been trying to test it without having any intel atomisp
>> hardware and failed continuously, do you have any tips or maybe some
>> resources on how i can test this driver.
> 
> So, the easiest way as I can see it is to ask people who possess the HW to
> test, but you need to provide a testing patch (which can be applied on top
> of this one, for example).

I don't think it is worth testing the error path here,
the old code is obviously wrong.

What is interesting here is to see if the extra call to hmm_init()
in __hmm_alloc() is necessary at all.

And obviously hmm_init() needs to propagate the error return
from hmm_bo_init() right away instead of continuing if nothing
was wrong and then only returning the error at the end.

So it seems that there plenty of cleanup to do around this
without needing error injection to test all paths.

Actually I'm pretty sure that there will be quite a few
error-handling paths with bugs in the atomisp code given
its overall quality. But lets clean things up first, that
should make addressing any such cases easier.

Regards,

Hans