[PATCH] xfs: sanitize da node pad field on write

[PATCH] xfs: sanitize da node pad field on write

[Yuto Ohnuki]

The DA node block header (xfs_da3_node_hdr) contains a __pad32 field
that should always be zero. Prior to commit a45086e27dfa21 ("xfs:
validate metadata LSNs against log on v5 superblocks"),
xfs_da3_node_create() did not zero the full header, so __pad32 could
contain stale data on older filesystems.

Clear this field in the write verifier to ensure it is corrected
whenever the block is next written to disk.

Suggested-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
---
 fs/xfs/libxfs/xfs_da_btree.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/fs/xfs/libxfs/xfs_da_btree.c b/fs/xfs/libxfs/xfs_da_btree.c
index ad801b7bd2dd..f6054a47d24c 100644
--- a/fs/xfs/libxfs/xfs_da_btree.c
+++ b/fs/xfs/libxfs/xfs_da_btree.c
@@ -318,6 +318,8 @@ xfs_da3_node_write_verify(
 	if (bip)
 		hdr3->info.lsn = cpu_to_be64(bip->bli_item.li_lsn);
 
+	hdr3->__pad32 = 0;
+
 	xfs_buf_update_cksum(bp, XFS_DA3_NODE_CRC_OFF);
 }
 
-- 
2.50.1




Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284

Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705

Re: [PATCH] xfs: sanitize da node pad field on write

[Darrick J. Wong]

On Tue, Apr 21, 2026 at 06:43:12AM +0100, Yuto Ohnuki wrote:
> The DA node block header (xfs_da3_node_hdr) contains a __pad32 field
> that should always be zero. Prior to commit a45086e27dfa21 ("xfs:
> validate metadata LSNs against log on v5 superblocks"),
> xfs_da3_node_create() did not zero the full header, so __pad32 could
> contain stale data on older filesystems.
> 
> Clear this field in the write verifier to ensure it is corrected
> whenever the block is next written to disk.
> 
> Suggested-by: "Darrick J. Wong" <djwong@kernel.org>
> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
> ---
>  fs/xfs/libxfs/xfs_da_btree.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/xfs/libxfs/xfs_da_btree.c b/fs/xfs/libxfs/xfs_da_btree.c
> index ad801b7bd2dd..f6054a47d24c 100644
> --- a/fs/xfs/libxfs/xfs_da_btree.c
> +++ b/fs/xfs/libxfs/xfs_da_btree.c
> @@ -318,6 +318,8 @@ xfs_da3_node_write_verify(
>  	if (bip)
>  		hdr3->info.lsn = cpu_to_be64(bip->bli_item.li_lsn);
>  
> +	hdr3->__pad32 = 0;

Looks good to me, thanks for clearing this todo :)

Reviewed-by: "Darrick J. Wong" <djwong@kernel.org>

--D

> +
>  	xfs_buf_update_cksum(bp, XFS_DA3_NODE_CRC_OFF);
>  }
>  
> -- 
> 2.50.1
> 
> 
> 
> 
> Amazon Web Services EMEA SARL, 38 avenue John F. Kennedy, L-1855 Luxembourg, R.C.S. Luxembourg B186284
> 
> Amazon Web Services EMEA SARL, Irish Branch, One Burlington Plaza, Burlington Road, Dublin 4, Ireland, branch registration number 908705
> 
> 
> 
> 

Re: [PATCH] xfs: sanitize da node pad field on write

[Dave Chinner]

On Tue, Apr 21, 2026 at 06:43:12AM +0100, Yuto Ohnuki wrote:
> The DA node block header (xfs_da3_node_hdr) contains a __pad32 field
> that should always be zero. Prior to commit a45086e27dfa21 ("xfs:
> validate metadata LSNs against log on v5 superblocks"),
> xfs_da3_node_create() did not zero the full header, so __pad32 could
> contain stale data on older filesystems.
> 
> Clear this field in the write verifier to ensure it is corrected
> whenever the block is next written to disk.
> 
> Suggested-by: "Darrick J. Wong" <djwong@kernel.org>
> Signed-off-by: Yuto Ohnuki <ytohnuki@amazon.com>
> ---
>  fs/xfs/libxfs/xfs_da_btree.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/fs/xfs/libxfs/xfs_da_btree.c b/fs/xfs/libxfs/xfs_da_btree.c
> index ad801b7bd2dd..f6054a47d24c 100644
> --- a/fs/xfs/libxfs/xfs_da_btree.c
> +++ b/fs/xfs/libxfs/xfs_da_btree.c
> @@ -318,6 +318,8 @@ xfs_da3_node_write_verify(
>  	if (bip)
>  		hdr3->info.lsn = cpu_to_be64(bip->bli_item.li_lsn);
>  
> +	hdr3->__pad32 = 0;
> +

Please add a comment explaining why the padding is being written
unconditionally here. By itself like this it makes no sense at all.

-Dave.
-- 
Dave Chinner
dgc@kernel.org