> On the kernel side there was previously a CVE assigned for the ptrace issue - CVE-2015-8709. That restricted ptrace if the real, effective, and saved uids and gids of the process were not mapped into the ptracing process's user ns, but that doesn't forbid ptrace under the circumstances here.
Isn't that subverting the idea behind CVEs? It seems Redhat is already patched against that vulnerability:
Fedora Update System 2016-02-01 01:23:43 EST
kernel-4.3.4-200.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
So basically they would have to reopen the issue and patch the same vuln again, although first patch was complete?
Or should we just accept that and wait for the first system to appear that is patched for CVE-2015-8709-A and not for CVE-2015-8709-B and then split the old entry into two?
> On the kernel side there was previously a CVE assigned for the ptrace issue - CVE-2015-8709. That restricted ptrace if the real, effective, and saved uids and gids of the process were not mapped into the ptracing process's user ns, but that doesn't forbid ptrace under the circumstances here.
Isn't that subverting the idea behind CVEs? It seems Redhat is already patched against that vulnerability:
https:/ /bugzilla. redhat. com/show_ bug.cgi? id=1295287
Fedora Update System 2016-02-01 01:23:43 EST 4.3.4-200. fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
kernel-
So basically they would have to reopen the issue and patch the same vuln again, although first patch was complete?
Or should we just accept that and wait for the first system to appear that is patched for CVE-2015-8709-A and not for CVE-2015-8709-B and then split the old entry into two?