The dvb_demux functions handle frontend connectivity without holding
dvbdemux->mutex during checks, leading to TOCTOU race conditions. In
dvbdmx_write(), a concurrent dvbdmx_disconnect_frontend() can set
demux->frontend to NULL after the check, causing a potential NULL pointer
dereference. In dvbdmx_connect_frontend(), a concurrent connection could
set the frontend between the check and the lock. This allows the second
caller to overwrite the existing frontend, leading to resource leaks.
The dvb_demux module should use its own mutex to ensure thread safety
for these internal state checks.

Fix this by extending the lock scope. Move the frontend state checks
inside the dvbdemux->mutex critical section to ensure the state remains
stable during the operation.

This possible bug was found by our experimental static analysis tool,
which analyzes lock usage to detect TOCTOU issues.

Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Gui-Dong Han <hanguidong02@gmail.com>
---
v2:
* Remove unnecessary parentheses to fix checkpatch --strict warning, as
reported by Media CI robot.
---
 drivers/media/dvb-core/dvb_demux.c | 21 +++++++++++++--------
 1 file changed, 13 insertions(+), 8 deletions(-)

diff --git a/drivers/media/dvb-core/dvb_demux.c b/drivers/media/dvb-core/dvb_demux.c
index 7c4d86bfdd6c..38ffbbfef1f5 100644
--- a/drivers/media/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb-core/dvb_demux.c
@@ -1141,15 +1141,18 @@ static int dvbdmx_write(struct dmx_demux *demux, const char __user *buf, size_t
 	struct dvb_demux *dvbdemux = (struct dvb_demux *)demux;
 	void *p;
 
-	if ((!demux->frontend) || (demux->frontend->source != DMX_MEMORY_FE))
+	if (mutex_lock_interruptible(&dvbdemux->mutex))
+		return -ERESTARTSYS;
+
+	if (!demux->frontend || demux->frontend->source != DMX_MEMORY_FE) {
+		mutex_unlock(&dvbdemux->mutex);
 		return -EINVAL;
+	}
 
 	p = memdup_user(buf, count);
-	if (IS_ERR(p))
+	if (IS_ERR(p)) {
+		mutex_unlock(&dvbdemux->mutex);
 		return PTR_ERR(p);
-	if (mutex_lock_interruptible(&dvbdemux->mutex)) {
-		kfree(p);
-		return -ERESTARTSYS;
 	}
 	dvb_dmx_swfilter(dvbdemux, p, count);
 	kfree(p);
@@ -1202,11 +1205,13 @@ static int dvbdmx_connect_frontend(struct dmx_demux *demux,
 {
 	struct dvb_demux *dvbdemux = (struct dvb_demux *)demux;
 
-	if (demux->frontend)
-		return -EINVAL;
-
 	mutex_lock(&dvbdemux->mutex);
 
+	if (demux->frontend) {
+		mutex_unlock(&dvbdemux->mutex);
+		return -EINVAL;
+	}
+
 	demux->frontend = frontend;
 	mutex_unlock(&dvbdemux->mutex);
 	return 0;
-- 
2.43.0

…
> Fix this by extending the lock scope.
…

How do you think about to increase the application of scope-based resource management?
https://elixir.bootlin.com/linux/v6.19-rc5/source/include/linux/mutex.h#L253


> This possible bug was found by our experimental static analysis tool,
> which analyzes lock usage to detect TOCTOU issues.

* Do you refer to any other source code analysis approach than LR-Miner?

* Will any additional background information become more helpful here?


Regards,
Markus

On Tue, Jan 20, 2026 at 01:38:33PM +0100, Markus Elfring wrote:
> …
> > Fix this by extending the lock scope.
> …
> 
> How do you think about to increase the application of scope-based resource management?
> https://elixir.bootlin.com/linux/v6.19-rc5/source/include/linux/mutex.h#L253
> 
> 
> > This possible bug was found by our experimental static analysis tool,
> > which analyzes lock usage to detect TOCTOU issues.
> 
> * Do you refer to any other source code analysis approach than LR-Miner?
> 
> * Will any additional background information become more helpful here?
> 
> 
> Regards,
> Markus
> 

Hi,

This is the semi-friendly patch-bot of Greg Kroah-Hartman.

Markus, you seem to have sent a nonsensical or otherwise pointless
review comment to a patch submission on a Linux kernel developer mailing
list.  I strongly suggest that you not do this anymore.  Please do not
bother developers who are actively working to produce patches and
features with comments that, in the end, are a waste of time.

Patch submitter, please ignore Markus's suggestion; you do not need to
follow it at all.  The person/bot/AI that sent it is being ignored by
almost all Linux kernel maintainers for having a persistent pattern of
behavior of producing distracting and pointless commentary, and
inability to adapt to feedback.  Please feel free to also ignore emails
from them.

thanks,

greg k-h's patch email bot

On Tue, Jan 20, 2026 at 8:38 PM Markus Elfring <Markus.Elfring@web.de> wrote:
>
> …
> > Fix this by extending the lock scope.
> …
>
> How do you think about to increase the application of scope-based resource management?
> https://elixir.bootlin.com/linux/v6.19-rc5/source/include/linux/mutex.h#L253

I did not use scope-based resource management because it was
introduced into the kernel relatively recently. Since this patch fixes
a bug that has existed for a long time and needs to be backported to
older stable kernels, using standard mutex locking ensures better
compatibility and easier backporting.

> > This possible bug was found by our experimental static analysis tool,
> > which analyzes lock usage to detect TOCTOU issues.
>
> * Do you refer to any other source code analysis approach than LR-Miner?
>
> * Will any additional background information become more helpful here?

This is a new experimental static analysis tool we are developing.
There is no additional background information to share at this moment.

Thanks.