Re: [PATCH v9 00/13] media: staging/imx7: add i.MX7 media driver

into account. I'm pretty sure it complains about both equally. If you make fix one warning it will complain about the other. So you just have to pick which warning to not care about. regards, dan carpenter

Re: [PATCH] media: cedrus: don't initialize pointers with zero

to be a gcc extension. So, I decided to check upstream > > > > No, this is not a gcc extension. It's part of the latest C standard. > > Sure? Where the C standard spec states that? I've been seeking for > such info for a while, as '= {}' is also my personal preference. > > I tried to build the Kernel with clang, just to be sure that this > won't cause issues with the clang support My test says that clang works with {}. I support this in Smatch as well. regards, dan carpenter

Re: 4.18 regression: dvb-usb-v2: General Protection Fault shortly after boot

On Sat, 2018-09-22 at 18:31 -0400, Dan Ziemba wrote: > On Sat, 2018-09-22 at 07:21 -0300, Mauro Carvalho Chehab wrote: > > Em Thu, 20 Sep 2018 00:07:09 -0400 > > Dan Ziemba escreveu: > > > > > I reported this on bugzilla also a few days ago, but I'm not sure &

Re: 4.18 regression: dvb-usb-v2: General Protection Fault shortly after boot

On Sat, 2018-09-22 at 07:21 -0300, Mauro Carvalho Chehab wrote: > Em Thu, 20 Sep 2018 00:07:09 -0400 > Dan Ziemba escreveu: > > > I reported this on bugzilla also a few days ago, but I'm not sure > > if > > that is actually the right place to report, so copying

4.18 regression: dvb-usb-v2: General Protection Fault shortly after boot

=201055 Arch bug: https://bugs.archlinux.org/task/59990 Thanks, Dan Ziemba

[PATCH] [media] VPU: mediatek: don't pass an unused parameter

and silence the static checker warning by not passing the parameter at all. Signed-off-by: Dan Carpenter diff --git a/drivers/media/platform/mtk-vpu/mtk_vpu.c b/drivers/media/platform/mtk-vpu/mtk_vpu.c index f8d35e3ac1dc..616f78b24a79 100644 --- a/drivers/media/platform/mtk-vpu/mtk_vpu.c +++ b/drivers

[PATCH v2] media: sr030pc30: remove NULL in sr030pc30_base_config()

k can be removed. The other thing is that if "ret" is an error code here, then we don't want to do the next call to cam_i2c_write(), so actually let's flip that test around and return the error. This is more of a theoretical issue than something which is likely to affect real life. Signed-off

Re: [PATCH 03/14] staging: media: tegra-vde: Prepare for interlacing support

; > unsigned int i, k; > + size_t size; > + > + size = num_ref_pics * 4 * 8; > + memset(vde->iram, 0, size); I can't get behind the magical size calculation... :( regards, dan carpenter

[bug report] media: i2c: Add driver for Aptina MT9V111

se it to user space. */ 1199 v4l2_ctrl_new_std(>ctrls, _ctrl_ops, regards, dan carpenter

[PATCH] media: dvb_ca_en50221: off by one in dvb_ca_en50221_io_do_ioctl()

The > should be >= so we don't read one element beyond the end of the ca->slot_info[] array. The array is allocated in dvb_ca_en50221_init(). Signed-off-by: Dan Carpenter diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c b/drivers/media/dvb-core/dvb_ca_en50221.c index 131

[PATCH] media: sr030pc30: inconsistent NULL checking in sr030pc30_base_config()

If info->pdata is NULL then we would oops on the next line. And we can flip the "ret" test around and give up if a failure has already occured. Signed-off-by: Dan Carpenter diff --git a/drivers/media/i2c/sr030pc30.c b/drivers/media/i2c/sr030pc30.c index 2a4882cddc51..4ebd00

Re: [GIT PULL FOR v4.18] R-Car VSP1 TLB optimisation

ULL > > due > > to line 26) > > - On line 28, smatch assumes that vsp1->bru is not NULL > > - On line 29, brx is assigned a non-NULL value (as vsp1->bru is not NULL > > due > > to line 28) > > - On line 31, brx is assigned a possibly NULL value (as there's no > > information > > regarding vsp1->brs) > > - On line 34, pipe->brx is not assigned a non-NULL value if brx is NULL > > - On line 36 pipe->brx is dereferenced > > > > The problem comes from the fact that smatch assumes that vsp1->brs isn't > > NULL. > > Adding a "(void)vsp1->brs->entity;" statement on line 25 makes the warning > > disappear. > > I will respond to the other emails in this thread. You guys are basically spot on. All this analysis is 100% correct. Btw, if you want to see Smatch's internal state you can do: #include "/home/whatever/smatch/check_debug.h" else if (!vsp1->bru->entity.pipe) { __smatch_implied(>bru->entity); And it tells you what Smatch thinks it is at that point. The __smatch_about() output can also be useful. regards, dan carpenter

Re: [GIT PULL FOR v4.18] R-Car VSP1 TLB optimisation

entity can be == to pipe->brx and NULL. Adding a "(void)vsp1->bru->entity;" on that path will silence the warning (hopefully). regards, dan carpenter

Re: [GIT PULL FOR v4.18] R-Car VSP1 TLB optimisation

brx = pipe->brx; > else if (!vsp1->bru->entity.pipe) > brx = >bru->entity; > else > brx = >brs->entity; > > if (!brx) > return -EINVAL; > > and that didn't help either... D

Re: [GIT PULL FOR v4.18] R-Car VSP1 TLB optimisation

bru->entity.pipe) brx = >bru->entity; Then Smatch sees that vsp1->bru is dereferenced and marks "brx" as non-NULL. regards, dan carpenter

