Bug 1402885 (CVE-2016-7913) - CVE-2016-7913 kernel: media: use-after-free in [tuner-xc2028] media driver
Summary: CVE-2016-7913 kernel: media: use-after-free in [tuner-xc2028] media driver
Status: CLOSED ERRATA
Alias: CVE-2016-7913
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard: impact=moderate,public=20160128,repor...
Keywords: Security
Depends On: 1402888 1402893 1402894 1402895 1402896 1695829 1695830
Blocks: 1395247
TreeView+ depends on / blocked
 
Reported: 2016-12-08 14:38 UTC by Vladis Dronov
Modified: 2019-06-11 11:13 UTC (History)
31 users (show)

(edit)
The xc2028_set_config function in drivers/media/tuners/tuner-xc2028.c in the Linux kernel before 4.6 allows local users to gain privileges or cause a denial of service (use-after-free) via vectors involving omission of the firmware name from a certain data structure. Due to the nature of the flaw, privilege escalation cannot be fully ruled out, although we believe it is unlikely.
Clone Of:
(edit)
Last Closed: 2019-06-08 03:03:55 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:0676 None None None 2018-04-10 08:04 UTC
Red Hat Product Errata RHSA-2018:1062 None None None 2018-04-10 09:28 UTC
Red Hat Product Errata RHSA-2019:1170 None None None 2019-05-14 19:08 UTC
Red Hat Product Errata RHSA-2019:1190 None None None 2019-05-14 20:26 UTC

Description Vladis Dronov 2016-12-08 14:38:44 UTC
The xc2028_set_config function in drivers/media/tuners/tuner-xc2028.c in the Linux kernel before 4.6 allows local users to gain privileges or cause a denial of service (use-after-free) via vectors involving omission of the firmware name from a certain data structure. Due to the nature of the flaw, privilege escalation cannot be fully ruled out, although we believe it is unlikely.

References:

https://source.android.com/security/bulletin/2016-11-01.html#eop-in-kernel-media-driver

https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-7913

Patch:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8dfbcc4351a0b6d2f2d77f367552f48ffefafe18

Comment 2 Vladis Dronov 2016-12-08 14:43:01 UTC
Created kernel tracking bugs for this issue:

Affects: fedora-all [bug 1402888]

Comment 8 Vladis Dronov 2016-12-08 14:55:57 UTC
Statement:

This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, 6 as the code with the flaw is not present in the products listed.

This issue affects the Linux kernel packages as shipped with Red Hat Enterprise Linux 7 and Red Hat Enterprise MRG-2. Future Linux kernel updates for the respective releases might address this issue.

Comment 9 Vladis Dronov 2017-03-07 14:09:15 UTC
addressing customer's request:

> This seems specific to audio and/or video configuration and playback
> or TV tuner signals. If we have no TV tuner card, are we vulnerable
> to this issue? Could we be vulnerable if we also have no audio card,
> and only the default bios/motherboard speaker? Is there a way to tell
> if we have hardware that would use the vulnerable code?

unfortunately, you have not specified exact version of RHEL you run. you are safe with RHEL-5 or -6 as [tuner-xc2028] module is not built or shipped with these products.

RHEL-7 is potentially vulnerable. due to the nature of the flaw, privilege escalation cannot be fully ruled out, although we believe it is unlikely. we are not aware of any exploit using this flaw. let me now address your questions.

> If we have no TV tuner card, are we vulnerable to this issue?
you are safe if you do not have a tv tuner card which is equipped with Xceive XC3028/XC3018/XC2028 chip, for which [tuner-xc2028] module is used. loading the module manually with 'modprobe' does not result in the problem code (xc2028_set_config() function) being run.

> Is there a way to tell if we have hardware that would use
> the vulnerable code?"
such a hardware should be equipped with Xceive XC3028/XC3018/XC2028 chip. you can check for (possibly incomplete) list of equipment with Xceive XC3028/XC3018/XC2028 chip at https://www.linuxtv.org/wiki/index.php/Xceive_XC3028/XC2028

boot the system and check with 'lsmod' if the module [tuner-xc2028] was loaded automatically. if not, you do not have a hardware which requires this module.

Comment 10 errata-xmlrpc 2018-04-10 08:04:21 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2018:0676 https://access.redhat.com/errata/RHSA-2018:0676

Comment 11 errata-xmlrpc 2018-04-10 09:28:01 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7

Via RHSA-2018:1062 https://access.redhat.com/errata/RHSA-2018:1062

Comment 12 Stephan Zeisberg 2018-07-09 15:41:58 UTC
The applied patch [1] fixes the use-after-free issue, but at the same time introduces a new issue (improper locking). 

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8dfbcc4351a0b6d2f2d77f367552f48ffefafe18

After calling xc2028_set_config() the &priv->lock mutex is locked. Due to the applied patch [1] the mutex will not be unlocked before the return -ENOMEM call.


Patch proposal:
diff --git a/drivers/media/tuners/tuner-xc2028.c b/drivers/media/tuners/tuner-xc2028.c
index e7d06779c88b..e9f745bfe0b4 100644
--- a/drivers/media/tuners/tuner-xc2028.c
+++ b/drivers/media/tuners/tuner-xc2028.c
@@ -1387,8 +1387,10 @@ static int xc2028_set_config(struct dvb_frontend *fe, void *priv_cfg)
        memcpy(&priv->ctrl, p, sizeof(priv->ctrl));
        if (p->fname) {
                priv->ctrl.fname = kstrdup(p->fname, GFP_KERNEL);
-               if (priv->ctrl.fname == NULL)
-                       return -ENOMEM;
+               if (priv->ctrl.fname == NULL) {
+                       rc = -ENOMEM;
+                       goto unlock;
+               }
        }
 
        /*
@@ -1425,6 +1425,7 @@ static int xc2028_set_config(struct dvb_frontend *fe, void *priv_cfg)
                } else
                        priv->state = XC2028_WAITING_FIRMWARE;
        }
+unlock:
        mutex_unlock(&priv->lock);
 
        return rc;

Comment 14 errata-xmlrpc 2019-05-14 19:08:14 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise Linux 7.4 Extended Update Support

Via RHSA-2019:1170 https://access.redhat.com/errata/RHSA-2019:1170

Comment 15 errata-xmlrpc 2019-05-14 20:26:31 UTC
This issue has been addressed in the following products:

  Red Hat Enterprise MRG 2

Via RHSA-2019:1190 https://access.redhat.com/errata/RHSA-2019:1190


Note You need to log in before you can comment on or make changes to this bug.