linux-kernel - Re: [PATCH] media: bt8xx: Fix a possible data race in buffer

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: <ZKLAxKKc1z53Bm+S@db550>
Date:   Mon, 3 Jul 2023 05:36:20 -0700
From:   Deborah Brouwer <deborah.brouwer@...labora.com>
To:     Tuo Li <islituo@...il.com>
Cc:     mchehab@...nel.org, hverkuil-cisco@...all.nl,
        linux-media@...r.kernel.org, linux-kernel@...r.kernel.org,
        baijiaju1990@...look.com, BassCheck <bass@...a.edu.cn>
Subject: Re: [PATCH] media: bt8xx: Fix a possible data race in buffer_queue()

On Wed, Jun 28, 2023 at 03:19:51PM +0800, Tuo Li wrote:
> The variable btv->loop_irq is often protected by the lock btv->s_lock when
> is accessed. Here is an example in bttv_irq_timeout():
> 
>   spin_lock_irqsave(&btv->s_lock,flags); 
>   ...
>   btv->loop_irq = 0;
>   ...
>   spin_unlock_irqrestore(&btv->s_lock,flags);
> 
> However, it is accessed without holding the lock btv->s_lock in 
> buffer_queue():
> 
>   btv->loop_irq |= 1;
> 
> And thus a data race can occur.
> To fix this possible data race, a lock and unlock pair is added when
> accessing the variable btv->loop_irq in buffer_queue().

hmm I am not sure why buffer_queue() didn't bother holding the
btv->s_lock but in the new version of the bttv driver that I have
been working on, the btv->s_lock is always held before changing
the loop_irq value. 

https://patchwork.linuxtv.org/project/linux-media/cover/cover.1682995256.git.deborah.brouwer@collabora.com/

When the bttv driver is converted to vb2, and the work is almost done,
the old buffer_queue() is totally eliminated, so I don't think it would
make sense to apply this patch now.

> 
> Reported-by: BassCheck <bass@...a.edu.cn>
> Signed-off-by: Tuo Li <islituo@...il.com>
> ---
>  drivers/media/pci/bt8xx/bttv-driver.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/media/pci/bt8xx/bttv-driver.c b/drivers/media/pci/bt8xx/bttv-driver.c
> index 734f02b91aa3..241c51951627 100644
> --- a/drivers/media/pci/bt8xx/bttv-driver.c
> +++ b/drivers/media/pci/bt8xx/bttv-driver.c
> @@ -1617,13 +1617,16 @@ buffer_queue(struct videobuf_queue *q, struct videobuf_buffer *vb)
>  	struct bttv_buffer *buf = container_of(vb,struct bttv_buffer,vb);
>  	struct bttv_fh *fh = q->priv_data;
>  	struct bttv    *btv = fh->btv;
> +	unsigned long flags;
>  
> +	spin_lock_irqsave(&btv->s_lock,flags);
>  	buf->vb.state = VIDEOBUF_QUEUED;
>  	list_add_tail(&buf->vb.queue,&btv->capture);
>  	if (!btv->curr.frame_irq) {
>  		btv->loop_irq |= 1;
>  		bttv_set_dma(btv, 0x03);
>  	}
> +	spin_unlock_irqrestore(&btv->s_lock,flags);
>  }
>  
>  static void buffer_release(struct videobuf_queue *q, struct videobuf_buffer *vb)
> -- 
> 2.34.1
>