linux-kernel - Re: [PATCH] scsi: pm8001: Fix potential TOCTOU race in pm8001_find

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAAo+4rX8HT_3zKEQ3vULN-B8StnwsT-7DQPoFCOedZLrMngASQ@mail.gmail.com>
Date: Tue, 20 Jan 2026 12:39:10 +0800
From: Chengfeng Ye <dg573847474@...il.com>
To: James Bottomley <James.Bottomley@...senpartnership.com>
Cc: "Martin K . Petersen" <martin.petersen@...cle.com>, Jack Wang <jinpu.wang@...ud.ionos.com>, 
	linux-scsi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] scsi: pm8001: Fix potential TOCTOU race in pm8001_find_tag

> > Sorry that I might miss something as I am not very familiar with the
> > code. But I also notice the find_tag() function is also invoked
> > inside the abort function (and invoked before the completion).
>
> This is part of the problem, though: you're apparently using some tool
> looking for data races in an ancient driver but most of what you find
> isn't significant and costs us review cycles to check.

Sorry indeed for the extra efforts caused. I am implementing an
experimental tool to check for concurrency issues. I didn't mean to
bother you on purpose (but apologize if it did happen), as I just like
to report some potential issues and improve the security of the
codebase by fixing them.

> So the theory now is that in the couple of instruction cycles between
> checking lldd_task and dereferencing it to find the tag, it goes null?
> That's so astronomically unlikely precisely because abort is only
> called on a task that timed out anyway and the completion function sets
> the state done flags, which sas error handling checks, long before it
> begins to free the lldd_task.

That is also the point that bothers me: some races like this one can
only happen under rare scheduling due to the small race windows
(despite not being totally impossible and might be reported by lockdep
one day), and could introduce a security impact (like a crash in this
case) when they happen.
Also like this one:
https://lore.kernel.org/linux-scsi/CAAo+4rVWOzkz+HMc99c2D8tf2ZuwYHq39+jejaXWxD-PvUAuOA@mail.gmail.com/T/#t,
it is a UAF race between device removal and ioctl path (if I did not
miss anything), if measured by CVSS, it could be scored as a
low-severity vulnerability.

Will be more than appreciated if can learn more about the community's
attitude toward this kind of data race issues: do you prefer to fix
them as a preventative measure (especially if the fix is harmless), or
only like to fix them until they are encountered during execution, or
like to fix them if it is in important code like subsystem core
instead of an ancient driver?

Thanks again for your reply.

Best regards,
Chengfeng