Re: [GIT PULL FOR v4.18] R-Car VSP1 TLB optimisation

rmat.pad = pipe->brx->source_pad > > > (1) ensures that brx can't be NULL. (2) is thus always true if pipe->brx is > NULL. (3) then assigns a non-NULL value to pipe->brx. Smatch should thus > never > complain about (4), even if it can't backtrack. Oh wow... That's a very basic and ancient bug. I've written a fix and will push it out tomorrow if it passes my testing. regards, dan carpenter

Re: [GIT PULL FOR v4.18] R-Car VSP1 TLB optimisation

On Mon, May 28, 2018 at 01:54:18PM +0300, Laurent Pinchart wrote: > Hi Dan, > > Thank you for your quick reply. > > On Monday, 28 May 2018 13:20:49 EEST Dan Carpenter wrote: > > On Mon, May 28, 2018 at 11:28:41AM +0300, Laurent Pinchart wrote: > > > and I sti

Re: [GIT PULL FOR v4.18] R-Car VSP1 TLB optimisation

struct vsp1_entity *released_brx = NULL; > Just to be clear. After this patch, Smatch does *NOT* think that "pipe->brx" is necessarily non-NULL. What this patch does it that Smatch says "pipe->brx has been modified on every code path since we checked for NULL, so forget about the earlier check". regards, dan carpenter

Re: [PATCH v2] media: davinci vpbe: array underflow in vpbe_enum_outputs()

On Fri, May 25, 2018 at 03:16:21PM +0200, Hans Verkuil wrote: > On 25/05/18 15:12, Dan Carpenter wrote: > > In vpbe_enum_outputs() we check if (temp_index >= cfg->num_outputs) but > > the problem is that temp_index can be negative. I've made > > cgf->num_outp

[PATCH v2] media: davinci vpbe: array underflow in vpbe_enum_outputs()

In vpbe_enum_outputs() we check if (temp_index >= cfg->num_outputs) but the problem is that temp_index can be negative. I've made cgf->num_outputs unsigned to fix this issue. Fixes: 66715cdc3224 ("[media] davinci vpbe: VPBE display driver") Signed-off-by: Dan Carpenter <da

[PATCH] media: v4l2-ioctl: prevent underflow in v4l_enumoutput()

arlier in a central place. There is no one who need p->index to be more than INT_MAX. Fixes: 66715cdc3224 ("[media] davinci vpbe: VPBE display driver") Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c b/drivers/media/v4l2-core/v

[PATCH] media: vivid: potential integer overflow in vidioc_g_edid()

If we pick a very large "edid->blocks" value then the "edid->start_block + edid->blocks" addition could wrap around. Fixes: ef834f7836ec ("[media] vivid: add the video capture and output parts") Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com&g

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

() warn: > > potential spectre issue 'p->ule_next_hdr' > > I failed to see what's wrong here, or if this is exploited. Oh... Huh. This is a bug in smatch. That line looks like: p->ule_sndu_type = ntohs(*(__be16 *)(p->ule_next_hdr + ((p->ule_dbit ? 2 : 3) * ETH_AL

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

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. > > > > > &g

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

