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: <f90010b2-7db1-412c-8526-47339bf4aa6b@acm.org>
Date: Mon, 13 Oct 2025 09:19:39 -0700
From: Bart Van Assche <bvanassche@....org>
To: Wonkon Kim <wkon.kim@...sung.com>, James.Bottomley@...senPartnership.com,
 martin.petersen@...cle.com, peter.wang@...iatek.com,
 linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] ufs: core: Initialize a variable mode for PA_PWRMODE

On 10/13/25 1:20 AM, Wonkon Kim wrote:
>> On 10/2/25 12:00 AM, Wonkon Kim wrote:
>>>    static bool ufshcd_is_pwr_mode_restore_needed(struct ufs_hba *hba)
>>>    {
>>>    	struct ufs_pa_layer_attr *pwr_info = &hba->pwr_info;
>>> -	u32 mode;
>>> +	u32 mode = 0;
>>>
>>>    	ufshcd_dme_get(hba, UIC_ARG_MIB(PA_PWRMODE), &mode);
>>
>> Since there is more code that passes a pointer to an uninitialized
>> variable to ufshcd_dme_get(), the untested patch below may be a better
>> solution:
>>
>> diff --git a/drivers/ufs/core/ufshcd.c b/drivers/ufs/core/ufshcd.c index
>> 127b691402f9..5226fbca29ec 100644
>> --- a/drivers/ufs/core/ufshcd.c
>> +++ b/drivers/ufs/core/ufshcd.c
>> @@ -4277,8 +4277,8 @@ int ufshcd_dme_get_attr(struct ufs_hba *hba, u32
>> attr_sel,
>>    			get, UIC_GET_ATTR_ID(attr_sel),
>>    			UFS_UIC_COMMAND_RETRIES - retries);
>>
>> -	if (mib_val && !ret)
>> -		*mib_val = uic_cmd.argument3;
>> +	if (mib_val)
>> +		*mib_val = ret == 0 ? uic_cmd.argument3 : 0;
>>
>>    	if (peer && (hba->quirks & UFSHCD_QUIRK_DME_PEER_ACCESS_AUTO_MODE)
>>    	    && pwr_mode_change)
>>
>>
> 
> There are some attributes to use 0 as valid value.
> e.g. PA_MAXRXHSGEAR is set to 0 for NO_HS=0
> If it has 0 for valid value, most of value 0 are regarded as FALSE, unsupported or minimum.
> And these cases seems to check ret for command success/fail in code.
> However, is it ok to set 0 for ufshcd_send_uic_cmd() fail?
> 
> If it can't, it needs to initialize mode.
> Value 0 for PA_PWRMODE is invalid.

Hi Wonkon,

Modifying ufshcd_dme_get_attr() doesn't exclude checking the return
value of ufshcd_dme_get_attr(). I propose to modify
ufshcd_dme_get_attr() such that it always initializes *mib_val and also
to check the ufshcd_dme_get_attr() return value wherever appropriate.

Thanks,

Bart.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