[SECURITY] net: nfs: buffer overflow in nfs_readlink_reply() in legacy NFS path (nfs-common.c) , incomplete fix

[Sebastián Alba]

Thank you for the quick response. I have submitted the patch to the mailing
list:

  Message-ID: <20260409164440.323405-1-sebasjosue84 at gmail.com>
  Subject: [PATCH] net: nfs: fix buffer overflow in nfs_readlink_reply()
  To: u-boot at lists.denx.de
  Cc: trini at konsulko.com, jerome.forissier at linaro.org,
stable at vger.kernel.org

Regarding the CVE, I will request one directly via cveform.mitre.org as you
suggested.

Please let me know if any changes are needed.

El jue, 9 abr 2026 a las 9:40, Tom Rini (<trini at konsulko.com>) escribió:

> On Wed, Apr 08, 2026 at 10:56:59PM -0600, Sebastián Alba wrote:
> > Hi Jerome, Tom, and U-Boot security list,
> >
> > I would like to report a buffer overflow vulnerability in
> > net/nfs-common.c:nfs_readlink_reply()
> > that was not addressed by the recent fix in commit fd6e3d34097f ("net:
> > lwip: nfs: fix buffer
> > overflow when using symlinks").
> >
> >
> > *== Vulnerability ==*
> > File: net/nfs-common.c | Function: nfs_readlink_reply() | Lines: ~667-685
> >
> > The `rlen` field from a server READLINK reply is validated only against
> the
> > incoming packet
> > length (check inherited from CVE-2019-14195), but NOT against the
> > destination buffer
> > nfs_path_buff[2048]:
> >
> >     rlen = ntohl(rpc_pkt.u.reply.data[1 + nfsv3_data_offset]);
> >
> >     /* validates rlen against packet size only */
> >     if (((uchar *)&rpc_pkt.u.reply.data[0] - (uchar *)(&rpc_pkt) + rlen)
> >
> > len)
> >         return -NFS_RPC_DROP;
> >
> >     /* MISSING: check that pathlen + rlen < sizeof(nfs_path_buff) */
> >     pathlen = strlen(nfs_path);
> >     memcpy(nfs_path + pathlen, data, rlen);   /* BSS overflow */
> >     nfs_path[pathlen + rlen] = 0;             /* OOB write */
> >
> > An attacker controlling an NFS server can send a syntactically valid
> > READLINK reply
> > (rlen <= packet_size) where pathlen + rlen exceeds sizeof(nfs_path_buff)
> =
> > 2048,
> > overflowing the BSS buffer into adjacent memory.
> >
> >
> > *== Relationship to Existing Fixes ==*
> > - CVE-2019-14195 (cf3a4f1e86): added a packet-size check for rlen only —
> > does not bound the copy against nfs_path_buff.
> > - fd6e3d34097f ("net: lwip: nfs: fix buffer overflow when using
> symlinks"):
> > fixed the same overflow class in net/lwip/nfs.c only; net/nfs-common.c
> > (legacy NFS path) was not addressed.
> >
> >
> > *== Impact ==*
> > CWE-120 | CVSS 8.8 (AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)
> > Affects any U-Boot client booting via NFS when symlinks are present on
> the
> > server.
> >
> >
> > *== Suggested Fix ==*
> > --- a/net/nfs-common.c
> > +++ b/net/nfs-common.c
> >      pathlen = strlen(nfs_path);
> > +    if (pathlen + rlen >= sizeof(nfs_path_buff))
> > +        return -NFS_RPC_DROP;
> >      memcpy(nfs_path + pathlen, data, rlen);
> >      nfs_path[pathlen + rlen] = 0;
> >
> > Also required for the absolute path branch (~L683):
> > +    if (rlen >= sizeof(nfs_path_buff))
> > +        return -NFS_RPC_DROP;
> >      memcpy(nfs_path, data, rlen);
> >      nfs_path[rlen] = 0;
> >
> >
> >
> > I would appreciate if the project could request a CVE identifier through
> > the appropriate CNA, crediting me as the reporter.
>
> Thanks for the report. Please see
> https://docs.u-boot.org/en/latest/develop/sending_patches.html for how
> to submit a patch we can apply. With respect to a CVE, that's up to the
> submitter to request, from whatever service they usually work with for
> one, currently.
>
> --
> Tom
>


-- 
Sebastián Alba