linux-kernel - Re: [PATCH v2] scsi: pm8001: Fix data race in sysfs SAS address read

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: <88b042009eff363d098f8b80238329385837c6f7.camel@HansenPartnership.com>
Date: Fri, 16 Jan 2026 07:47:58 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Chengfeng Ye <dg573847474@...il.com>, Jinpu Wang <jinpu.wang@...os.com>
Cc: "Martin K . Petersen" <martin.petersen@...cle.com>, Bart Van Assche
 <bvanassche@....org>, linux-scsi@...r.kernel.org,
 linux-kernel@...r.kernel.org,  Chengfeng Ye <cyeaa@...nect.ust.hk>
Subject: Re: [PATCH v2] scsi: pm8001: Fix data race in sysfs SAS address read

On Fri, 2026-01-16 at 16:31 +0800, Chengfeng Ye wrote:
> > As James commented, sas address is uniq, not something changing all
> > the time.
> 
> I think maybe the more noteworthy case is sas address could be read
> when it is only partially initialized.

But again, do we care and is the proposed fix any better?  sas_addr is
just an indicator for tools to print.  All your fix would do is have us
output a fully uninitialized address instead which isn't really any
better (or worse) ... either way the output is wrong.  Effectively
there's a small period where the sas address may not be accurate and
tools can mitigate it by waiting.

> It might happen because the sysfs is mounted by scsi_add_host() at
> line 1196 of pm8001_init.c
> during probe, prior to the sas address being initialized by the
> pm8001_init_sas_add() called
> at line 1208. The small window could allow sysfs read return
> non-initialized (should be
> zero) or partially initialized sas address (due to the non-atomic
> read/write)

I think everyone would agree this can't happen for built in drivers
(because user space doesn't start until long after driver init), so
your theory above rests on a race between inserting the module and a
tool reading the file which can be fixed by waiting a short period ...
it just doesn't seem to be an important issue.

Regards,

James