_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 <samitolva...@google.com> > Signed-off-by: Hans Verkuil <hansv...@cisco.com> > Signed-off-by: Mauro Carvalho Chehab <mchehab+sams...@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

Re: [PATCH] media: staging: atomisp: fix a potential missing-check bug

bug would exist too... If there were really a race condition like that then we'd want to fix it instead. In other words, this is not a real life bug fix. But it would be fine as a readability or static checker fix so that's fine. regards, dan carpenter

[bug report] media: rcar-vin: add group allocator functions

: 351 mutex_unlock(>group->lock); 352 353 kref_put(>group->refcount, rvin_group_release); There are a bunch of NULL dereferences here... 354 } regards, dan carpenter

[bug report] [media] exynos4-is: Add the FIMC-IS ISP capture DMA driver

[ This code is five years old now. It's so weird to me that the warning is showing up in my new warnings pile. Perhaps this wasn't included in my allmodconfig before? - dan ] Hello Sylwester Nawrocki, The patch 34947b8aebe3: "[media] exynos4-is: Add the FIMC-IS ISP capture DMA d

Re: [PATCH][media-next] media: davinci_vpfe: fix memory leaks of params

rval = module_if->set(ipipe, to); > if (rval) > @@ -1287,7 +1287,9 @@ static int ipipe_s_config(struct v4l2_subdev *sd, > struct vpfe_ipipe_config *cfg) > } > kfree(params); > } > + return rval; Doing a "return 0;" is more readable than "return rval;". regards, dan carpenter

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 10:44 AM, Alex Deucher wrote: > On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig wrote: >> On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: >>> > It has a non-coherent transaction mode (which the chipset can opt to

Re: [PATCH 01/11] media: tm6000: fix potential Spectre variant 1

Hi Mauro, I saw your comment on LWN. You argue on LWN that since the format array is static the CPU won't speculatively read past the L1 cache? I don't know if that's true. It should be easy enough to filter out the reads into static arrays. Peter do you know the answer here? regards, dan

[PATCH] media: vpbe_venc: potential uninitialized variable in ven_sub_dev_init()

Smatch complains that "venc" could be unintialized. There a couple error paths where it looks like maybe that could happen. I don't know if it's really a bug, but it's reasonable to set "venc" to NULL and silence the warning. Signed-off-by: Dan Carpenter <dan.carpen...@

[PATCH] media: davinci_vpfe: fix some potential overflows

We check "lutdpc->dpc_size" in ipipe_validate_lutdpc_params() but if it's invalid then we would have corrupted memory already when we do the memcpy() before calling it. We don't ever check "gamma->tbl_size" but we should since they come from the user. Signed-off-by:

Re: [PATCH 01/15] media: staging/imx: add support to media dev for no IPU systems

o_ipu) {". It's not hard to invert the varible in this case, because the only thing we need to change is imx_media_probe() to set: + imxmd->ipu_present = true; regards, dan carpenter

Re: [PATCH 05/15] media: staging/imx7: add MIPI CSI-2 receiver subdev for i.MX7

((status & MIPI_CSIS_INTSRC_ERRORS) || 1) { ^^^ Was this supposed to make it into the published code? > + for (i = 0; i < MIPI_CSIS_NUM_EVENTS; i++) { > + if (!(status & state->events[i].mask)) > + continue; > + state->events[i].counter++; > + } > + } > + spin_unlock_irqrestore(>slock, flags); > + > + mipi_csis_write(state, MIPI_CSIS_INTSRC, status); > + > + return IRQ_HANDLED; > +} > + regards, dan carpenter

Re: [PATCH 02/15] media: staging/imx7: add imx7 CSI subdev driver

ind upstream endpoint\n"); > + return ret; > + } > + > + mutex_lock(>lock); > + > + csi->upstream_ep = upstream_ep; > + csi->is_csi2 = (upstream_ep.bus_type == V4L2_MBUS_CSI2); > + > + mutex_unlock(>lock); > + > + return ret; return 0; > +} > + [ snip ] > + > +static int imx7_csi_remove(struct platform_device *pdev) > +{ > + return 0; > +} There is no need for this empty (struct platform_driver)->remove() function. See platform_drv_remove() for how it's called. This looks nice, though. regards, dan carpenter

Re: [PATCH 12/18] media: staging: atomisp: avoid a warning if 32 bits build

var16[i] = var8[i]; > > +#ifdef CONFIG_64BIT > /* To avoid owerflows when calling the efivar API */ > if (*out_len > ULONG_MAX) > return -EINVAL; > +#endif I should just silence this particular warning in Smatch. I feel like this is a pretty common thing and the ifdefs aren't very pretty. :( regards, dan carpenter

[PATCH] media: dvb-core: Check for allocation failure in dvb_module_probe()

We should check if kzalloc() fails. Fixes: 8f569c0b4e6b ("media: dvb-core: add helper functions for I2C binding") Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c index cf747d753a79..787

Re: [PATCH v3 1/2] staging: media: davinci_vpfe: add error handling on kmalloc failure

On Tue, Mar 27, 2018 at 02:00:45PM +0900, Ji-Hun Kim wrote: > > Are there any opinions? I'd like to know how this patch is going. > Looks good. Thanks! Greg just hasn't gotten to it yet. regards, dan carpenter

Re: [PATCH 02/30] media: imx-media-utils: fix a warning

array' 14 <= 20 It's always good to simplify the code, but I have a fix for this that I will publish very soon. regards, dan carpenter

Re: Double-free in /drivers/media/usb/zr364xx driver

credit to: Reported-by: "Yavuz, Tuba" <t...@ece.ufl.edu> regards, dan carpenter On Tue, Mar 20, 2018 at 02:30:45PM +, Yavuz, Tuba wrote: > Hello, > > > It looks like there is a double-free on an error path in the zr364xx_probe > function of the zr364xx

Re: [PATCH v3 2/2] staging: media: davinci_vpfe: add kfree() on goto err statement

Looks good. Thanks! regards, dan carpenter

Re: Double-free in /drivers/media/usb/hackrf driver

ackrf_video_release; then the calls to: video_unregister_device(>rx_vdev); and kfree(dev); are a double free. regards, dan carpenter On Tue, Mar 20, 2018 at 01:48:17PM +, Yavuz, Tuba wrote: > Hello, > > > It looks like there is a double-free vulnerability on an

Re: Re: [PATCH] staging: media: davinci_vpfe: add error handling on kmalloc failure

ors all do a return or a goto so "rval" would be zero here. Then the error path would look like: err_free_params: kfree(params); return rval; } regards, dan carpenter

Re: [PATCH] staging: media: davinci_vpfe: add error handling on kmalloc failure

ain goto free_params. 1298 } 1299 kfree(params); 1300 } 1301 } 1302 error: 1303 return rval; Change this to: return 0; free_params: kfree(params); return rval; 1304 } regards, dan carpenter

Re: [PATCH v4 2/2] media: staging/imx: fill vb2_v4l2_buffer sequence entry

MUCH BETTER!111!Exclamationmark! Thanks! :) regards, dan carpenter

Re: [PATCH] media: staging/imx: fill vb2_v4l2_buffer sequence entry

F at stream off */ > bool nfb4eof;/* NFB4EOF encountered during streaming */ > struct completion last_eof_comp; regards, dan carpenter

[PATCH] media: em28xx-cards: fix em28xx_duplicate_dev()

There is a double sizeof() typo here so we don't duplicate the struct properly. Fixes: be7fd3c3a8c5 ("media: em28xx: Hauppauge DualHD second tuner functionality") Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/d

Re: [bug report] media: i2c: Copy tw9910 soc_camera sensor driver

>> 8) & 0x03); > > > > Won't your analyzer in that case point out that > "15 >> 8 is zero" again? I may have been underestimating it though > It will complain, yes, but it's a pretty common false positive and I have it in the back of my head to teach the static checker to look for that situation. Eventually I will get around to it. regards, dan carpenter

Re: [bug report] media: i2c: Copy tw9910 soc_camera sensor driver

On Fri, Mar 02, 2018 at 03:20:16PM +0100, jacopo mondi wrote: > Hi Dan, > > On Thu, Mar 01, 2018 at 12:59:54PM +0300, Dan Carpenter wrote: > > [ I know you're just copying files, but you might have a fix for these > > since you're looking at the code. - dan ] > &

[PATCH] media: ov5695: Off by one in ov5695_enum_frame_sizes()

