4 ms·

Red Hat (RHEL 5/6/7) not affected: https://access.redhat.com/security/cve/CVE-2016-10229 https://access.redhat.com/security/cve/CVE-2016-10229 Highest impact i

by cyann 9y ago

Red Hat (RHEL 5/6/7) not affected: https://access.redhat.com/security/cve/CVE-2016-10229 https://access.redhat.com/security/cve/CVE-2016-10229 Highest impact is on Android: https://source.android.com/security/bulletin/2017-04-01 https://source.android.com/security/bulletin/2017-04-01

mnw21cam 9y ago
The RHEL web page is singularly unhelpful. Do they mean that is not affected if you update today and reboot, or that they have never shipped a kernel with the affected functionality enabled? I have a server with just over a year's uptime, so I need to know. The debian web page at least lists the exact kernel version they ship where it is confirmed fixed.
- bipson 9y ago
  Maybe this is more helpful: https://bugzilla.redhat.com/show_bug.cgi?id=1439740 https://bugzilla.redhat.com/show_bug.cgi?id=1439740
  - mnw21cam 9y ago
    Definitely. Thanks.
    - ungamed 9y ago
      Thanks, I wrote that statement. I think it might be worth it if the statement text makes its way across to the CVE pages.
- forbiddenlake 9y ago
  The Statement near the top seems unambiguous: > This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, 6, and 7, Red Hat Enterprise MRG 2, and realtime kernels as the code that introduced the flaw is not present in these products.
  - mnw21cam 9y ago
    That statement has been subsequently added. And yes.
etatoby 9y ago
Would a kernel-level firewall (iptables) help in this case? Or does the vulnerability happen before the packet can be discarded by iptables? If so, what is a good firewall frontend for Android?
- lucb1e 9y ago
  Given that the PEEK flag is needed, I'd say an application needs to try to use the data first (with that flag). A firewall would do the trick to block that I guess.
fuzzy2 9y ago
Hm, I find it very hard to believe how something would not be affected by this. Did they backport the patch earlier than others? Or is there perhaps some dependency on specific kernel configurations?

by cyann 9y ago

mnw21cam 9y ago

The RHEL web page is singularly unhelpful. Do they mean that is not affected if you update today and reboot, or that they have never shipped a kernel with the affected functionality enabled? I have a server with just over a year's uptime, so I need to know. The debian web page at least lists the exact kernel version they ship where it is confirmed fixed.

bipson 9y ago
Maybe this is more helpful: https://bugzilla.redhat.com/show_bug.cgi?id=1439740 https://bugzilla.redhat.com/show_bug.cgi?id=1439740
- mnw21cam 9y ago
  Definitely. Thanks.
  - ungamed 9y ago
    Thanks, I wrote that statement. I think it might be worth it if the statement text makes its way across to the CVE pages.
forbiddenlake 9y ago
The Statement near the top seems unambiguous: > This issue does not affect the Linux kernel packages as shipped with Red Hat Enterprise Linux 5, 6, and 7, Red Hat Enterprise MRG 2, and realtime kernels as the code that introduced the flaw is not present in these products.
- mnw21cam 9y ago
  That statement has been subsequently added. And yes.

etatoby 9y ago

Would a kernel-level firewall (iptables) help in this case? Or does the vulnerability happen before the packet can be discarded by iptables? If so, what is a good firewall frontend for Android?

lucb1e 9y ago
Given that the PEEK flag is needed, I'd say an application needs to try to use the data first (with that flag). A firewall would do the trick to block that I guess.

fuzzy2 9y ago

Hm, I find it very hard to believe how something would not be affected by this. Did they backport the patch earlier than others? Or is there perhaps some dependency on specific kernel configurations?