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

Bumping this, as I still think it's worth addressing...

On Wed, 3 Jun 2026 09:24:19 +0100, John Garry wrote:

> 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.

IMO it's a real problem, e.g.: 'I changed my username from "bob" to
"0bob" and now I can't access my data.'

> Anyway, the code itself looks ok, so:
> 
> Reviewed-by: John Garry <[email protected]>
> 
> But the maintainer can make the judgement to take this obviously.

Thanks for the review.