The ">" should be ">=" so that we don't read one element beyond the end of the array. Fixes: 8a77009be4be ("media: ov5695: add support for OV5695 sensor") Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> diff --git a/drivers/media/i2c/o

[bug report] media: i2c: Copy tw9910 soc_camera sensor driver

[ I know you're just copying files, but you might have a fix for these since you're looking at the code. - dan ] Hello Jacopo Mondi, The patch e0d76c3842ee: "media: i2c: Copy tw9910 soc_camera sensor driver" from Feb 21, 2018, leads to the following static checker warning: dri

[bug report] V4L/DVB (3420): Added iocls to configure VBI on tvp5150

[ This is obviously ancient code. It's probably fine. I've just been going through all array overflow warnings recently. - dan ] Hello Mauro Carvalho Chehab, The patch 12db56071b47: "V4L/DVB (3420): Added iocls to configure VBI on tvp5150" from Jan 23, 2006, leads to the follow

Re: [PATCH] Staging: bcm2048: Fix function argument alignment in radio-bcm2048.c.

roducing shorter aliases is the right thing. But here it just makes it look like a variable when it's a constant. It's makes the code slightly less readable. Just ignore the warning. regards, dan carpenter

Re: [PATCH v2 5/5] drm: adv7511: Add support for i2c_new_secondary_device

2c_client *i2c, const > struct i2c_device_id *id) > adv7511_audio_init(dev, adv7511); > return 0; > > +err_unregister_packet: > + i2c_unregister_device(adv7511->i2c_packet); > err_unregister_cec: > i2c_unregister_device(adv7511->i2c_cec); > if (adv7511->cec_clk) regards, dan carpenter

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

that Geert found where the right side wasn't a number literal. drivers/net/can/m_can/m_can.c:#define RXFC_FWM_MASK (0x7f < RXFC_FWM_SHIFT) drivers/usb/gadget/udc/goku_udc.h:#define INT_EPnNAK(n) (0x00100 < (n)) /* 0 < n < 4 */ regards, dan carpenter

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

On Tue, Feb 06, 2018 at 02:15:51PM +0100, Julia Lawall wrote: > > > On Tue, 6 Feb 2018, Dan Carpenter wrote: > > > On Mon, Feb 05, 2018 at 09:09:57PM +0100, Wolfram Sang wrote: > > > In one Renesas driver, I found a typo which turned an intended bit shift > >

Re: [PATCH 0/4] tree-wide: fix comparison to bitshift when dealing with a mask

ch series is the outcome. > > Buildbot and checkpatch are happy. Only compile-tested. To be applied > individually per sub-system, I think. I'd think only the net: amd: patch needs > to be conisdered for stable, but I leave this to people who actually know this > driver. > > CCin

[PATCH] [media] sr030pc30: prevent array underflow in try_fmt()

Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> diff --git a/drivers/media/i2c/sr030pc30.c b/drivers/media/i2c/sr030pc30.c index 0bf031b7e4fa..2a4882cddc51 100644 --- a/drivers/media/i2c/sr030pc30.c +++ b/drivers/media/i2c/sr030pc30.c @@ -511,13 +511,16 @@ static int sr030pc30_g

Re: [bug report] [media] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

videobuf2-v4l2.c is called by > vb2_core_dqbuf(). > And that __fill_v4l2_buffer() overwrited the index field: b->index = > vb->index; > > So after the vb2_dqbuf call the buf->index field is correct and bounded. > Ah.. I get it. Thanks. regards, dan carpenter

Re: [bug report] [media] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

On Thu, Jan 25, 2018 at 10:58:45AM +0100, Andrzej Hajda wrote: > On 23.01.2018 09:32, Dan Carpenter wrote: > > Hello Andrzej Hajda, > > > > The patch 4d0b0ed63660: "[media] s5p-mfc: use MFC_BUF_FLAG_EOS to > > identify last buffers in decoder capture qu

Re: [PATCH] staging: media: remove unused VIDEO_ATOMISP_OV8858 kconfig

support") > > Lets remove this kconfig option. > > First of all, I hardly understand how that change is related. It's pretty obvious if you look at the commit. -obj-$(CONFIG_VIDEO_ATOMISP_OV8858) += atomisp-ov8858.o It sounds like you deleted that line by mistake and re-add

Re: [PATCH] [media] s3c-camif: array underflow in __camif_subdev_try_format()

On Mon, Jan 22, 2018 at 09:50:04PM +0100, Sylwester Nawrocki wrote: > On 01/22/2018 11:37 AM, Dan Carpenter wrote: > > --- a/drivers/media/platform/s3c-camif/camif-capture.c > > +++ b/drivers/media/platform/s3c-camif/camif-capture.c > > @@ -1261,11 +1261,11 @@ static void __ca

[bug report] V4L/DVB(7872): mxl5005s: checkpatch.pl compliance

>Mode ? 1 : 1); ^^^ 1818 status += MXL_ControlWrite(fe, EN_CHP_LIN_B, state->Mode ? 0 : 0); ^^^ What do these mean? What are they supposed to do? 1819 regards, dan carpenter

[bug report] [media] s5p-mfc: use MFC_BUF_FLAG_EOS to identify last buffers in decoder capture queue

I couldn't find the check. 659 v4l2_event_queue_fh(>fh, ); 660 return 0; 661 default: 662 return -EINVAL; 663 } 664 } regards, dan carpenter

[PATCH] [media] s3c-camif: array underflow in __camif_subdev_try_format()

e we found the right format and I've removed the "mf->code = camif_mbus_formats[i];" because that is a no-op anyway. Fixes: babde1c243b2 ("[media] V4L: Add driver for S3C24XX/S3C64XX SoC series camera interface") Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com>

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 18, 2018 at 5:18 AM, Will Deacon <will.dea...@arm.com> wrote: > Hi Dan, Linus, > > On Thu, Jan 11, 2018 at 05:41:08PM -0800, Dan Williams wrote: >> On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds >> <torva...@linux-foundation.org> wrote: >>

[PATCH] media: staging/imx: Checking the right variable in vdic_get_ipu_resources()

