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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <b03e802fce29c90bbc4342e7254c3adb9f48bbf7.camel@HansenPartnership.com>
Date: Tue, 20 Jan 2026 09:28:07 -0500
From: James Bottomley <James.Bottomley@...senPartnership.com>
To: Chengfeng Ye <dg573847474@...il.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

On Tue, 2026-01-20 at 12:39 +0800, Chengfeng Ye wrote:
> > > 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.

But this too is a problem: fixes aren't free.  In fact a portion of the
patches sold as a bug fix eventually turn out to introduce a bug ...
and that new bug is one we didn't have before.  This is just a sad
consequence of the fact that all code produced by humans contains bugs.
The longer code is used, the more chance the bugs are found and the
less buggy it becomes (even with the bug fixes introducing bugs).  So
for really old drivers we assume most of the significant bugs have been
found and we try not to perturb the code base to avoid introducing new
bugs that, given the small and decreasing user base, will take ages to
find and eliminate.

On the scale of serious problems in older drivers, theoretical data
races that cause a crash don't rank highly simply because if the race
window were significant we'd already have seen it (the detection signal
is obvious and users aren't shy about reporting driver crashes). That
makes the probability of encountering the issue in the field way lower
than the probability that any fix will introduce a new bug.  So the
balance of risks argues against applying any fix.

Regards,

James