linux-kernel - Re: [PATCH 08/16] fs/ntfs3: Fix detected field-spanning write (size 8) of single field "le->name"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAMuHMdVu1xAHDo1UUsCKEX=pbiZWab0HwkO6hObwE6uB2yD4RQ@mail.gmail.com>
Date:   Thu, 7 Dec 2023 10:31:53 +0100
From:   Geert Uytterhoeven <geert@...ux-m68k.org>
To:     Konstantin Komarovc <almaz.alexandrovich@...agon-software.com>
Cc:     ntfs3@...ts.linux.dev, linux-kernel@...r.kernel.org,
        linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 08/16] fs/ntfs3: Fix detected field-spanning write (size
 8) of single field "le->name"

Hi Konstantin,

On Wed, Dec 6, 2023 at 4:12 PM Konstantin Komarovc
<almaz.alexandrovich@...agon-software.com> wrote:
> Signed-off-by: Konstantin Komarov <almaz.alexandrovich@...agon-software.com>

Thanks for your patch, which is now commit d155617006ebc172 ("fs/ntfs3:
Fix detected field-spanning write (size 8) of single field "le->name"")
in next-20231207.

> --- a/fs/ntfs3/ntfs.h
> +++ b/fs/ntfs3/ntfs.h
> @@ -523,7 +523,7 @@ struct ATTR_LIST_ENTRY {
>       __le64 vcn;        // 0x08: Starting VCN of this attribute.
>       struct MFT_REF ref;    // 0x10: MFT record number with attribute.
>       __le16 id;        // 0x18: struct ATTRIB ID.
> -    __le16 name[3];        // 0x1A: Just to align. To get real name can
> use bNameOffset.
> +    __le16 name[];        // 0x1A: Just to align. To get real name can
> use name_off.

noreply@...erman.id.au reports for all m68k configs[1]:

include/linux/build_bug.h:78:41: error: static assertion failed:
"sizeof(struct ATTR_LIST_ENTRY) == 0x20"

>
>   }; // sizeof(0x20)

Indeed, we now have a hole of 4 bytes at the end of the structure,
which shrinks the size of the structure on all architectures where
alignof(u64) < sizeof(u64).

So either the patch should be reverted, or explicit padding should
be added.  Your patch description is not very descriptive, so I
don't know which is the correct solution.

[1] http://kisskb.ellerman.id.au/kisskb/head/8e00ce02066e8f6f1ad5eab49a2ede7bf7a5ef64

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds