* [PATCH v3] md/raid5: validate payload size before calculating payload_len
@ 2026-09-02 18:18 Martin Wilck
2026-09-03 3:44 ` Junrui Luo
2026-09-07 6:29 ` yu kuai
0 siblings, 2 replies; 4+ messages in thread
From: Martin Wilck @ 2026-09-02 18:18 UTC (permalink / raw)
To: Yu Kuai, Song Liu
Cc: Xiao Ni, Li Nan, linux-raid, Martin Wilck, Junrui Luo, stable
Commit b0cc3ae97e89 ("md/raid5: validate payload size before accessing
journal metadata") introduced a bounds check to verify that a given payload
fits into the current metadata block. In order to calculate the payload
size, it has to access the members payload->header.type and payload->size,
the offset of which may already be past the end of the metadata block,
because the loop condition only checks that the first byte of the payload
is inside, and the payload entries have variable sizes. Later on,
payload->checksum[0] and payload->checksum[1] are accessed without
verifying that payload->size is large enough.
Add another check to make sure that payload->size can be safely
accessed, and make sure that the checksum fields are accessible.
This issue has been found by AI (gemma4, Gemini) during a backport
review.
Cc: Junrui Luo <moonafterrain@outlook.com>
Cc: stable@vger.kernel.org
Fixes: b0cc3ae97e89 ("md/raid5: validate payload size before accessing journal metadata")
Signed-off-by: Martin Wilck <mwilck@suse.com>
---
Changes v2 -> v3: Fixed another issue reported by Sashiko
* Modify loop condition to make sure the payload->header.type can be accessed
Changes v1 -> v2: Fixed issues reported by Sashiko
* fix use of wrong variable name payload_len instead of mb_offset
* add checks to ensure payload->size is large enough to hold the checksum values
---
drivers/md/raid5-cache.c | 34 ++++++++++++++++++++++++++--------
1 file changed, 26 insertions(+), 8 deletions(-)
diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
index 7b7546bfa21f..031a89faddae 100644
--- a/drivers/md/raid5-cache.c
+++ b/drivers/md/raid5-cache.c
@@ -2001,27 +2001,36 @@ r5l_recovery_verify_data_checksum_for_mb(struct r5l_log *log,
if (!page)
return -ENOMEM;
- while (mb_offset < le32_to_cpu(mb->meta_size)) {
+ while (mb_offset + sizeof(struct r5l_payload_header) < le32_to_cpu(mb->meta_size)) {
+ uint32_t payload_size;
sector_t payload_len;
payload = (void *)mb + mb_offset;
payload_flush = (void *)mb + mb_offset;
if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_DATA) {
+ if (mb_offset + sizeof(struct r5l_payload_data_parity)
+ > le32_to_cpu(mb->meta_size))
+ goto mismatch;
+ payload_size = le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9);
payload_len = sizeof(struct r5l_payload_data_parity) +
- (sector_t)sizeof(__le32) *
- (le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
- if (mb_offset + payload_len > le32_to_cpu(mb->meta_size))
+ (sector_t)sizeof(__le32) * payload_size;
+ if (mb_offset + payload_len > le32_to_cpu(mb->meta_size) ||
+ payload_size < 1)
goto mismatch;
if (r5l_recovery_verify_data_checksum(
log, ctx, page, log_offset,
payload->checksum[0]) < 0)
goto mismatch;
} else if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_PARITY) {
+ if (mb_offset + sizeof(struct r5l_payload_data_parity)
+ > le32_to_cpu(mb->meta_size))
+ goto mismatch;
+ payload_size = le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9);
payload_len = sizeof(struct r5l_payload_data_parity) +
- (sector_t)sizeof(__le32) *
- (le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
- if (mb_offset + payload_len > le32_to_cpu(mb->meta_size))
+ (sector_t)sizeof(__le32) * payload_size;
+ if (mb_offset + payload_len > le32_to_cpu(mb->meta_size) ||
+ payload_size < conf->max_degraded)
goto mismatch;
if (r5l_recovery_verify_data_checksum(
log, ctx, page, log_offset,
@@ -2035,6 +2044,9 @@ r5l_recovery_verify_data_checksum_for_mb(struct r5l_log *log,
payload->checksum[1]) < 0)
goto mismatch;
} else if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_FLUSH) {
+ if (mb_offset + sizeof(struct r5l_payload_flush)
+ > le32_to_cpu(mb->meta_size))
+ goto mismatch;
payload_len = sizeof(struct r5l_payload_flush) +
(sector_t)le32_to_cpu(payload_flush->size);
if (mb_offset + payload_len > le32_to_cpu(mb->meta_size))
@@ -2096,7 +2108,7 @@ r5c_recovery_analyze_meta_block(struct r5l_log *log,
mb_offset = sizeof(struct r5l_meta_block);
log_offset = r5l_ring_add(log, ctx->pos, BLOCK_SECTORS);
- while (mb_offset < le32_to_cpu(mb->meta_size)) {
+ while (mb_offset + sizeof(struct r5l_payload_header) < le32_to_cpu(mb->meta_size)) {
sector_t payload_len;
int dd;
@@ -2106,6 +2118,9 @@ r5c_recovery_analyze_meta_block(struct r5l_log *log,
if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_FLUSH) {
int i, count;
+ if (mb_offset + sizeof(struct r5l_payload_flush) >
+ le32_to_cpu(mb->meta_size))
+ return -EINVAL;
payload_len = sizeof(struct r5l_payload_flush) +
(sector_t)le32_to_cpu(payload_flush->size);
if (mb_offset + payload_len >
@@ -2130,6 +2145,9 @@ r5c_recovery_analyze_meta_block(struct r5l_log *log,
}
/* DATA or PARITY payload */
+ if (mb_offset + sizeof(struct r5l_payload_data_parity) >
+ le32_to_cpu(mb->meta_size))
+ return -EINVAL;
payload_len = sizeof(struct r5l_payload_data_parity) +
(sector_t)sizeof(__le32) *
(le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
--
2.51.0
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH v3] md/raid5: validate payload size before calculating payload_len
2026-09-02 18:18 [PATCH v3] md/raid5: validate payload size before calculating payload_len Martin Wilck
@ 2026-09-03 3:44 ` Junrui Luo
2026-09-07 6:29 ` yu kuai
1 sibling, 0 replies; 4+ messages in thread
From: Junrui Luo @ 2026-09-03 3:44 UTC (permalink / raw)
To: Martin Wilck
Cc: Yu Kuai, Song Liu, Xiao Ni, Li Nan, linux-raid@vger.kernel.org,
Martin Wilck, stable@vger.kernel.org
Hi Martin,
Thanks for fixing the follow-up out-of-bounds accesses. The diff looks
good to me.
Thanks,
Junrui
> On Sep 3, 2026, at 2:18 AM, Martin Wilck <martin.wilck@suse.com> wrote:
>
> Commit b0cc3ae97e89 ("md/raid5: validate payload size before accessing
> journal metadata") introduced a bounds check to verify that a given payload
> fits into the current metadata block. In order to calculate the payload
> size, it has to access the members payload->header.type and payload->size,
> the offset of which may already be past the end of the metadata block,
> because the loop condition only checks that the first byte of the payload
> is inside, and the payload entries have variable sizes. Later on,
> payload->checksum[0] and payload->checksum[1] are accessed without
> verifying that payload->size is large enough.
>
> Add another check to make sure that payload->size can be safely
> accessed, and make sure that the checksum fields are accessible.
>
> This issue has been found by AI (gemma4, Gemini) during a backport
> review.
>
> Cc: Junrui Luo <moonafterrain@outlook.com>
> Cc: stable@vger.kernel.org
> Fixes: b0cc3ae97e89 ("md/raid5: validate payload size before accessing journal metadata")
> Signed-off-by: Martin Wilck <mwilck@suse.com>
> ---
> Changes v2 -> v3: Fixed another issue reported by Sashiko
>
> * Modify loop condition to make sure the payload->header.type can be accessed
>
> Changes v1 -> v2: Fixed issues reported by Sashiko
>
> * fix use of wrong variable name payload_len instead of mb_offset
> * add checks to ensure payload->size is large enough to hold the checksum values
>
> ---
> drivers/md/raid5-cache.c | 34 ++++++++++++++++++++++++++--------
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index 7b7546bfa21f..031a89faddae 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c
> @@ -2001,27 +2001,36 @@ r5l_recovery_verify_data_checksum_for_mb(struct r5l_log *log,
> if (!page)
> return -ENOMEM;
>
> - while (mb_offset < le32_to_cpu(mb->meta_size)) {
> + while (mb_offset + sizeof(struct r5l_payload_header) < le32_to_cpu(mb->meta_size)) {
> + uint32_t payload_size;
> sector_t payload_len;
>
> payload = (void *)mb + mb_offset;
> payload_flush = (void *)mb + mb_offset;
>
> if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_DATA) {
> + if (mb_offset + sizeof(struct r5l_payload_data_parity)
> + > le32_to_cpu(mb->meta_size))
> + goto mismatch;
> + payload_size = le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9);
> payload_len = sizeof(struct r5l_payload_data_parity) +
> - (sector_t)sizeof(__le32) *
> - (le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
> - if (mb_offset + payload_len > le32_to_cpu(mb->meta_size))
> + (sector_t)sizeof(__le32) * payload_size;
> + if (mb_offset + payload_len > le32_to_cpu(mb->meta_size) ||
> + payload_size < 1)
> goto mismatch;
> if (r5l_recovery_verify_data_checksum(
> log, ctx, page, log_offset,
> payload->checksum[0]) < 0)
> goto mismatch;
> } else if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_PARITY) {
> + if (mb_offset + sizeof(struct r5l_payload_data_parity)
> + > le32_to_cpu(mb->meta_size))
> + goto mismatch;
> + payload_size = le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9);
> payload_len = sizeof(struct r5l_payload_data_parity) +
> - (sector_t)sizeof(__le32) *
> - (le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
> - if (mb_offset + payload_len > le32_to_cpu(mb->meta_size))
> + (sector_t)sizeof(__le32) * payload_size;
> + if (mb_offset + payload_len > le32_to_cpu(mb->meta_size) ||
> + payload_size < conf->max_degraded)
> goto mismatch;
> if (r5l_recovery_verify_data_checksum(
> log, ctx, page, log_offset,
> @@ -2035,6 +2044,9 @@ r5l_recovery_verify_data_checksum_for_mb(struct r5l_log *log,
> payload->checksum[1]) < 0)
> goto mismatch;
> } else if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_FLUSH) {
> + if (mb_offset + sizeof(struct r5l_payload_flush)
> + > le32_to_cpu(mb->meta_size))
> + goto mismatch;
> payload_len = sizeof(struct r5l_payload_flush) +
> (sector_t)le32_to_cpu(payload_flush->size);
> if (mb_offset + payload_len > le32_to_cpu(mb->meta_size))
> @@ -2096,7 +2108,7 @@ r5c_recovery_analyze_meta_block(struct r5l_log *log,
> mb_offset = sizeof(struct r5l_meta_block);
> log_offset = r5l_ring_add(log, ctx->pos, BLOCK_SECTORS);
>
> - while (mb_offset < le32_to_cpu(mb->meta_size)) {
> + while (mb_offset + sizeof(struct r5l_payload_header) < le32_to_cpu(mb->meta_size)) {
> sector_t payload_len;
> int dd;
>
> @@ -2106,6 +2118,9 @@ r5c_recovery_analyze_meta_block(struct r5l_log *log,
> if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_FLUSH) {
> int i, count;
>
> + if (mb_offset + sizeof(struct r5l_payload_flush) >
> + le32_to_cpu(mb->meta_size))
> + return -EINVAL;
> payload_len = sizeof(struct r5l_payload_flush) +
> (sector_t)le32_to_cpu(payload_flush->size);
> if (mb_offset + payload_len >
> @@ -2130,6 +2145,9 @@ r5c_recovery_analyze_meta_block(struct r5l_log *log,
> }
>
> /* DATA or PARITY payload */
> + if (mb_offset + sizeof(struct r5l_payload_data_parity) >
> + le32_to_cpu(mb->meta_size))
> + return -EINVAL;
> payload_len = sizeof(struct r5l_payload_data_parity) +
> (sector_t)sizeof(__le32) *
> (le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
> --
> 2.51.0
>
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] md/raid5: validate payload size before calculating payload_len
2026-09-02 18:18 [PATCH v3] md/raid5: validate payload size before calculating payload_len Martin Wilck
2026-09-03 3:44 ` Junrui Luo
@ 2026-09-07 6:29 ` yu kuai
2026-09-07 15:43 ` Martin Wilck
1 sibling, 1 reply; 4+ messages in thread
From: yu kuai @ 2026-09-07 6:29 UTC (permalink / raw)
To: Martin Wilck, Song Liu, yu kuai
Cc: Xiao Ni, Li Nan, linux-raid, Martin Wilck, Junrui Luo, stable
Hi,
在 2026/9/3 2:18, Martin Wilck 写道:
> Commit b0cc3ae97e89 ("md/raid5: validate payload size before accessing
> journal metadata") introduced a bounds check to verify that a given payload
> fits into the current metadata block. In order to calculate the payload
> size, it has to access the members payload->header.type and payload->size,
> the offset of which may already be past the end of the metadata block,
> because the loop condition only checks that the first byte of the payload
> is inside, and the payload entries have variable sizes. Later on,
> payload->checksum[0] and payload->checksum[1] are accessed without
> verifying that payload->size is large enough.
>
> Add another check to make sure that payload->size can be safely
> accessed, and make sure that the checksum fields are accessible.
>
> This issue has been found by AI (gemma4, Gemini) during a backport
> review.
>
> Cc: Junrui Luo <moonafterrain@outlook.com>
> Cc: stable@vger.kernel.org
> Fixes: b0cc3ae97e89 ("md/raid5: validate payload size before accessing journal metadata")
> Signed-off-by: Martin Wilck <mwilck@suse.com>
> ---
> Changes v2 -> v3: Fixed another issue reported by Sashiko
>
> * Modify loop condition to make sure the payload->header.type can be accessed
>
> Changes v1 -> v2: Fixed issues reported by Sashiko
>
> * fix use of wrong variable name payload_len instead of mb_offset
> * add checks to ensure payload->size is large enough to hold the checksum values
>
> ---
> drivers/md/raid5-cache.c | 34 ++++++++++++++++++++++++++--------
> 1 file changed, 26 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> index 7b7546bfa21f..031a89faddae 100644
> --- a/drivers/md/raid5-cache.c
> +++ b/drivers/md/raid5-cache.c
> @@ -2001,27 +2001,36 @@ r5l_recovery_verify_data_checksum_for_mb(struct r5l_log *log,
> if (!page)
> return -ENOMEM;
>
> - while (mb_offset < le32_to_cpu(mb->meta_size)) {
> + while (mb_offset + sizeof(struct r5l_payload_header) < le32_to_cpu(mb->meta_size)) {
Offset can't be meta_size, however, is it possible that the remaining space is exactly one
payload size? If so I think <= should be used here.
> + uint32_t payload_size;
checkpatch report u32 is prefered.
> sector_t payload_len;
>
> payload = (void *)mb + mb_offset;
> payload_flush = (void *)mb + mb_offset;
>
> if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_DATA) {
> + if (mb_offset + sizeof(struct r5l_payload_data_parity)
> + > le32_to_cpu(mb->meta_size))
> + goto mismatch;
> + payload_size = le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9);
> payload_len = sizeof(struct r5l_payload_data_parity) +
> - (sector_t)sizeof(__le32) *
> - (le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
> - if (mb_offset + payload_len > le32_to_cpu(mb->meta_size))
> + (sector_t)sizeof(__le32) * payload_size;
> + if (mb_offset + payload_len > le32_to_cpu(mb->meta_size) ||
> + payload_size < 1)
> goto mismatch;
> if (r5l_recovery_verify_data_checksum(
> log, ctx, page, log_offset,
> payload->checksum[0]) < 0)
> goto mismatch;
> } else if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_PARITY) {
> + if (mb_offset + sizeof(struct r5l_payload_data_parity)
> + > le32_to_cpu(mb->meta_size))
> + goto mismatch;
> + payload_size = le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9);
> payload_len = sizeof(struct r5l_payload_data_parity) +
> - (sector_t)sizeof(__le32) *
> - (le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
> - if (mb_offset + payload_len > le32_to_cpu(mb->meta_size))
> + (sector_t)sizeof(__le32) * payload_size;
> + if (mb_offset + payload_len > le32_to_cpu(mb->meta_size) ||
> + payload_size < conf->max_degraded)
> goto mismatch;
> if (r5l_recovery_verify_data_checksum(
> log, ctx, page, log_offset,
> @@ -2035,6 +2044,9 @@ r5l_recovery_verify_data_checksum_for_mb(struct r5l_log *log,
> payload->checksum[1]) < 0)
> goto mismatch;
> } else if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_FLUSH) {
> + if (mb_offset + sizeof(struct r5l_payload_flush)
> + > le32_to_cpu(mb->meta_size))
> + goto mismatch;
> payload_len = sizeof(struct r5l_payload_flush) +
> (sector_t)le32_to_cpu(payload_flush->size);
> if (mb_offset + payload_len > le32_to_cpu(mb->meta_size))
> @@ -2096,7 +2108,7 @@ r5c_recovery_analyze_meta_block(struct r5l_log *log,
> mb_offset = sizeof(struct r5l_meta_block);
> log_offset = r5l_ring_add(log, ctx->pos, BLOCK_SECTORS);
>
> - while (mb_offset < le32_to_cpu(mb->meta_size)) {
> + while (mb_offset + sizeof(struct r5l_payload_header) < le32_to_cpu(mb->meta_size)) {
> sector_t payload_len;
> int dd;
>
> @@ -2106,6 +2118,9 @@ r5c_recovery_analyze_meta_block(struct r5l_log *log,
> if (le16_to_cpu(payload->header.type) == R5LOG_PAYLOAD_FLUSH) {
> int i, count;
>
> + if (mb_offset + sizeof(struct r5l_payload_flush) >
> + le32_to_cpu(mb->meta_size))
> + return -EINVAL;
> payload_len = sizeof(struct r5l_payload_flush) +
> (sector_t)le32_to_cpu(payload_flush->size);
> if (mb_offset + payload_len >
> @@ -2130,6 +2145,9 @@ r5c_recovery_analyze_meta_block(struct r5l_log *log,
> }
>
> /* DATA or PARITY payload */
> + if (mb_offset + sizeof(struct r5l_payload_data_parity) >
> + le32_to_cpu(mb->meta_size))
> + return -EINVAL;
> payload_len = sizeof(struct r5l_payload_data_parity) +
> (sector_t)sizeof(__le32) *
> (le32_to_cpu(payload->size) >> (PAGE_SHIFT - 9));
--
Thanks,
Kuai
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH v3] md/raid5: validate payload size before calculating payload_len
2026-09-07 6:29 ` yu kuai
@ 2026-09-07 15:43 ` Martin Wilck
0 siblings, 0 replies; 4+ messages in thread
From: Martin Wilck @ 2026-09-07 15:43 UTC (permalink / raw)
To: yukuai, Song Liu; +Cc: Xiao Ni, Li Nan, linux-raid, Junrui Luo, stable
On Mon, 2026-09-07 at 14:29 +0800, yu kuai wrote:
> Hi,
>
> 在 2026/9/3 2:18, Martin Wilck 写道:
> > Commit b0cc3ae97e89 ("md/raid5: validate payload size before
> > accessing
> > journal metadata") introduced a bounds check to verify that a given
> > payload
> > fits into the current metadata block. In order to calculate the
> > payload
> > size, it has to access the members payload->header.type and
> > payload->size,
> > the offset of which may already be past the end of the metadata
> > block,
> > because the loop condition only checks that the first byte of the
> > payload
> > is inside, and the payload entries have variable sizes. Later on,
> > payload->checksum[0] and payload->checksum[1] are accessed without
> > verifying that payload->size is large enough.
> >
> > Add another check to make sure that payload->size can be safely
> > accessed, and make sure that the checksum fields are accessible.
> >
> > This issue has been found by AI (gemma4, Gemini) during a backport
> > review.
> >
> > Cc: Junrui Luo <moonafterrain@outlook.com>
> > Cc: stable@vger.kernel.org
> > Fixes: b0cc3ae97e89 ("md/raid5: validate payload size before
> > accessing journal metadata")
> > Signed-off-by: Martin Wilck <mwilck@suse.com>
> > ---
> > Changes v2 -> v3: Fixed another issue reported by Sashiko
> >
> > * Modify loop condition to make sure the payload->header.type can
> > be accessed
> >
> > Changes v1 -> v2: Fixed issues reported by Sashiko
> >
> > * fix use of wrong variable name payload_len instead of mb_offset
> > * add checks to ensure payload->size is large enough to hold the
> > checksum values
> >
> > ---
> > drivers/md/raid5-cache.c | 34 ++++++++++++++++++++++++++--------
> > 1 file changed, 26 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/md/raid5-cache.c b/drivers/md/raid5-cache.c
> > index 7b7546bfa21f..031a89faddae 100644
> > --- a/drivers/md/raid5-cache.c
> > +++ b/drivers/md/raid5-cache.c
> > @@ -2001,27 +2001,36 @@
> > r5l_recovery_verify_data_checksum_for_mb(struct r5l_log *log,
> > if (!page)
> > return -ENOMEM;
> >
> > - while (mb_offset < le32_to_cpu(mb->meta_size)) {
> > + while (mb_offset + sizeof(struct r5l_payload_header) <
> > le32_to_cpu(mb->meta_size)) {
>
> Offset can't be meta_size, however, is it possible that the remaining
> space is exactly one
> payload size? If so I think <= should be used here.
Right. But practically speaking, as this must be either a struct
r5l_payload_data_parity or a struct r5l_payload_flush, and both contain
additional elements besides the header, if "==" applies here, we will
run into one of the following error conditions later, because the size
element won't be accessible.
Anyway, for the sake of correctness, I'll change it to "<=".
>
> > + uint32_t payload_size;
>
> checkpatch report u32 is prefered.
Strange, it did not for me. I'll change it.
Thanks,
Martin
--
Dr. Martin Wilck <mwilck@suse.com>
SUSE Software Solutions Germany GmbH, Frankenstr. 146, 90461 Nürnberg,
Germany
Geschäftsführer: Jochen Jaser, Andrew McDonald (HRB 36809,AG Nürnberg)
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2026-09-07 15:43 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2026-09-02 18:18 [PATCH v3] md/raid5: validate payload size before calculating payload_len Martin Wilck
2026-09-03 3:44 ` Junrui Luo
2026-09-07 6:29 ` yu kuai
2026-09-07 15:43 ` Martin Wilck
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox