Re: [PATCH 01/11] iio: temperature: tmp006: fix information leak in triggered buffer

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 2 Dec 2024 20:28:12 +0100
Javier Carrasco <javier.carrasco.cruz@xxxxxxxxx> wrote:

> On 25/11/2024 22:16, Javier Carrasco wrote:
> > The 'scan' local struct is used to push data to user space from a
> > triggered buffer, but it has a hole between the two 16-bit data channels
> > and the timestamp. This hole is never initialized.
> > 
> > Initialize the struct to zero before using it to avoid pushing
> > uninitialized information to userspace.
> > 
> > Cc: stable@xxxxxxxxxxxxxxx
> > Fixes: 91f75ccf9f03 ("iio: temperature: tmp006: add triggered buffer support")
> > Signed-off-by: Javier Carrasco <javier.carrasco.cruz@xxxxxxxxx>
> > ---
> >  drivers/iio/temperature/tmp006.c | 2 ++
> >  1 file changed, 2 insertions(+)
> > 
> > diff --git a/drivers/iio/temperature/tmp006.c b/drivers/iio/temperature/tmp006.c
> > index 0c844137d7aa..02b27f471baa 100644
> > --- a/drivers/iio/temperature/tmp006.c
> > +++ b/drivers/iio/temperature/tmp006.c
> > @@ -252,6 +252,8 @@ static irqreturn_t tmp006_trigger_handler(int irq, void *p)
> >  	} scan;
> >  	s32 ret;
> >  
> > +	memset(&scan, 0, sizeof(scan));
> > +
> >  	ret = i2c_smbus_read_word_data(data->client, TMP006_VOBJECT);
> >  	if (ret < 0)
> >  		goto err;
> >   
> 
> @Jonathan, this patch requires 91f75ccf9f03 ("iio: temperature: tmp006:
> add triggered buffer support"), which is in the mainline kernel, but not
> accessible from iio/fixes-to-greg.
> 

Yeah. That happens briefly around merge windows.  In this particular
case to just after rc1 as there were some tree wide refactors that
needed merging.  Sometimes it takes me a few days to find the time to
rebase.  Doing anything mid merge window is a challenge at best.

> Is there any branch in IIO where the fixes and the new features are put
> together? I would like to rebase my series to automatically get rid of
> the applied patches, but iio/fixes-to-greg (where the patches were
> applied) does not have the feature this patch fixes. Of course I can
> manually drop the applied patches, but that is error-prone.
No. I don't push out such a tree, though I often do test merges.

You could use linux-next for your automation as that normally contains
both the fixes-togreg and togreg branches. Mind you that doesn't right
now because of the merge issue mentioned above,

Jonathan

> 
> This is not the first time I face this inconvenience, and I suppose
> there is a cleaner way that I might be missing, or maybe that branch I
> am looking for already exists.
> 
> Thanks and best regards,
> Javier Carrasco





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Input]     [Linux Kernel]     [Linux SCSI]     [X.org]

  Powered by Linux