Prior report for the nvmet-tcp unbounded SGL length fix in 7.3

Prior report for the nvmet-tcp unbounded SGL length fix in 7.3

[Shivam Kumar]

Hi all,

I originally reported this issue to security@kernel.org on 2026-03-17
(Cc Sagi), Message-ID:
<CA+ysrSJUFi8cHzU8g9Nrbbkcuo0F7vh8CMn3ht15gSk3BbK45A@mail.gmail.com>
and posted the first patch for it in this thread,
"[PATCH] nvmet-tcp: bound sgl->length check in nvmet_tcp_map_data()"
(2026-03-19).

Commit 4a3f002 ("nvmet-tcp: bound SGL data length before allocating
command buffers"), merged for 7.3, adds the same NVMET_TCP_MAXH2CDATA
bound with the same status code.

These things happen independently, and I'm glad the issue is fixed.
Would it be possible to get some acknowledgement for the original
report?

Thanks,
Shivam

Re: Prior report for the nvmet-tcp unbounded SGL length fix in 7.3

[Shivam Kumar]

On Mon, Aug 24, 2026 at 11:42 AM Shivam Kumar
<kumar.shivam43666@gmail.com> wrote:
>
> Hi all,
>
> I originally reported this issue to security@kernel.org on 2026-03-17
> (Cc Sagi), Message-ID:
> <CA+ysrSJUFi8cHzU8g9Nrbbkcuo0F7vh8CMn3ht15gSk3BbK45A@mail.gmail.com>
> and posted the first patch for it in this thread,
> "[PATCH] nvmet-tcp: bound sgl->length check in nvmet_tcp_map_data()"
> (2026-03-19).
>
> Commit 4a3f002 ("nvmet-tcp: bound SGL data length before allocating
> command buffers"), merged for 7.3, adds the same NVMET_TCP_MAXH2CDATA
> bound with the same status code.
>
> These things happen independently, and I'm glad the issue is fixed.
> Would it be possible to get some acknowledgement for the original
> report?
>
> Thanks,
> Shivam

Adding Maurizio and Christoph, who reviewed the original patch.

To be clear, "this thread" above refers to the March thread, not this
one, I meant to send this as a reply there. Link for reference:

https://lore.kernel.org/all/CA+ysrS+fsJQ+4x7jHoSEX_tiYRQJC8LEhuH2stKA6Q4qSK-MWA@mail.gmail.com/

Re: Prior report for the nvmet-tcp unbounded SGL length fix in 7.3

[Greg Kroah-Hartman]

On Mon, Aug 24, 2026 at 11:42:50AM -0400, Shivam Kumar wrote:
> Hi all,
> 
> I originally reported this issue to security@kernel.org on 2026-03-17
> (Cc Sagi), Message-ID:
> <CA+ysrSJUFi8cHzU8g9Nrbbkcuo0F7vh8CMn3ht15gSk3BbK45A@mail.gmail.com>
> and posted the first patch for it in this thread,
> "[PATCH] nvmet-tcp: bound sgl->length check in nvmet_tcp_map_data()"
> (2026-03-19).
> 
> Commit 4a3f002 ("nvmet-tcp: bound SGL data length before allocating
> command buffers"), merged for 7.3, adds the same NVMET_TCP_MAXH2CDATA
> bound with the same status code.
> 
> These things happen independently, and I'm glad the issue is fixed.
> Would it be possible to get some acknowledgement for the original
> report?

"acknowledgment" in what way?  If the patch is merged, what can we do
here?

thanks,

greg k-h

Re: Prior report for the nvmet-tcp unbounded SGL length fix in 7.3

[Shivam Kumar]

Hi Greg,

Just the CVE, if one is assigned to 4a3f002, being recorded as the
reporter would be all I'm after.

Thanks,
Shivam

On Mon, Aug 24, 2026 at 12:01 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Mon, Aug 24, 2026 at 11:42:50AM -0400, Shivam Kumar wrote:
> > Hi all,
> >
> > I originally reported this issue to security@kernel.org on 2026-03-17
> > (Cc Sagi), Message-ID:
> > <CA+ysrSJUFi8cHzU8g9Nrbbkcuo0F7vh8CMn3ht15gSk3BbK45A@mail.gmail.com>
> > and posted the first patch for it in this thread,
> > "[PATCH] nvmet-tcp: bound sgl->length check in nvmet_tcp_map_data()"
> > (2026-03-19).
> >
> > Commit 4a3f002 ("nvmet-tcp: bound SGL data length before allocating
> > command buffers"), merged for 7.3, adds the same NVMET_TCP_MAXH2CDATA
> > bound with the same status code.
> >
> > These things happen independently, and I'm glad the issue is fixed.
> > Would it be possible to get some acknowledgement for the original
> > report?
>
> "acknowledgment" in what way?  If the patch is merged, what can we do
> here?
>
> thanks,
>
> greg k-h

Re: Prior report for the nvmet-tcp unbounded SGL length fix in 7.3

[Greg Kroah-Hartman]

On Mon, Aug 24, 2026 at 12:07:28PM -0400, Shivam Kumar wrote:
> Hi Greg,
> 
> Just the CVE, if one is assigned to 4a3f002, being recorded as the
> reporter would be all I'm after.

We do not have names/reporters on CVEs at all, we rely on the git commit
text, but also will be glad to link to any external documentation as a
reference if needed.

But I think you got the git id there wrong...

thanks,

greg k-h

Re: Prior report for the nvmet-tcp unbounded SGL length fix in 7.3

[Shivam Kumar]

On Mon, Aug 24, 2026 at 12:54 PM Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> On Mon, Aug 24, 2026 at 12:07:28PM -0400, Shivam Kumar wrote:
> > Hi Greg,
> >
> > Just the CVE, if one is assigned to 4a3f002, being recorded as the
> > reporter would be all I'm after.
>
> We do not have names/reporters on CVEs at all, we rely on the git commit
> text, but also will be glad to link to any external documentation as a
> reference if needed.
>
> But I think you got the git id there wrong...
>
> thanks,
>
> greg k-h

Understood, thanks for explaining.

A reference link would be great if a CVE is assigned. The relevant
thread is:
https://lore.kernel.org/all/CA+ysrS+fsJQ+4x7jHoSEX_tiYRQJC8LEhuH2stKA6Q4qSK-MWA@mail.gmail.com/

And apologies for the bad commit id, the correct one is
4a3f00262a044e8e15064b1a6860968bf0500bf4
("nvmet-tcp: bound SGL data length before allocating command buffers").

Thanks,
Shivam

Re: Prior report for the nvmet-tcp unbounded SGL length fix in 7.3

[Greg Kroah-Hartman]

On Mon, Aug 24, 2026 at 02:18:44PM -0400, Shivam Kumar wrote:
> On Mon, Aug 24, 2026 at 12:54 PM Greg Kroah-Hartman
> <gregkh@linuxfoundation.org> wrote:
> >
> > On Mon, Aug 24, 2026 at 12:07:28PM -0400, Shivam Kumar wrote:
> > > Hi Greg,
> > >
> > > Just the CVE, if one is assigned to 4a3f002, being recorded as the
> > > reporter would be all I'm after.
> >
> > We do not have names/reporters on CVEs at all, we rely on the git commit
> > text, but also will be glad to link to any external documentation as a
> > reference if needed.
> >
> > But I think you got the git id there wrong...
> >
> > thanks,
> >
> > greg k-h
> 
> Understood, thanks for explaining.
> 
> A reference link would be great if a CVE is assigned. The relevant
> thread is:
> https://lore.kernel.org/all/CA+ysrS+fsJQ+4x7jHoSEX_tiYRQJC8LEhuH2stKA6Q4qSK-MWA@mail.gmail.com/
> 
> And apologies for the bad commit id, the correct one is
> 4a3f00262a044e8e15064b1a6860968bf0500bf4
> ("nvmet-tcp: bound SGL data length before allocating command buffers").

Please see:
        https://www.kernel.org/doc/html/latest/process/cve.html
for how kernel CVEs are assigned.

thanks,

greg k-h

Re: Prior report for the nvmet-tcp unbounded SGL length fix in 7.3

[Maurizio Lombardi]

On Mon Aug 24, 2026 at 5:42 PM CEST, Shivam Kumar wrote:
> Hi all,
>
> I originally reported this issue to security@kernel.org on 2026-03-17
> (Cc Sagi), Message-ID:
> <CA+ysrSJUFi8cHzU8g9Nrbbkcuo0F7vh8CMn3ht15gSk3BbK45A@mail.gmail.com>
> and posted the first patch for it in this thread,
> "[PATCH] nvmet-tcp: bound sgl->length check in nvmet_tcp_map_data()"
> (2026-03-19).
>
> Commit 4a3f002 ("nvmet-tcp: bound SGL data length before allocating
> command buffers"), merged for 7.3, adds the same NVMET_TCP_MAXH2CDATA
> bound with the same status code.

I didn't notice this new patch, but I still suspect that MAXH2CDATA is misused
and that the correct solution is to set MDTS.

Maurizio