linux-ext4 - Question about commit "ext4: always initialize the crc32c checksum driver"

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-next>] [day] [month] [year] [list]

Message-ID: <d686d167-9ad2-bfd6-3464-fb35c10ae63d@huawei.com>
Date:   Thu, 13 Dec 2018 15:56:04 +0800
From:   "zhangyi (F)" <yi.zhang@...wei.com>
To:     "Theodore Y. Ts'o" <tytso@....edu>
CC:     <linux-ext4@...r.kernel.org>, Miao Xie <miaoxie@...wei.com>,
        yangerkun <yangerkun@...wei.com>, <yi.zhang@...wei.com>
Subject: Question about commit "ext4: always initialize the crc32c checksum
 driver"

Hi Ted,

I am checking a CVE patch a45403b515 "ext4: always initialize the crc32c checksum driver"[1]
in CVE-2018-1094[2] recently, and have a question about the commit log in this patch.

The patch commit log said:

> The extended attribute code now uses the crc32c checksum for hashing
> purposes, so we should just always always initialize it.  We also want
> to prevent NULL pointer dereferences if one of the metadata checksum
> features is enabled after the file sytsem is originally mounted.

This first fix is clear. But I don't understand the second fix. IIUC, the kernel does not call
ext4_set_feature_metadata_csum() to enable metadata checksum, and this feature can only be enabled
by mkfs,turn2fs or change the image directly. So this feature bit will never change once the
file system is mounted, the second case could never happen ?

BTW, does this patch need on the old kernel before dec214d00e "ext4: xattr inode deduplication" ?

------
[1]. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a45403b51582a
[2]. https://nvd.nist.gov/vuln/detail/CVE-2018-1094

Thanks,
Yi.