Impact H2O is vulnerable to the HTTP/2 Rapid Reset attack. An attacker might be able to consume more than adequate amount of processing power of h2o and the backend servers by mounting the attack. Patches All commits up to cb9f500 are vulnerable. The vulnerability is fixed by #3291. Users are advised to upgrade to commit 28fe151 or above that incorporates this pull request.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=24f20ce718815bfd0a2db32f9fb116ec81a9e58c commit 24f20ce718815bfd0a2db32f9fb116ec81a9e58c Author: Akinori Hattori <hattya@gentoo.org> AuthorDate: 2023-10-22 13:38:38 +0000 Commit: Akinori Hattori <hattya@gentoo.org> CommitDate: 2023-10-22 13:38:38 +0000 www-servers/h2o: fix CVE-2023-44487 Bug: https://bugs.gentoo.org/915567 Signed-off-by: Akinori Hattori <hattya@gentoo.org> www-servers/h2o/files/h2o-2.2-CVE-2023-44487.patch | 225 +++++++++++++++++++++ www-servers/h2o/h2o-2.2.6-r2.ebuild | 107 ++++++++++ 2 files changed, 332 insertions(+)
This bug is interesting in that the upstream has now decided that they're no longer going to tag release ever again. They now consider the git master branch to be the latest stable release at all times. For fixing this in the tree, should we start simply doing semi-arbitrary dates for releases?
(In reply to Anthony Ryan from comment #2) > This bug is interesting in that the upstream has now decided that they're no > longer going to tag release ever again. > > They now consider the git master branch to be the latest stable release at > all times. > > For fixing this in the tree, should we start simply doing semi-arbitrary > dates for releases? That's one way to do it!
