The struct field dmx_demux.frontend is often protected by the lock
dvb_demux.mutex when is accessed. Here is an example in
dvbdmx_connect_frontend():
mutex_lock(&dvbdemux->mutex);
demux->frontend = frontend;
mutex_unlock(&dvbdemux->mutex);
However, the variable demux->frontend is accessed without holding the lock
dvbdemux->mutex in dvbdmx_write():
if ((!demux->frontend) || (demux->frontend->source != DMX_MEMORY_FE))
In my opinion, this may be a harmful race, because if demux->fontend is set
to NULL right after the first condition is checked, a null-pointer
dereference can occur when accessing the field demux->frontend->source.
To fix this possible null-pointer dereference caused by data race, a lock
and unlock pair is added when accessing the variable demux->frontend.
Reported-by: BassCheck <[email protected]>
Signed-off-by: Tuo Li <[email protected]>
---
drivers/media/dvb-core/dvb_demux.c | 8 ++++++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/media/dvb-core/dvb_demux.c b/drivers/media/dvb-core/dvb_demux.c
index 7c4d86bfdd6c..d26738e3310a 100644
--- a/drivers/media/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb-core/dvb_demux.c
@@ -1140,9 +1140,13 @@ 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))
+
+ mutex_lock(&dvbdemux->mutex);
+ if ((!demux->frontend) || (demux->frontend->source != DMX_MEMORY_FE)) {
+ mutex_unlock(&dvbdemux->mutex);
return -EINVAL;
+ }
+ mutex_unlock(&dvbdemux->mutex);
p = memdup_user(buf, count);
if (IS_ERR(p))
--
2.34.1