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]
Message-ID: <563d673a-19e8-f161-ab2f-6e8acd420531@oss.qualcomm.com>
Date: Tue, 25 Nov 2025 10:09:46 +0530
From: Dikshita Agarwal <dikshita.agarwal@....qualcomm.com>
To: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Vikash Garodia <vikash.garodia@....qualcomm.com>,
        Bryan O'Donoghue <bod@...nel.org>,
        Mauro Carvalho Chehab
 <mchehab@...nel.org>,
        Viswanath Boma <quic_vboma@...cinc.com>,
        Stanimir Varbanov <stanimir.k.varbanov@...il.com>
Cc: Konrad Dybcio <konradybcio@...nel.org>, linux-media@...r.kernel.org,
        linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
        stable@...r.kernel.org, Renjiang Han <renjiang.han@....qualcomm.com>,
        Mecid Urganci <mecid@...omediagroup.de>
Subject: Re: [PATCH] media: venus: vdec: restrict EOS addr quirk to IRIS2 only



On 11/24/2025 4:36 PM, Konrad Dybcio wrote:
> On 11/24/25 11:58 AM, Dikshita Agarwal wrote:
>> On SM8250 (IRIS2) with firmware older than 1.0.087, the firmware could
>> not handle a dummy device address for EOS buffers, so a NULL device
>> address is sent instead. The existing check used IS_V6() alongside a
>> firmware version gate:
>>
>>     if (IS_V6(core) && is_fw_rev_or_older(core, 1, 0, 87))
>>         fdata.device_addr = 0;
>>     else
>> 	fdata.device_addr = 0xdeadb000;
>>
>> However, SC7280 which is also V6, uses a firmware string of the form
>> "1.0.<commit-hash>", which the version parser translates to 1.0.0. This
>> unintentionally satisfies the `is_fw_rev_or_older(..., 1, 0, 87)`
>> condition on SC7280. Combined with IS_V6() matching there as well, the
>> quirk is incorrectly applied to SC7280, causing VP9 decode failures.
>>
>> Constrain the check to IRIS2 (SM8250) only, which is the only platform
>> that needed this quirk, by replacing IS_V6() with IS_IRIS2(). This
>> restores correct behavior on SC7280 (no forced NULL EOS buffer address).
> 
> This really needs an inline comment, since you provided a long backstory
> explaining how fragile this check is

Sure, will add.

> 
>> Fixes: 47f867cb1b63 ("media: venus: fix EOS handling in decoder stop command")
>> Cc: stable@...r.kernel.org
>> Reported-by: Mecid <notifications@...hub.com>
> 
> This is certainly not a correct email to use... it will at best bounce
> or get ignored and at worst cause some unintended interactions with gh if
> you have an account registered with the email you're sending from 
> 
> I opened that person's GH profile and grabbed the git identify of a recent
> commit made attributed to this account:
> 
> Mecid Urganci <mecid@...omediagroup.de>

Thanks for this, I tried but couldn't find the proper id, will fix in v2.

Regards,
Dikshita
> 
> (+CC Mecid, -CC github, fwiw)
> 
> Konrad

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