We recently changed this error handling around but missed this error pointer check. We're testing "priv->vdi_in_ch_n" instead of "ch" so the error handling can't be triggered. Fixes: 0b2e9e7947e7 ("media: staging/imx: remove confusing IS_ERR_OR_NULL usage&qu

Re: [PATCH v2 00/19] prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 5:19 PM, Linus Torvalds <torva...@linux-foundation.org> wrote: > On Thu, Jan 11, 2018 at 4:46 PM, Dan Williams <dan.j.willi...@intel.com> > wrote: >> >> This series incorporates Mark Rutland's latest ARM changes and adds >

[PATCH v2 00/19] prevent bounds-check bypass via speculative execution

k/2018/01/reading-privileged-memory-with-side.html [3]: https://spectreattack.com/spectre.pdf [4]: https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf.git/commit/?id=b2157399cc98 --- Dan Williams (16): x86: implement ifence() x86: implement ifence_array_ptr() and a

[PATCH v2 14/19] [media] uvcvideo: prevent bounds-check bypass via speculative execution

dia@vger.kernel.org Reviewed-by: Laurent Pinchart <laurent.pinch...@ideasonboard.com> Signed-off-by: Elena Reshetova <elena.reshet...@intel.com> Signed-off-by: Dan Williams <dan.j.willi...@intel.com> --- drivers/media/usb/uvc/uvc_v4l2.c |9 +++-- 1 file changed, 7 inse

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Thu, Jan 11, 2018 at 1:54 AM, Jiri Kosina <ji...@kernel.org> wrote: > On Tue, 9 Jan 2018, Josh Poimboeuf wrote: > >> On Tue, Jan 09, 2018 at 11:44:05AM -0800, Dan Williams wrote: >> > On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina <ji...@kernel.org> wrote: >&g

[PATCH] media: lirc: Fix uninitialized variable in ir_lirc_transmit_ir()

The "txbuf" is uninitialized when we call ir_raw_encode_scancode() so this failure path would lead to a crash. Fixes: a74b2bff5945 ("media: lirc: do not pass ERR_PTR to kfree") Signed-off-by: Dan Carpenter <dan.carpen...@oracle.com> diff --git a/drivers/media/rc/lir

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Tue, Jan 9, 2018 at 11:34 AM, Jiri Kosina <ji...@kernel.org> wrote: > On Fri, 5 Jan 2018, Dan Williams wrote: > > [ ... snip ... ] >> Andi Kleen (1): >> x86, barrier: stop speculation for failed access_ok >> >> Dan Williams (13): >> x8

Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

On Mon, Jan 8, 2018 at 3:23 AM, Laurent Pinchart <laurent.pinch...@ideasonboard.com> wrote: > Hi Dan, > > Thank you for the patch. > > On Saturday, 6 January 2018 03:10:32 EET Dan Williams wrote: >> Static analysis reports that 'index' may be a user controlled valu

Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

On Sun, Jan 7, 2018 at 1:09 AM, Greg KH wrote: [..] > Sorry for the confusion, no, I don't mean the "taint tracking", I mean > the generic pattern of "speculative out of bounds access" that we are > fixing here. > > Yes, as you mentioned before, there are tons of

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Sat, Jan 6, 2018 at 11:37 AM, Dan Williams <dan.j.willi...@intel.com> wrote: > On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams <dan.j.willi...@intel.com> wrote: >> Quoting Mark's original RFC: >> >> "Recently, Google Project Zero discovered several cl

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Fri, Jan 5, 2018 at 5:09 PM, Dan Williams <dan.j.willi...@intel.com> wrote: > Quoting Mark's original RFC: > > "Recently, Google Project Zero discovered several classes of attack > against speculative execution. One of these, known as variant-1, allows > explicit bo

Re: [PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

On Sat, Jan 6, 2018 at 1:40 AM, Greg KH <gre...@linuxfoundation.org> wrote: > On Sat, Jan 06, 2018 at 10:09:07AM +0100, Greg KH wrote: >> On Fri, Jan 05, 2018 at 05:10:32PM -0800, Dan Williams wrote: >> > Static analysis reports that 'index' may be a user controlled

Re: [PATCH 00/18] prevent bounds-check bypass via speculative execution

On Fri, Jan 5, 2018 at 6:22 PM, Eric W. Biederman <ebied...@xmission.com> wrote: > Dan Williams <dan.j.willi...@intel.com> writes: > >> Quoting Mark's original RFC: >> >> "Recently, Google Project Zero discovered several classes of attack >> aga

[PATCH 07/18] [media] uvcvideo: prevent bounds-check bypass via speculative execution

sed on an invalid value of 'pin'. Based on an original patch by Elena Reshetova. Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com> Cc: Mauro Carvalho Chehab <mche...@kernel.org> Cc: linux-media@vger.kernel.org Signed-off-by: Elena Reshetova <elena.reshet...@intel.com> Signed

[PATCH 00/18] prevent bounds-check bypass via speculative execution

for failed access_ok Dan Williams (13): x86: implement nospec_barrier() [media] uvcvideo: prevent bounds-check bypass via speculative execution carl9170: prevent bounds-check bypass via speculative execution p54: prevent bounds-check bypass via speculative execution qla

Re: [PATCH v1 05/10] staging: atomisp: Remove non-ACPI leftovers

On Wed, Dec 20, 2017 at 11:30:01AM +0100, Julia Lawall wrote: > > > On Wed, 20 Dec 2017, Dan Carpenter wrote: > > > On Tue, Dec 19, 2017 at 10:59:52PM +0200, Andy Shevchenko wrote: > > > @@ -914,9 +904,7 @@ static int lm3554_probe(struct i2c_client *client) > >

[PATCH v4] media: ABS macro parameter parenthesization

From: Dan Gopstein <dgopst...@nyu.edu> Replace usages of the locally defined ABS() macro with calls to the canonical abs() from kernel.h and remove the old definitions of ABS() This change was originally motivated by two local definitions of the ABS (absolute value) macro tha

[PATCH v3] media: ABS macro parameter parenthesization

From: Dan Gopstein <dgopst...@nyu.edu> Replace usages of the locally defined ABS() macro with calls to the canonical abs() from kernel.h and remove the old definitions of ABS() Signed-off-by: Dan Gopstein <dgopst...@nyu.edu> --- v2->v3: * replace local ABS() with kernel'

Re: [PATCH v1 05/10] staging: atomisp: Remove non-ACPI leftovers

Actually every place where we directly return a function call is wrong and needs error handling added. I've been meaning to write a Smatch check for this because it's a common anti-pattern we don't check the last function call for errors. Someone could probably do the same in Coccinelle if they want. regards, dan carpenter

Re: [PATCH v1 05/10] staging: atomisp: Remove non-ACPI leftovers

goto err_free_something; return 0; > > - return ret; > out_free: > v4l2_device_unregister_subdev(>sd); > kfree(dev); regards, dan carpenter

Re: [bug report] drx: add initial drx-d driver

I'm really sorry. This warning showed up in my new warnings pile and I didn't look at the date. :/ Sorry for the noise. regards, dan carpenter

[bug report] drx: add initial drx-d driver

Anyway, it's more clear to just "return 0;" 1306 } 1307 return -1; ^^ -1 is not a proper error code. 1308 } regards, dan carpenter

[bug report] media: lirc: improve locking

Are you sure you want to hold the lock this whole time? 368 } 369 } 370 371 out: 372 mutex_unlock(>lock); 373 kfree(txbuf); ^ Can't pass an error pointer to kfree(). 374 kfree(raw); regards, dan carpenter

