Re: [PATCH] readelf: PR28928 - wrong dynamic section entry number
Hey team,
I made some changes for this patch:
(1) update the commit message to make it more clear
(2) tests/alldts.c needs the padding spaces for output comparison
On Tue, Mar 1, 2022 at 8:54 PM Di Chen wrote:
> commit 978663c5323cf402cd35b8614e41f24b587cbdd8 (HEAD -> dichen/DT_NULL,
> origin/dichen/DT_NULL)
> Author: Di Chen
> Date: Tue Mar 1 20:44:38 2022 +0800
>
> readelf: PR28928 - wrong dynamic section entry number
>
> when using `$ eu-readelf -d {file}` to get the number of dynamic
> section entris, It wrongly counts the padding DT_NULLs as dynamic
> section entries. However, DT_NULL Marks end of dynamic section.
> They should not be counted as dynamic section entries.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=28928
>
> Signed-off-by: Di Chen
>
> diff --git a/src/readelf.c b/src/readelf.c
> index 93fb5989..1bec3aa6 100644
> --- a/src/readelf.c
> +++ b/src/readelf.c
> @@ -296,6 +296,7 @@ static void print_shdr (Ebl *ebl, GElf_Ehdr *ehdr);
> static void print_phdr (Ebl *ebl, GElf_Ehdr *ehdr);
> static void print_scngrp (Ebl *ebl);
> static void print_dynamic (Ebl *ebl);
> +static void handle_dynamic (Ebl *ebl, Elf_Scn *scn, GElf_Shdr *shdr);
> static void print_relocs (Ebl *ebl, GElf_Ehdr *ehdr);
> static void handle_relocs_rel (Ebl *ebl, GElf_Ehdr *ehdr, Elf_Scn *scn,
>GElf_Shdr *shdr);
> @@ -1781,16 +1782,54 @@ print_dt_posflag_1 (int class, GElf_Xword d_val)
> [dichen@arpeggio elfutils]$ git format-patch -1 HEAD
> 0001-readelf-PR28928-wrong-dynamic-section-entry-number.patch
> [dichen@arpeggio elfutils]$ vim
> 0001-readelf-PR28928-wrong-dynamic-section-entry-number.patch
> [dichen@arpeggio elfutils]$ cat
> 0001-readelf-PR28928-wrong-dynamic-section-entry-number.patch
> From 978663c5323cf402cd35b8614e41f24b587cbdd8 Mon Sep 17 00:00:00 2001
> From: Di Chen
> Date: Tue, 1 Mar 2022 20:44:38 +0800
> Subject: [PATCH] readelf: PR28928 - wrong dynamic section entry number
>
> when using `$ eu-readelf -d {file}` to get the number of dynamic
> section entris, It wrongly counts the padding DT_NULLs as dynamic
> section entries. However, DT_NULL Marks end of dynamic section.
> They should not be counted as dynamic section entries.
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=28928
>
> Signed-off-by: Di Chen
> ---
> src/readelf.c | 49 --
> tests/alldts.c | 5 +++--
> tests/run-alldts.sh| 2 +-
> tests/run-readelf-d.sh | 7 +-
> 4 files changed, 48 insertions(+), 15 deletions(-)
>
> diff --git a/src/readelf.c b/src/readelf.c
> index 93fb5989..1bec3aa6 100644
> --- a/src/readelf.c
> +++ b/src/readelf.c
> @@ -296,6 +296,7 @@ static void print_shdr (Ebl *ebl, GElf_Ehdr *ehdr);
> static void print_phdr (Ebl *ebl, GElf_Ehdr *ehdr);
> static void print_scngrp (Ebl *ebl);
> static void print_dynamic (Ebl *ebl);
> +static void handle_dynamic (Ebl *ebl, Elf_Scn *scn, GElf_Shdr *shdr);
> static void print_relocs (Ebl *ebl, GElf_Ehdr *ehdr);
> static void handle_relocs_rel (Ebl *ebl, GElf_Ehdr *ehdr, Elf_Scn *scn,
> GElf_Shdr *shdr);
> @@ -1781,16 +1782,54 @@ print_dt_posflag_1 (int class, GElf_Xword d_val)
> }
>
>
> +static GElf_Phdr *
> +get_dyn_phdr (Elf *elf)
> +{
> + GElf_Phdr *phdr = NULL;
> + for (size_t i = 0; i < phnum; ++i) {
> +GElf_Phdr phdr_mem;
> +phdr = gelf_getphdr(elf, i, &phdr_mem);
> +if (phdr->p_type == PT_DYNAMIC) {
> + break;
> +}
> + }
> + return phdr;
> +}
> +
> +
> +static size_t
> +get_dyn_scnents (Elf *elf, GElf_Phdr * dyn_phdr)
> +{
> + Elf_Data *data = elf_getdata_rawchunk(
> + elf, dyn_phdr->p_offset, dyn_phdr->p_filesz, ELF_T_DYN);
> + GElf_Dyn *dyn;
> + size_t dyn_idx = 0;
> + do
> + {
> +GElf_Dyn dyn_mem;
> +dyn = gelf_getdyn(data, dyn_idx, &dyn_mem);
> +++dyn_idx;
> + } while (dyn->d_tag != DT_NULL);
> +
> + return dyn_idx;
> +}
> +
> +
> static void
> handle_dynamic (Ebl *ebl, Elf_Scn *scn, GElf_Shdr *shdr)
> {
>int class = gelf_getclass (ebl->elf);
> + GElf_Phdr *dyn_phdr;
>GElf_Shdr glink_mem;
>GElf_Shdr *glink;
>Elf_Data *data;
>size_t cnt;
>size_t shstrndx;
> - size_t sh_entsize;
> + size_t dyn_scnents;
> +
> + /* Calculate the dynamic section entry number */
> + dyn_phdr = get_dyn_phdr (ebl->elf);
> + dyn_scnents = get_dyn_scnents (ebl->elf, dyn_phdr);
>
>/* Get the data of the section. */
>data = elf_getdata (scn, NULL);
> @@ -1802,8 +1841,6 @@ handle_dynamic (Ebl *ebl, Elf_Scn *scn, GElf_Shdr
> *shdr)
> error (EXIT_FAILURE, 0,
> _("cannot get section header string table index"));
>
> - sh_entsize = gelf_fsize (ebl->elf, ELF_T_DYN, 1, EV_CURRENT);
> -
>glink = gelf_getshdr (elf_getscn (ebl->elf, shdr->sh_link), &glink_mem);
>if (glink == NULL)
> error (EXIT_FAILURE, 0, _("invalid sh_link value in section %zu"),
> @@ -1813,15 +1850,15 @@ handle_dynamic (Ebl *ebl, Elf_Scn *scn, GElf_Shdr
> *shdr)
> \
Issue 45628 in oss-fuzz: elfutils:fuzz-libdwfl: Heap-buffer-overflow in strtol
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #5 on issue 45628 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Heap-buffer-overflow in strtol https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45628#c5 ClusterFuzz testcase 4673586076450816 is verified as fixed in https://oss-fuzz.com/revisions?job=honggfuzz_asan_elfutils&range=202203210605:202203211200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45682 in oss-fuzz: elfutils:fuzz-libelf: Misaligned-address in elf_cvt_Verneed
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 45682 by ClusterFuzz-External: elfutils:fuzz-libelf: Misaligned-address in elf_cvt_Verneed https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45682#c3 ClusterFuzz testcase 4968585519300608 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_elfutils&range=202203210605:202203211200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45634 in oss-fuzz: elfutils:fuzz-libdwfl: Misaligned-address in file_read_elf
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 45634 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Misaligned-address in file_read_elf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45634#c3 ClusterFuzz testcase 5069818166902784 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_elfutils&range=202203210605:202203211200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45705 in oss-fuzz: elfutils:fuzz-libdwfl: Indirect-leak in __libelf_next_arhdr_wrlock
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #6 on issue 45705 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Indirect-leak in __libelf_next_arhdr_wrlock https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45705#c6 ClusterFuzz testcase 5085329692950528 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_i386_elfutils&range=202203210605:202203211200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45635 in oss-fuzz: elfutils:fuzz-libdwfl: Timeout in fuzz-libdwfl
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 45635 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Timeout in fuzz-libdwfl https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45635#c3 ClusterFuzz testcase 5237809772888064 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_elfutils&range=202203210605:202203211200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45629 in oss-fuzz: elfutils:fuzz-libdwfl: Indirect-leak in __libelf_read_mmaped_file
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #4 on issue 45629 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Indirect-leak in __libelf_read_mmaped_file https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45629#c4 ClusterFuzz testcase 5280476447768576 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_elfutils&range=202203210605:202203211200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45646 in oss-fuzz: elfutils:fuzz-libdwfl: Misaligned-address in __libdw_image_header
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 45646 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Misaligned-address in __libdw_image_header https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45646#c3 ClusterFuzz testcase 5699171619831808 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_elfutils&range=202203210605:202203211200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45636 in oss-fuzz: elfutils:fuzz-libdwfl: Crash in read_long_names
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #4 on issue 45636 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Crash in read_long_names https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45636#c4 ClusterFuzz testcase 5787862593830912 is verified as fixed in https://oss-fuzz.com/revisions?job=afl_asan_elfutils&range=202203210605:202203211200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45637 in oss-fuzz: elfutils:fuzz-libelf: Timeout in fuzz-libelf
Updates: Labels: ClusterFuzz-Verified Status: Verified Comment #3 on issue 45637 by ClusterFuzz-External: elfutils:fuzz-libelf: Timeout in fuzz-libelf https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45637#c3 ClusterFuzz testcase 6393240885002240 is verified as fixed in https://oss-fuzz.com/revisions?job=libfuzzer_asan_elfutils&range=202203210605:202203211200 If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Re: Some fuzzer workarounds
Hi Mark, >> So I took the fuzz-libelf.c and fuzz-libdwfl.c files from the oss-fuzz >> repo, tweaked them so they have a normal main that takes one file >> argument to try to replicate the reports. That found some "real" >> issues I submitted patches for. Then I ran afl-fuzz on them locally >> during the weekend and found another issue for which I also submitted >> a patch. > > FWIW to test the "fuzz" branch I integrated the new fuzz targets into the > elfutils build system > by analogy with > https://sourceware.org/pipermail/elfutils-devel/2021q4/004615.html and > there they are linked with the main function automatically and it's also > possible to pass --enable-afl > to ./configure to automatically run it with AFL. I sent it to the mailing list: https://sourceware.org/pipermail/elfutils-devel/2022q1/004767.html > >> There are several duplicates though and all the MSAN reported >> issues seem bogus. > > > I'm not sure all of them are bogus but I would ignore them for now. Once the > new fuzz targets > are linked with zlib built with MSan bogus reports will be closed and I'll > take a look at what's left > there. I can also prevent OSS-Fuzz from reporting new bugs found by MSan by setting the experimental flag From https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers > If you want to test a particular sanitizer to see what crashes it generates > without filing them in the issue tracker, you can set an experimental flag It should help to figure out whether it makes sense to keep it without spamming the mailing list in the process. What do you think? Thanks, Evgeny Vereshchagin
Issue 45952 in oss-fuzz: elfutils:fuzz-libdwfl: Misaligned-address in elf_cvt_gnuhash
Status: New Owner: CC: elfut...@sourceware.org, da...@adalogics.com, evv...@gmail.com, izz...@google.com Labels: ClusterFuzz Reproducible Stability-UndefinedBehaviorSanitizer Engine-libfuzzer OS-Linux Proj-elfutils Reported-2022-03-22 Type: Bug New issue 45952 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Misaligned-address in elf_cvt_gnuhash https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45952 Detailed Report: https://oss-fuzz.com/testcase?key=6331966935400448 Project: elfutils Fuzzing Engine: libFuzzer Fuzz Target: fuzz-libdwfl Job Type: libfuzzer_ubsan_elfutils Platform Id: linux Crash Type: Misaligned-address Crash Address: Crash State: elf_cvt_gnuhash __libelf_set_data_list_rdlock __elf_getdata_rdlock Sanitizer: undefined (UBSAN) Regressed: https://oss-fuzz.com/revisions?job=libfuzzer_ubsan_elfutils&range=202203161800:20220317 Reproducer Testcase: https://oss-fuzz.com/download?testcase_id=6331966935400448 Issue filed automatically. See https://google.github.io/oss-fuzz/advanced-topics/reproducing for instructions to reproduce this bug locally. When you fix this bug, please * mention the fix revision(s). * state whether the bug was a short-lived regression or an old bug in any stable releases. * add any other useful information. This information can help downstream consumers. If you need to contact the OSS-Fuzz team with a question, concern, or any other feedback, please file an issue at https://github.com/google/oss-fuzz/issues. Comments on individual Monorail issues are not monitored. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45706 in oss-fuzz: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in process_file
Comment #1 on issue 45706 by evv...@gmail.com: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in process_file https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45706#c1 It's a false positive. https://github.com/google/oss-fuzz/pull/7422 should fix it. -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 45631 in oss-fuzz: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in __libdw_gunzip
Updates: Labels: Fuzz-Blocker Comment #3 on issue 45631 by ClusterFuzz-External: elfutils:fuzz-libdwfl: Use-of-uninitialized-value in __libdw_gunzip https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=45631#c3 This crash occurs very frequently on linux platform and is likely preventing the fuzzer fuzz-libdwfl from making much progress. Fixing this will allow more bugs to be found. If this is incorrect, please file a bug on https://github.com/google/oss-fuzz/issues/new -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[PATCH] libelf: Correct alignment of ELF_T_GNUHASH data for ELFCLASS64
ELF_T_GNUHASH data is just 32bit words for ELFCLASS32. But for
ELFCLASS64 it is a mix of 32bit and 64bit words. In the
elf_cvt_gnuhash function we rely on the alignment of the whole to be
64bit word aligned, even though the first 4 words are
32bits. Otherwise we might try to convert an unaligned 64bit word.
Signed-off-by: Mark Wielaard
---
libelf/ChangeLog | 5 +
libelf/elf_getdata.c | 16 ++--
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/libelf/ChangeLog b/libelf/ChangeLog
index ea204e2b..5ea1e41e 100644
--- a/libelf/ChangeLog
+++ b/libelf/ChangeLog
@@ -1,3 +1,8 @@
+2022-03-22 Mark Wielaard
+
+ * elf_getdata.c (__libelf_type_aligns): ELF_T_GNUHASH has different
+ alignment for ELFCLASS32 and ELFCLASS64.
+
2022-03-20 Mark Wielaard
* version_xlate.h (elf_cvt_Verdef): Make sure aux_offset and
diff --git a/libelf/elf_getdata.c b/libelf/elf_getdata.c
index 475c6ded..a704aae3 100644
--- a/libelf/elf_getdata.c
+++ b/libelf/elf_getdata.c
@@ -1,5 +1,6 @@
/* Return the next data element from the section after possibly converting it.
Copyright (C) 1998-2005, 2006, 2007, 2015, 2016 Red Hat, Inc.
+ Copyright (C) 2022 Mark J. Wielaard
This file is part of elfutils.
Written by Ulrich Drepper , 1998.
@@ -77,7 +78,6 @@ static const Elf_Type shtype_map[TYPEIDX (SHT_HISUNW) + 1] =
const uint_fast8_t __libelf_type_aligns[ELFCLASSNUM - 1][ELF_T_NUM] =
{
# define TYPE_ALIGNS(Bits) \
-{\
[ELF_T_ADDR] = __alignof__ (ElfW2(Bits,Addr)), \
[ELF_T_EHDR] = __alignof__ (ElfW2(Bits,Ehdr)), \
[ELF_T_HALF] = __alignof__ (ElfW2(Bits,Half)), \
@@ -100,13 +100,17 @@ const uint_fast8_t __libelf_type_aligns[ELFCLASSNUM -
1][ELF_T_NUM] =
[ELF_T_MOVE] = __alignof__ (ElfW2(Bits,Move)), \
[ELF_T_LIB] = __alignof__ (ElfW2(Bits,Lib)), \
[ELF_T_NHDR] = __alignof__ (ElfW2(Bits,Nhdr)), \
- [ELF_T_GNUHASH] = __alignof__ (Elf32_Word),\
[ELF_T_AUXV] = __alignof__ (ElfW2(Bits,auxv_t)), \
[ELF_T_CHDR] = __alignof__ (ElfW2(Bits,Chdr)), \
- [ELF_T_NHDR8] = 8 /* Special case for GNU Property note. */ \
-}
- [ELFCLASS32 - 1] = TYPE_ALIGNS (32),
- [ELFCLASS64 - 1] = TYPE_ALIGNS (64),
+ [ELF_T_NHDR8] = 8 /* Special case for GNU Property note. */
+[ELFCLASS32 - 1] = {
+ TYPE_ALIGNS (32),
+ [ELF_T_GNUHASH] = __alignof__ (Elf32_Word),
+},
+[ELFCLASS64 - 1] = {
+ TYPE_ALIGNS (64),
+ [ELF_T_GNUHASH] = __alignof__ (Elf64_Xword),
+},
# undef TYPE_ALIGNS
};
--
2.30.2
Re: Some fuzzer workarounds
Hi Evgeny, On Tue, Mar 22, 2022 at 07:59:57PM +0300, Evgeny Vereshchagin wrote: > I can also prevent OSS-Fuzz from reporting new bugs found by MSan > by setting the experimental flag > > From > https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers > > If you want to test a particular sanitizer to see what crashes it generates > > without filing them in the issue tracker, you can set an experimental flag > > It should help to figure out whether it makes sense to keep it without > spamming the mailing list > in the process. What do you think? I think that is a good idea. I really believe all the issues reported by MSAN are bogus. While the UBSAN and ASAN issues seem reasonable. At least I have a fix for the last one (45952 Misaligned-address in elf_cvt_gnuhash): https://sourceware.org/pipermail/elfutils-devel/2022q1/004782.html https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=fuzz Cheers, Mark
Re: Some fuzzer workarounds
Hi Mark, >> I can also prevent OSS-Fuzz from reporting new bugs found by MSan >> by setting the experimental flag >> >> From >> https://google.github.io/oss-fuzz/getting-started/new-project-guide/#sanitizers >>> If you want to test a particular sanitizer to see what crashes it generates >>> without filing them in the issue tracker, you can set an experimental flag >> >> It should help to figure out whether it makes sense to keep it without >> spamming the mailing list >> in the process. What do you think? > > I think that is a good idea. I really believe all the issues reported > by MSAN are bogus. They are but all those issues should be gone once https://github.com/google/oss-fuzz/pull/7422 and https://github.com/google/oss-fuzz/pull/7401 are merged. I ran the fuzzers with those patches applied for a few hours and MSan didn't complain. I'll flip the flag there a bit later today anyway and maybe bring it back in a month or so if it isn't noisy. > > While the UBSAN and ASAN issues seem reasonable. At least I have a fix > for the last one (45952 Misaligned-address in elf_cvt_gnuhash): > https://sourceware.org/pipermail/elfutils-devel/2022q1/004782.html > https://code.wildebeest.org/git/user/mjw/elfutils/commit/?h=fuzz I rebased it on top my "fuzzing" branch and the fuzzers, static analyzers, the unit tests on various architectures and so on confirmed that the issue is gone. Thanks! Thanks, Evgeny Vereshchagin
