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
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 1402888]
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.
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.
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
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
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;
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
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