Hello,
Can anyone please confirm this bug and apply the patch? Thanks!
Wenwen
On Thu, Oct 4, 2018 at 11:00 AM Wenwen Wang wrote:
>
> In vpfe_isif_init(), there is a while loop to get the ISIF base address and
> linearization table0 and table1 address. In the loop body, the
atform_get_resource().
Signed-off-by: Wenwen Wang
---
drivers/staging/media/davinci_vpfe/dm365_isif.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/staging/media/davinci_vpfe/dm365_isif.c
b/drivers/staging/media/davinci_vpfe/dm365_isif.c
index 745e33f..b0425a6 1006
On Tue, May 8, 2018 at 7:16 AM, Dan Carpenter wrote:
> On Wed, May 02, 2018 at 05:38:49PM -0500, Wenwen Wang wrote:
>> At the end of atomisp_subdev_set_selection(), the function
>> atomisp_subdev_get_rect() is invoked to get the pointer to v4l2_rect. Since
>> this funct
On Fri, May 4, 2018 at 5:08 AM, Dilger, Andreas
wrote:
> On May 3, 2018, at 22:19, Wenwen Wang wrote:
>>
>> On Tue, May 1, 2018 at 3:46 AM, Dan Carpenter
>> wrote:
>>> On Mon, Apr 30, 2018 at 05:56:10PM -0500, Wenwen Wang wrote:
>>>> However, given th
as null pointer
dereference.
This patch saves the pointer returned by the first invocation and removes
the second invocation. If the returned pointer is not NULL, the memory
content is copied according to the original code.
Signed-off-by: Wenwen Wang
---
drivers/staging/media/atomisp/pci
On Fri, May 4, 2018 at 12:27 AM, Dan Carpenter wrote:
> There is no security problem here. The user is allowed to choose either
> v1 or v3. Using a double read race condition to choose v1 is not
> going to cause problems. It's slightly more complicated than just
> choosing it directly but that
On Tue, May 1, 2018 at 3:46 AM, Dan Carpenter wrote:
> On Mon, Apr 30, 2018 at 05:56:10PM -0500, Wenwen Wang wrote:
>> However, given that the user data resides in the user space, a malicious
>> user-space process can race to change the data between the two copies. By
>> d
as null pointer
dereference.
This patch saves the pointer returned by the first invocation and removes
the second invocation. If the returned pointer is not NULL, the memory
content is copied according to the original code.
Signed-off-by: Wenwen Wang
---
drivers/staging/media/atomisp/pci
cted, i.e., LOV_USER_MAGIC_V3, an error code will be
returned: -EINVAL.
Signed-off-by: Wenwen Wang
---
drivers/staging/lustre/lustre/llite/dir.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index d10
On Mon, Apr 30, 2018 at 5:38 PM, Dilger, Andreas
wrote:
> On Apr 29, 2018, at 07:20, Greg Kroah-Hartman
> wrote:
>>
>> On Sat, Apr 28, 2018 at 04:04:25PM +, Dilger, Andreas wrote:
>>> On Apr 27, 2018, at 17:45, Wenwen Wang wrote:
>>>> [PATCH] stagin
On Sun, Apr 29, 2018 at 8:20 AM, Greg Kroah-Hartman
wrote:
> On Sat, Apr 28, 2018 at 04:04:25PM +, Dilger, Andreas wrote:
>> On Apr 27, 2018, at 17:45, Wenwen Wang wrote:
>> > [PATCH] staging: luster: llite: fix potential missing-check bug when
>> > copying lumv
&
as null pointer
dereference.
This patch saves the pointer returned by the first invocation and removes
the second invocation. If the returned pointer is not NULL, the memory
content is copied according to the original code.
Signed-off-by: Wenwen Wang
---
drivers/staging/media/atomisp/pci
cted, i.e., LOV_USER_MAGIC_V3, an error code will be
returned: -EINVAL.
Signed-off-by: Wenwen Wang
---
drivers/staging/lustre/lustre/llite/dir.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/staging/lustre/lustre/llite/dir.c
b/drivers/staging/lustre/lustre/llite/dir.c
index d10
13 matches
Mail list logo
