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] [day] [month] [year] [list]

Message-ID: <CAAo+4rXdBpPTVu0XQvKwUwQUakNgP2ihdfOcz3zO=16wyVnSWw@mail.gmail.com>
Date: Wed, 21 Jan 2026 00:39:26 +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

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

Thank you indeed for the detailed response. It helps a lot, appreciate
much of the insightful reply that clarifies my long-standing
confusion...

Best regards,
Chengfeng