[PATCH] media: imx274: Silence uninitialized variable warning

Smatch complains that "err" can be uninitialized if we have a zero size write. The flow analysis is a little complicated so I'm not sure if that's possible or not, but it's harmless to set this to zero and it makes the code easier to read. Signed-off-by: Dan Carpenter <dan.carpen.

Re: [PATCH v2 1/3] media: atomisp: convert default struct values to use compound-literals with designated initializers.

On Sat, Dec 02, 2017 at 08:41:48PM +, Jeremy Sowden wrote: > On 2017-12-02, at 10:35:06 +, Jeremy Sowden wrote: > > On 2017-12-02, at 13:20:09 +0300, Dan Carpenter wrote: > > > On Fri, Dec 01, 2017 at 05:19:37PM +, Jeremy Sowden wrote: > > > &

Re: [PATCH v2 1/3] media: atomisp: convert default struct values to use compound-literals with designated initializers.

= DEFAULT_SHADING_INFO, \ > + .grid_info = DEFAULT_GRID_INFO, \ > + .num_invalid_frames = 0 \ > + } \ > +) We need to get better compile test coverage on this... :/ There are some others as well. regards, dan carpenter

Re: [PATCH 1/3] media: atomisp: convert default struct values to use compound-literals with designated initializers.

x_end = 0, \ > + y_end = 0 \ I'm pretty sure those lines should start with a period. - width = 0, \ + .width = 0, \ regards, dan

[bug report] media: dvb_frontend: cleanup ioctl handling logic

return -ENOTSUPP; 2467 } /* switch */ 2468 2469 return err; ^^ 2470 } regards, dan carpenter

[PATCH v3 0/4] introduce get_user_pages_longterm()

face does not suffer the same constraints since it does not support file space management operations like hole-punch. --- Dan Williams (4): mm: introduce get_user_pages_longterm mm: fail get_vaddr_frames() for filesystem-dax mappings [media] v4l2: disable filesystem-dax mapping s

[PATCH v3 2/4] mm: fail get_vaddr_frames() for filesystem-dax mappings

orton <a...@linux-foundation.org> Cc: <sta...@vger.kernel.org> Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") Reviewed-by: Jan Kara <j...@suse.cz> Signed-off-by: Dan Williams <dan.j.willi...@intel.com> --- mm/frame_vector.c | 12 +++

[PATCH v3 3/4] [media] v4l2: disable filesystem-dax mapping support

. Reported-by: Jan Kara <j...@suse.cz> Cc: Mauro Carvalho Chehab <mche...@kernel.org> Cc: linux-media@vger.kernel.org Cc: <sta...@vger.kernel.org> Fixes: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") Reviewed-by: Jan Kara <j...@suse.cz> Signed-off-by: Dan

Re: [PATCH v2 1/3] media: staging: atomisp: fix for sparse "using plain integer as NULL pointer" warnings.

On Tue, Nov 28, 2017 at 11:33:37PM +, Jeremy Sowden wrote: > On 2017-11-28, at 17:15:24 +0300, Dan Carpenter wrote: > > On Mon, Nov 27, 2017 at 12:44:48PM +, Jeremy Sowden wrote: > > > The "address" member of struct ia_css_host_data is a > > > point

Re: [PATCH v2 1/3] media: staging: atomisp: fix for sparse "using plain integer as NULL pointer" warnings.

carcass it's still stinking up the living room. We should leave the warning there until it irritates someone enough to fix it properly. regards, dan carpenter

  1   2   3   4   5   6   7   8   >