New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 718792 link

Starred by 1 user

Issue metadata

Status: WontFix
Owner:
Closed: May 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 2
Type: Bug-Security



Sign in to add a comment

CrOS: Vulnerability reported in sys-kernel/chromeos-kernel-3_8

Project Member Reported by vomit.go...@appspot.gserviceaccount.com, May 5 2017

Issue description

Automated analysis has detected that the following third party packages have had vulnerabilities publicly reported. 

NOTE: There may be several bugs listed below - in almost all cases, all bugs can be quickly addressed by upgrading to the latest version of the package.

Package Name: sys-kernel/chromeos-kernel-3_8
Package Version: [cpe:/o:linux:linux_kernel:3.8.11]

Advisory: CVE-2010-5321
  Details: https://vomit.googleplex.com/advisory?id=CVE/CVE-2010-5321
  CVSS severity score: 4.9/10.0
  Confidence: high
  Description:

Memory leak in drivers/media/video/videobuf-core.c in the videobuf subsystem in the Linux kernel 2.6.x through 4.x allows local users to cause a denial of service (memory consumption) by leveraging /dev/video access for a series of mmap calls that require new allocations, a different vulnerability than CVE-2007-6761.  NOTE: as of 2016-06-18, this affects only 11 drivers that have not been updated to use videobuf2 instead of videobuf.


 
Components: OS>Kernel
Labels: Security_Impact-Stable Security_Severity-Low
Owner: groeck@chromium.org
Status: Assigned (was: Untriaged)
groeck, could you please take a look? Thanks!

Out of caution I'm going to give this Severity-Low. The description which says this is a DoS, which may been we don't consider this a security bug at all.
Status: WontFix (was: Assigned)
videobuf-core.c is enabled with configuration symbol CONFIG_VIDEOBUF_GEN, which is not enabled in any of our configurations (checked all releases from 3.8).
All our drivers use videobuf2 which is not affected.

Comment 3 by snanda@google.com, May 5 2017

I haven't looked at that config option closely to know whether we will want to enable it sometime in the future or not. Do we want to pick up the fix speculatively?  We can also ask posciak for his thoughts too since he is a video expert.
In general, I agree that it makes sense to apply security patches from upstream even if we don't currently use that code.

However, the situation is a bit different here. The fix never made it upstream. There is one floating around, but I have not been able to locate it. None of the major distributions fixed this problem. The vulnerability only applies to affected drivers. A user must be either "root" or in group "video" to be able to exploit it.

On top of that, it appears unlikely that we would today introduce a video driver using an API which was replaced some 6+ years ago and is, for all practical purposes, unsupported in the upstream kernel, instead of using its replacement.

Given all that, it does not make sense to me to apply the fix - if we can locate it - and maintain it in our code base "just in case". We would not even be able to test that code.

Comment 5 by snanda@google.com, May 5 2017

c#4: sounds good.
 Issue 719059  has been merged into this issue.
 Issue 719060  has been merged into this issue.
Cc: djm@google.com
Project Member

Comment 9 by sheriffbot@chromium.org, Aug 12 2017

Labels: -Restrict-View-SecurityTeam allpublic
This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Sign in to add a comment