Summary: | <www-servers/nginx-unit-1.7.1 - heap memory buffer overflow might have been caused in the router process by a specially crafted request, potentially resulting in a segmentation fault or other unspecified behavior (CVE-2019-7401) | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | gentoo, proxy-maint |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://mailman.nginx.org/pipermail/unit/2019-February/000112.html | ||
See Also: | https://github.com/gentoo/gentoo/pull/11002 | ||
Whiteboard: | B3 [noglsa cve] | ||
Package list: | Runtime testing required: | --- |
Description
Jeroen Roovers (RETIRED)
2019-02-10 13:41:43 UTC
I've opened https://github.com/gentoo/gentoo/pull/11002 to deal with this issue three days before the bug report was filed, but unfortunately nobody has picked up the PR yet. (In reply to Ralph Seichter from comment #1) > three days before the bug report was filed, but unfortunately nobody > has picked up the PR yet. Because no one was aware that there was a security issue to fix? Maybe the PR process can be improved with flags that signal security bugs to people who need to know about it? Or you just file your own security bug reports? Allowing pull request authors to add flags like "security related" is something I'd appreciate. I included the term security in the PR's subject line, but apparently that is not enough to make a pull request stand out, given the volume that needs to be processed. (In reply to Ralph Seichter from comment #3) > Allowing pull request authors to add flags like "security related" is > something I'd appreciate. I included the term security in the PR's subject > line, but apparently that is not enough to make a pull request stand out, > given the volume that needs to be processed. The only acceptable workflow for Gentoo is the bugtracker, so it needs to be within this context. (In reply to Kristian Fiskerstrand from comment #4) > The only acceptable workflow for Gentoo is the bugtracker [...] That's not how I interpret what I read on the Gentoo Developers mailing list over the last months. My understanding is that using GitHub is the predominant way to get changes into the Gentoo tree, not Bugzilla. I don't mean to start a debate here; that's something for the mailing list. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=11fab555d65c1148e80b372503750765f8b04e10 commit 11fab555d65c1148e80b372503750765f8b04e10 Author: Ralph Seichter <gentoo@seichter.de> AuthorDate: 2019-08-04 10:40:45 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2019-08-04 11:08:46 +0000 www-servers/nginx-unit: Remove obsolete ebuilds Package-Manager: Portage-2.3.69, Repoman-2.3.16 Signed-off-by: Ralph Seichter <gentoo@seichter.de> Bug: https://bugs.gentoo.org/677644 Closes: https://github.com/gentoo/gentoo/pull/12616 Signed-off-by: Michał Górny <mgorny@gentoo.org> www-servers/nginx-unit/Manifest | 5 -- www-servers/nginx-unit/nginx-unit-1.3-r1.ebuild | 52 ------------------- www-servers/nginx-unit/nginx-unit-1.3.ebuild | 39 --------------- www-servers/nginx-unit/nginx-unit-1.5.ebuild | 66 ------------------------- www-servers/nginx-unit/nginx-unit-1.6.ebuild | 66 ------------------------- www-servers/nginx-unit/nginx-unit-1.7.1.ebuild | 66 ------------------------- www-servers/nginx-unit/nginx-unit-1.7.ebuild | 66 ------------------------- 7 files changed, 360 deletions(-) I think this cleans up all vulnerable versions. Security, please do your dance. |