From ${URL} : From the upstream commit [1]: """ The bug fix in f66e6ce4446: "libext2fs: avoid buffer overflow if s_first_meta_bg is too big" had a typo in the fix for ext2fs_closefs(). In practice most of the security exposure was from the openfs path, since this meant if there was a carefully crafted file system, buffer overrun would be triggered when the file system was opened. However, if corrupted file system didn't trip over some corruption check, and then the file system was modified via tune2fs or debugfs, such that the superblock was marked dirty and then written out via the closefs() path, it's possible that the buffer overrun could be triggered when the file system is closed. """ [1]: https://git.kernel.org/cgit/fs/ext2/e2fsprogs.git/commit/?id=49d0fe2a14f2a23da2fe299643379b8c1d37df73 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
(In reply to Agostino Sarubbo from comment #0) > From ${URL} : > s_first_meta_bg is too big" had a typo in the fix for ext2fs_closefs(). In Well that sucks. We should just backport that patch.
CVE-2015-1572 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2015-1572): Heap-based buffer overflow in closefs.c in the libext2fs library in e2fsprogs before 1.42.12 allows local users to execute arbitrary code by causing a crafted block group descriptor to be marked as dirty. NOTE: this vulnerability exists because of an incomplete fix for CVE-2015-0247.
the CVE seems to be wrong as the fix is in 1.42.13, not 1.42.12 at any rate, 1.42.13 is in the tree now and can be stabilized
Arches, please test and mark stable: =sys-fs/e2fsprogs-1.42.13 Target Keywords : "alpha amd64 arm hppa ia64 ppc ppc64 sparc x86" Thank you!
(In reply to Yury German from comment #4) > Arches, please test and mark stable: > > =sys-fs/e2fsprogs-1.42.13 And =sys-libs/e2fsprogs-libs-1.42.13 I presume.
Both stable on alpha.
amd64 stable
Stable for HPPA PPC64.
x86 stable
I am drafting this now
arm stable
ia64 stable
ppc stable
sparc stable. Maintainer(s), please cleanup. Security, please add it to the existing request, or file a new one.
This issue was resolved and addressed in GLSA 201507-22 at https://security.gentoo.org/glsa/201507-22 by GLSA coordinator Mikle Kolyada (Zlogene).
Reopen for cleanup
Maintainer(s), please drop the vulnerable version(s).
It has been 30 days+ since cleanup requested. Maintainer(s), please drop the vulnerable version(s). If not cleaned up then it will be removed from tree by security.
Maintainer(s), Thank you for your work.
cleanup completed... addressed in GLSA already.