Re: [PATCH 0/2] scsi: target: fix CHAP_N handling

John Garry <[email protected]> Wed, 3 Jun 2026 09:24:19 +0100
Newsgroups org.kernel.vger.target-devel,org.kernel.vger.linux-scsi
Organization Oracle Corporation
Message-ID <[email protected]>
On 03/06/2026 00:19, David Disseldorp wrote:
> On Tue, 2 Jun 2026 17:42:57 +0100, John Garry wrote:
> 
>> On 02/06/2026 12:43, David Disseldorp wrote:
>>> The sashiko bot pointed out issues with CHAP_N handling recently, when
>>> reviewing a patch for a separate issue:
>>> https://urldefense.com/v3/__https://sashiko.dev/*/patchset/20260521151121.808477-1-hossu.alexandru*40gmail.com__;IyU!!ACWV5N9M2RV99hQ!MNesZJ3IsH9Mv0iZxHUcVmbC_3uwDkJgMhAX8i1TelyqqZD_dAq1cwIy6RtYI8D3boJh5iFeGhtTvfTX$
>>>     Since extract_param() unconditionally strips '0x' or '0b' prefixes and
>>>     alters the returned type, wouldn't a valid user with a name like '0xalice' or
>>>     '0bob' have their username mutated to 'alice' or 'ob'?
>>
>> is there a real world case or vulnerability being fixed here?
> 
> No vulnerability -  the "real world case" is as above: CHAP
> authentication currently fails if the CHAP username begins with 0x, 0b
> or the upper case variants. The bug is trivial to reproduce.
> 
Understood.

To me, this is a fix for a problem which does not exist. And even if the 
spec says it's possible, it does not mean that we need to support it. If 
0x prefix is part of the username, I think that problems should be expected.

Anyway, the code itself looks ok, so:

Reviewed-by: John Garry <[email protected]>

But the maintainer can make the judgement to take this obviously.