Message ID | 99e158c0-1273-2500-da9e-b5ab31cba889@embeddedor.com (mailing list archive) |
---|---|
State | New, archived |
Headers | show |
Em Thu, 26 Apr 2018 16:41:56 -0500 "Gustavo A. R. Silva" <gustavo@embeddedor.com> escreveu: > Hi Mauro, > > On 04/23/2018 02:17 PM, Mauro Carvalho Chehab wrote: > > Em Mon, 23 Apr 2018 14:11:02 -0500 > > > > Thanks, I 'll mark this series as rejected at patchwork.linuxtv.org. > > Please feel free to resubmit any patch if they represent a real > > threat, adding a corresponding description about the threat scenario > > at the body of the e-mail. > > > >> Sorry for the noise and thanks for the feedback. > > > > Anytime. > > > > I noticed you changed the status of this series from rejected to new. Yes. > Also, there are other similar issues in media/pci/ Well, the issues will be there everywhere on all media drivers. I marked your patches because I need to study it carefully, after Peter's explanations. My plan is to do it next week. Still not sure if the approach you took is the best one or not. As I said, one possibility is to change the way v4l2-core handles VIDIOC_ENUM_foo ioctls, but that would be make harder to -stable backports. I need a weekend to sleep on it. > > I can write proper patches for all of them if you agree those are not > False Positives: > > diff --git a/drivers/media/pci/cx18/cx18-ioctl.c > b/drivers/media/pci/cx18/cx18-ioctl.c > index 80b902b..63f4388 100644 > --- a/drivers/media/pci/cx18/cx18-ioctl.c > +++ b/drivers/media/pci/cx18/cx18-ioctl.c > @@ -36,6 +36,8 @@ > #include <media/tveeprom.h> > #include <media/v4l2-event.h> > > +#include <linux/nospec.h> > + > u16 cx18_service2vbi(int type) > { > switch (type) { > @@ -488,8 +490,9 @@ static int cx18_enum_fmt_vid_cap(struct file *file, > void *fh, > }, > }; > > - if (fmt->index > ARRAY_SIZE(formats) - 1) > + if (fmt->index >= ARRAY_SIZE(formats)) > return -EINVAL; > + fmt->index = array_index_nospec(fmt->index, ARRAY_SIZE(formats)); > *fmt = formats[fmt->index]; > return 0; > } > diff --git a/drivers/media/pci/saa7134/saa7134-video.c > b/drivers/media/pci/saa7134/saa7134-video.c > index 1a50ec9..d93cf09 100644 > --- a/drivers/media/pci/saa7134/saa7134-video.c > +++ b/drivers/media/pci/saa7134/saa7134-video.c > @@ -30,6 +30,8 @@ > #include <media/v4l2-event.h> > #include <media/i2c/saa6588.h> > > +#include <linux/nospec.h> > + > /* ------------------------------------------------------------------ */ > > unsigned int video_debug; > @@ -1819,6 +1821,8 @@ static int saa7134_enum_fmt_vid_cap(struct file > *file, void *priv, > if (f->index >= FORMATS) > return -EINVAL; > > + f->index = array_index_nospec(f->index, FORMATS); > + > strlcpy(f->description, formats[f->index].name, > sizeof(f->description)); > > diff --git a/drivers/media/pci/tw68/tw68-video.c > b/drivers/media/pci/tw68/tw68-video.c > index 8c1f4a0..a6cfb4b 100644 > --- a/drivers/media/pci/tw68/tw68-video.c > #include <media/v4l2-event.h> > #include <media/videobuf2-dma-sg.h> > > +#include <linux/nospec.h> > + > #include "tw68.h" > #include "tw68-reg.h" > > @@ -789,6 +791,8 @@ static int tw68_enum_fmt_vid_cap(struct file *file, > void *priv, > if (f->index >= FORMATS) > return -EINVAL; > > + f->index = array_index_nospec(f->index, FORMATS); > + > strlcpy(f->description, formats[f->index].name, > sizeof(f->description)); > > diff --git a/drivers/media/pci/tw686x/tw686x-video.c > b/drivers/media/pci/tw686x/tw686x-video.c > index c3fafa9..281d722 100644 > --- a/drivers/media/pci/tw686x/tw686x-video.c > +++ b/drivers/media/pci/tw686x/tw686x-video.c > @@ -25,6 +25,8 @@ > #include "tw686x.h" > #include "tw686x-regs.h" > > +#include <linux/nospec.h> > + > #define TW686X_INPUTS_PER_CH 4 > #define TW686X_VIDEO_WIDTH 720 > #define TW686X_VIDEO_HEIGHT(id) ((id & V4L2_STD_525_60) > ? 480 : 576) > @@ -981,6 +983,7 @@ static int tw686x_enum_fmt_vid_cap(struct file > *file, void *priv, > { > if (f->index >= ARRAY_SIZE(formats)) > return -EINVAL; > + f->index = array_index_nospec(f->index, ARRAY_SIZE(formats)); > f->pixelformat = formats[f->index].fourcc; > return 0; > } > > > Thanks > -- > Gustavo Thanks, Mauro
Hi Mauro, On 04/26/2018 06:42 PM, Mauro Carvalho Chehab wrote: >> >> I noticed you changed the status of this series from rejected to new. > > Yes. > >> Also, there are other similar issues in media/pci/ > > Well, the issues will be there everywhere on all media drivers. > > I marked your patches because I need to study it carefully, after > Peter's explanations. My plan is to do it next week. Still not > sure if the approach you took is the best one or not. > > As I said, one possibility is to change the way v4l2-core handles > VIDIOC_ENUM_foo ioctls, but that would be make harder to -stable > backports. > > I need a weekend to sleep on it. > I'm curious about how you finally resolved to handle these issues. I noticed Smatch is no longer reporting them. Thanks -- Gustavo
Em Mon, 14 May 2018 22:31:37 -0500 "Gustavo A. R. Silva" <gustavo@embeddedor.com> escreveu: > Hi Mauro, > > On 04/26/2018 06:42 PM, Mauro Carvalho Chehab wrote: > > >> > >> I noticed you changed the status of this series from rejected to new. > > > > Yes. > > > >> Also, there are other similar issues in media/pci/ > > > > Well, the issues will be there everywhere on all media drivers. > > > > I marked your patches because I need to study it carefully, after > > Peter's explanations. My plan is to do it next week. Still not > > sure if the approach you took is the best one or not. > > > > As I said, one possibility is to change the way v4l2-core handles > > VIDIOC_ENUM_foo ioctls, but that would be make harder to -stable > > backports. > > > > I need a weekend to sleep on it. > > > > I'm curious about how you finally resolved to handle these issues. > > I noticed Smatch is no longer reporting them. There was no direct fix for it, but maybe this patch has something to do with the smatch error report cleanup: commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 Author: Sami Tolvanen <samitolvanen@google.com> Date: Tue May 8 13:56:12 2018 -0400 media: v4l2-ioctl: replace IOCTL_INFO_STD with stub functions This change removes IOCTL_INFO_STD and adds stub functions where needed using the DEFINE_V4L_STUB_FUNC macro. This fixes indirect call mismatches with Control-Flow Integrity, caused by calling standard ioctls using a function pointer that doesn't match the function type. Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Signed-off-by: Hans Verkuil <hansverk@cisco.com> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> > > Thanks > -- > Gustavo Thanks, Mauro
On Tue, May 15, 2018 at 08:59:53AM -0300, Mauro Carvalho Chehab wrote: > Em Mon, 14 May 2018 22:31:37 -0500 > "Gustavo A. R. Silva" <gustavo@embeddedor.com> escreveu: > > > Hi Mauro, > > > > On 04/26/2018 06:42 PM, Mauro Carvalho Chehab wrote: > > > > >> > > >> I noticed you changed the status of this series from rejected to new. > > > > > > Yes. > > > > > >> Also, there are other similar issues in media/pci/ > > > > > > Well, the issues will be there everywhere on all media drivers. > > > > > > I marked your patches because I need to study it carefully, after > > > Peter's explanations. My plan is to do it next week. Still not > > > sure if the approach you took is the best one or not. > > > > > > As I said, one possibility is to change the way v4l2-core handles > > > VIDIOC_ENUM_foo ioctls, but that would be make harder to -stable > > > backports. > > > > > > I need a weekend to sleep on it. > > > > > > > I'm curious about how you finally resolved to handle these issues. > > > > I noticed Smatch is no longer reporting them. > > There was no direct fix for it, but maybe this patch has something > to do with the smatch error report cleanup: > > commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 > Author: Sami Tolvanen <samitolvanen@google.com> > Date: Tue May 8 13:56:12 2018 -0400 > > media: v4l2-ioctl: replace IOCTL_INFO_STD with stub functions > > This change removes IOCTL_INFO_STD and adds stub functions where > needed using the DEFINE_V4L_STUB_FUNC macro. This fixes indirect call > mismatches with Control-Flow Integrity, caused by calling standard > ioctls using a function pointer that doesn't match the function type. > > Signed-off-by: Sami Tolvanen <samitolvanen@google.com> > Signed-off-by: Hans Verkuil <hansverk@cisco.com> > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> > Possibly... There was an ancient bug in Smatch's function pointer handling. I just pushed a fix for it now so the warning is there on linux-next. regards, dan carpenter
On 05/15/2018 09:16 AM, Dan Carpenter wrote: >>> >>> I'm curious about how you finally resolved to handle these issues. >>> >>> I noticed Smatch is no longer reporting them. >> >> There was no direct fix for it, but maybe this patch has something >> to do with the smatch error report cleanup: >> >> commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 >> Author: Sami Tolvanen <samitolvanen@google.com> >> Date: Tue May 8 13:56:12 2018 -0400 >> >> media: v4l2-ioctl: replace IOCTL_INFO_STD with stub functions >> >> This change removes IOCTL_INFO_STD and adds stub functions where >> needed using the DEFINE_V4L_STUB_FUNC macro. This fixes indirect call >> mismatches with Control-Flow Integrity, caused by calling standard >> ioctls using a function pointer that doesn't match the function type. >> >> Signed-off-by: Sami Tolvanen <samitolvanen@google.com> >> Signed-off-by: Hans Verkuil <hansverk@cisco.com> >> Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> >> Thanks, Mauro. > > Possibly... There was an ancient bug in Smatch's function pointer > handling. I just pushed a fix for it now so the warning is there on > linux-next. > Dan, These are all the Spectre media issues I see smatch is reporting in linux-next-20180515: drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() warn: potential spectre issue 'pin->error_inj_args' drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() warn: potential spectre issue 'ca->slot_info' (local cap) drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: potential spectre issue 'p->ule_next_hdr' I pulled the latest changes from the smatch repository and compiled it. I'm running smatch v0.5.0-4459-g2f66d40 now. Is this the latest version? I wonder if there is anything I might be missing. Thanks -- Gustavo
On Tue, May 15, 2018 at 12:29:10PM -0500, Gustavo A. R. Silva wrote: > > > On 05/15/2018 09:16 AM, Dan Carpenter wrote: > > > > > > > > I'm curious about how you finally resolved to handle these issues. > > > > > > > > I noticed Smatch is no longer reporting them. > > > > > > There was no direct fix for it, but maybe this patch has something > > > to do with the smatch error report cleanup: > > > > > > commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 > > > Author: Sami Tolvanen <samitolvanen@google.com> > > > Date: Tue May 8 13:56:12 2018 -0400 > > > > > > media: v4l2-ioctl: replace IOCTL_INFO_STD with stub functions > > > This change removes IOCTL_INFO_STD and adds stub functions where > > > needed using the DEFINE_V4L_STUB_FUNC macro. This fixes indirect call > > > mismatches with Control-Flow Integrity, caused by calling standard > > > ioctls using a function pointer that doesn't match the function type. > > > Signed-off-by: Sami Tolvanen <samitolvanen@google.com> > > > Signed-off-by: Hans Verkuil <hansverk@cisco.com> > > > Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> > > > > > Thanks, Mauro. > > > > > Possibly... There was an ancient bug in Smatch's function pointer > > handling. I just pushed a fix for it now so the warning is there on > > linux-next. > > > > Dan, > > These are all the Spectre media issues I see smatch is reporting in > linux-next-20180515: > > drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() > warn: potential spectre issue 'pin->error_inj_args' > drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() warn: > potential spectre issue 'ca->slot_info' (local cap) > drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: > potential spectre issue 'p->ule_next_hdr' > > I pulled the latest changes from the smatch repository and compiled it. > > I'm running smatch v0.5.0-4459-g2f66d40 now. Is this the latest version? > > I wonder if there is anything I might be missing. > You'd need to rebuild the db (possibly twice but definitely once). regards, dan carpenter
On 05/15/2018 02:39 PM, Dan Carpenter wrote: >> Dan, >> >> These are all the Spectre media issues I see smatch is reporting in >> linux-next-20180515: >> >> drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() >> warn: potential spectre issue 'pin->error_inj_args' >> drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() warn: >> potential spectre issue 'ca->slot_info' (local cap) >> drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: >> potential spectre issue 'p->ule_next_hdr' >> >> I pulled the latest changes from the smatch repository and compiled it. >> >> I'm running smatch v0.5.0-4459-g2f66d40 now. Is this the latest version? >> >> I wonder if there is anything I might be missing. >> > > You'd need to rebuild the db (possibly twice but definitely once). > Hi Dan, After rebuilding the db (once), these are all the Spectre media warnings I get: drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: potential spectre issue 'ddbs' drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: potential spectre issue 'pdev->port' drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: potential spectre issue 'idev->input' drivers/media/dvb-core/dvb_ca_en50221.c:1400 dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue 'ca->slot_info' (local cap) drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() warn: potential spectre issue 'ca->slot_info' (local cap) drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: potential spectre issue 'p->ule_next_hdr' drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential spectre issue 'dvbnet->device' (local cap) drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() warn: potential spectre issue 'pin->error_inj_args' I just want to double check if you are getting the same output. In case you are getting the same, then what Mauro commented about these issues: https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277 being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems to be correct. Thanks -- Gustavo
On 05/16/2018 08:14 PM, Gustavo A. R. Silva wrote: > > > On 05/15/2018 02:39 PM, Dan Carpenter wrote: >>> Dan, >>> >>> These are all the Spectre media issues I see smatch is reporting in >>> linux-next-20180515: >>> >>> drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() >>> warn: potential spectre issue 'pin->error_inj_args' >>> drivers/media/dvb-core/dvb_ca_en50221.c:1479 >>> dvb_ca_en50221_io_write() warn: >>> potential spectre issue 'ca->slot_info' (local cap) >>> drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: >>> potential spectre issue 'p->ule_next_hdr' >>> >>> I pulled the latest changes from the smatch repository and compiled it. >>> >>> I'm running smatch v0.5.0-4459-g2f66d40 now. Is this the latest version? >>> >>> I wonder if there is anything I might be missing. >>> >> >> You'd need to rebuild the db (possibly twice but definitely once). >> > > Hi Dan, > > After rebuilding the db (once), these are all the Spectre media warnings > I get: > > drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: > potential spectre issue 'ddbs' > drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: > potential spectre issue 'pdev->port' > drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: > potential spectre issue 'idev->input' > drivers/media/dvb-core/dvb_ca_en50221.c:1400 > dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue > 'ca->slot_info' (local cap) > drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() > warn: potential spectre issue 'ca->slot_info' (local cap) > drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: > potential spectre issue 'p->ule_next_hdr' > drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential > spectre issue 'dvbnet->device' (local cap) > drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() > warn: potential spectre issue 'pin->error_inj_args' > > I just want to double check if you are getting the same output. In case > you are getting the same, then what Mauro commented about these issues: > > https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277 > > being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems > to be correct. > Interesting, I've rebuild the db twice and now I get a total of 75 Spectre warnings in drivers/media -- Gustavo
Em Thu, 17 May 2018 05:36:03 -0500 "Gustavo A. R. Silva" <gustavo@embeddedor.com> escreveu: > > > On 05/16/2018 08:14 PM, Gustavo A. R. Silva wrote: > > > > > > On 05/15/2018 02:39 PM, Dan Carpenter wrote: > >> You'd need to rebuild the db (possibly twice but definitely once). How? Here, I just pull from your git tree and do a "make". At most, make clean; make. > >> > > > > Hi Dan, > > > > After rebuilding the db (once), these are all the Spectre media warnings > > I get: > > > > drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: > > potential spectre issue 'ddbs' > > drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: > > potential spectre issue 'pdev->port' > > drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: > > potential spectre issue 'idev->input' > > drivers/media/dvb-core/dvb_ca_en50221.c:1400 > > dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue > > 'ca->slot_info' (local cap) > > drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() > > warn: potential spectre issue 'ca->slot_info' (local cap) > > drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: > > potential spectre issue 'p->ule_next_hdr' > > drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential > > spectre issue 'dvbnet->device' (local cap) > > drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() > > warn: potential spectre issue 'pin->error_inj_args' > > > > I just want to double check if you are getting the same output. In case > > you are getting the same, then what Mauro commented about these issues: > > > > https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277 > > > > being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems > > to be correct. > > > > Interesting, I've rebuild the db twice and now I get a total of 75 > Spectre warnings in drivers/media That makes more sense to me, as the same pattern is used by almost all VIDIOC_ENUM_foo ioctls. Thanks, Mauro
Em Thu, 17 May 2018 08:34:40 -0300 Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu: > Em Thu, 17 May 2018 05:36:03 -0500 > "Gustavo A. R. Silva" <gustavo@embeddedor.com> escreveu: > > > > > > > On 05/16/2018 08:14 PM, Gustavo A. R. Silva wrote: > > > > > > > > > On 05/15/2018 02:39 PM, Dan Carpenter wrote: > > > >> You'd need to rebuild the db (possibly twice but definitely once). > > How? Here, I just pull from your git tree and do a "make". At most, > make clean; make. Never mind. Found it using grep. I'm running this: make allyesconfig /devel/smatch/smatch_scripts/build_kernel_data.sh /devel/smatch/smatch_scripts/build_kernel_data.sh > > > >> > > > > > > Hi Dan, > > > > > > After rebuilding the db (once), these are all the Spectre media warnings > > > I get: > > > > > > drivers/media/pci/ddbridge/ddbridge-core.c:233 ddb_redirect() warn: > > > potential spectre issue 'ddbs' > > > drivers/media/pci/ddbridge/ddbridge-core.c:243 ddb_redirect() warn: > > > potential spectre issue 'pdev->port' > > > drivers/media/pci/ddbridge/ddbridge-core.c:252 ddb_redirect() warn: > > > potential spectre issue 'idev->input' > > > drivers/media/dvb-core/dvb_ca_en50221.c:1400 > > > dvb_ca_en50221_io_do_ioctl() warn: potential spectre issue > > > 'ca->slot_info' (local cap) > > > drivers/media/dvb-core/dvb_ca_en50221.c:1479 dvb_ca_en50221_io_write() > > > warn: potential spectre issue 'ca->slot_info' (local cap) > > > drivers/media/dvb-core/dvb_net.c:252 handle_one_ule_extension() warn: > > > potential spectre issue 'p->ule_next_hdr' > > > drivers/media/dvb-core/dvb_net.c:1483 dvb_net_do_ioctl() warn: potential > > > spectre issue 'dvbnet->device' (local cap) > > > drivers/media/cec/cec-pin-error-inj.c:170 cec_pin_error_inj_parse_line() > > > warn: potential spectre issue 'pin->error_inj_args' > > > > > > I just want to double check if you are getting the same output. In case > > > you are getting the same, then what Mauro commented about these issues: > > > > > > https://patchwork.linuxtv.org/project/linux-media/list/?submitter=7277 > > > > > > being resolved by commit 3ad3b7a2ebaefae37a7eafed0779324987ca5e56 seems > > > to be correct. > > > > > > > Interesting, I've rebuild the db twice and now I get a total of 75 > > Spectre warnings in drivers/media > > That makes more sense to me, as the same pattern is used by almost all > VIDIOC_ENUM_foo ioctls. > > Thanks, > Mauro Thanks, Mauro
Em Thu, 17 May 2018 08:43:24 -0300 Mauro Carvalho Chehab <mchehab+samsung@kernel.org> escreveu: > > > > On 05/15/2018 02:39 PM, Dan Carpenter wrote: > > > > > >> You'd need to rebuild the db (possibly twice but definitely once). > > > > How? Here, I just pull from your git tree and do a "make". At most, > > make clean; make. > > Never mind. Found it using grep. I'm running this: > > make allyesconfig > /devel/smatch/smatch_scripts/build_kernel_data.sh > /devel/smatch/smatch_scripts/build_kernel_data.sh It seems that something is broken... getting this error/warning: DBD::SQLite::db do failed: unrecognized token: "'end + strlen(" " at /devel/smatch/smatch_scripts/../smatch_data/db/fill_db_sql.pl line 32, <WARNS> line 2938054. Thanks, Mauro
diff --git a/drivers/media/pci/cx18/cx18-ioctl.c b/drivers/media/pci/cx18/cx18-ioctl.c index 80b902b..63f4388 100644 --- a/drivers/media/pci/cx18/cx18-ioctl.c +++ b/drivers/media/pci/cx18/cx18-ioctl.c @@ -36,6 +36,8 @@ #include <media/tveeprom.h> #include <media/v4l2-event.h> +#include <linux/nospec.h> + u16 cx18_service2vbi(int type) { switch (type) { @@ -488,8 +490,9 @@ static int cx18_enum_fmt_vid_cap(struct file *file, void *fh, }, }; - if (fmt->index > ARRAY_SIZE(formats) - 1) + if (fmt->index >= ARRAY_SIZE(formats)) return -EINVAL; + fmt->index = array_index_nospec(fmt->index, ARRAY_SIZE(formats)); *fmt = formats[fmt->index]; return 0; } diff --git a/drivers/media/pci/saa7134/saa7134-video.c b/drivers/media/pci/saa7134/saa7134-video.c index 1a50ec9..d93cf09 100644 --- a/drivers/media/pci/saa7134/saa7134-video.c +++ b/drivers/media/pci/saa7134/saa7134-video.c @@ -30,6 +30,8 @@ #include <media/v4l2-event.h> #include <media/i2c/saa6588.h> +#include <linux/nospec.h> + /* ------------------------------------------------------------------ */ unsigned int video_debug; @@ -1819,6 +1821,8 @@ static int saa7134_enum_fmt_vid_cap(struct file *file, void *priv, if (f->index >= FORMATS) return -EINVAL; + f->index = array_index_nospec(f->index, FORMATS); + strlcpy(f->description, formats[f->index].name, sizeof(f->description)); diff --git a/drivers/media/pci/tw68/tw68-video.c b/drivers/media/pci/tw68/tw68-video.c index 8c1f4a0..a6cfb4b 100644 --- a/drivers/media/pci/tw68/tw68-video.c #include <media/v4l2-event.h> #include <media/videobuf2-dma-sg.h> +#include <linux/nospec.h> + #include "tw68.h" #include "tw68-reg.h" @@ -789,6 +791,8 @@ static int tw68_enum_fmt_vid_cap(struct file *file, void *priv, if (f->index >= FORMATS) return -EINVAL; + f->index = array_index_nospec(f->index, FORMATS); + strlcpy(f->description, formats[f->index].name, sizeof(f->description)); diff --git a/drivers/media/pci/tw686x/tw686x-video.c b/drivers/media/pci/tw686x/tw686x-video.c index c3fafa9..281d722 100644 --- a/drivers/media/pci/tw686x/tw686x-video.c +++ b/drivers/media/pci/tw686x/tw686x-video.c @@ -25,6 +25,8 @@ #include "tw686x.h" #include "tw686x-regs.h" +#include <linux/nospec.h> + #define TW686X_INPUTS_PER_CH 4 #define TW686X_VIDEO_WIDTH 720 #define TW686X_VIDEO_HEIGHT(id) ((id & V4L2_STD_525_60)