Control: tags -1 moreinfo On 2021-05-10 21:33:18, Salvatore Bonaccorso wrote: > Hi Release Team, > > On Wed, May 05, 2021 at 12:37:20AM +0200, Hilko Bengen wrote: > > Package: release.debian.org > > Severity: normal > > User: release.debian....@packages.debian.org > > Usertags: unblock > > X-Debbugs-Cc: none, Hilko Bengen <ben...@debian.org> > > > > Dear release team, > > > > I'd like to upload hivex to 1.3.20-1 to which fixes CVE-2021-3504 / > > Debian bug #988024. Please unblock. > > > > The security fix consists of a patch to lib/handle.c and is described in > > upstream git history: > > > > ,---- > > | commit 8f1935733b10d974a1a4176d38dd151ed98cf381 > > | Author: Richard W.M. Jones <rjo...@redhat.com> > > | Date: Thu Apr 15 15:50:13 2021 +0100 > > | > > | lib/handle.c: Bounds check for block exceeding page length > > (CVE-2021-3504) > > | > > | Hives are encoded as fixed-sized pages containing smaller variable- > > | length blocks: > > | > > | +-------------------+-------------------+-------------------+-- > > | | header |[ blk ][blk][ blk ]|[blk][blk][blk] | > > | +-------------------+-------------------+-------------------+-- > > | > > | Blocks should not straddle a page boundary. However because blocks > > | contain a 32 bit length field it is possible to construct an invalid > > | hive where the last block in a page overlaps either the next page or > > | the end of the file: > > | > > | +-------------------+-------------------+ > > | | header |[ blk ][blk][ blk ..... ] > > | +-------------------+-------------------+ > > | > > | Hivex lacked a bounds check and would process the registry. Because > > | the rest of the code assumes this situation can never happen it was > > | possible to have a block containing some field (eg. a registry key > > | name) which would extend beyond the end of the file. Hivex mmaps or > > | mallocs the file, causing hivex to read memory beyond the end of the > > | mapped region, resulting in reading other memory structures or a > > | crash. (Writing beyond the end of the mapped region seems to be > > | impossible because we always allocate a new page before writing.) > > | > > | This commit adds a check which rejects the malformed registry on > > | hivex_open. > > | > > | Credit: Jeremy Galindo, Sr Security Engineer, Datto.com > > | Signed-off-by: Richard W.M. Jones <rjo...@redhat.com> > > | Fixes: CVE-2021-3504 > > | Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1949687 > > `---- > > > > The debdiff (see attachments) is not minimal; apart from the security > > fix there's only the following functional fix (lib/hivex-internal.h)): > > > > ,---- > > | commit 35ebe62bef0c801fab8956fd36a131ad497a5cea > > | Author: Matt Coleman <m...@datto.com> > > | Date: Thu Aug 13 15:48:16 2020 -0400 > > | > > | Increase HIVEX_MAX_VALUES > > | > > | Due to unintended interaction between Windows and VMWare's snapshot > > | functionality, HKLM\SYSTEM\MountedDevices can end up with more than > > | 55,000 values. > > `---- > > > > The rest of the patch is made up of an update to the included gnulib > > sources, localization updates, fuzzing instructions, and regenerated > > Autotools build scripts. > > > > There are no changes to the Debian packageing. > > For buster DSA 4913-1 was released to fix this issue, so ideally this > fix is present as well on bullseye. Does the debdiff look ok to you > for inclusion based on rebasing to 1.3.20-1.
The bug report didn't make it to the list which is a good sign that the debdiff is too big. Please provide a filtered debdiff without the gnulib, auto*, etc. noise. Cheers -- Sebastian Ramacher