Question about potential buffer issue in nfs_request_mount() - seeking feedback

Question about potential buffer issue in nfs_request_mount() - seeking feedback

[SSH]

[-- Attachment #1.1: Type: text/plain, Size: 2775 bytes --]

Hi NFS maintainers,

I was looking at a kernel warning from 6.1-rc1 to understand it better and tried to trace through the code to understand what was happening. I think I may have found something, although now the most up-to-date kernel HEAD is August, 2025 and most of all, I'm not a kernel developer so I wanted to ask for your feedback on whether my analysis makes sense.

## Context
* This was on all NFS v3 TCP mounts
* The warning came from kernel's hardened memcpy detection
* The mount seemed to work despite the warning

### Additional Context
I noticed this warning was originally reported around 6.1-rc1 timeframe (~2022), but checking the current kernel source, it would appear that the same code pattern exists.
I'm not sure if this was previously reported to the NFS maintainers specifically, or if there's a reason it wasn't addressed. Either way, I thought it was worth bringing up again in case it got missed or deprioritized.

Source: https://lkml.org/lkml/2022/10/16/461

## The Original Warning
I saw this warning during NFS v3 TCP mount:

```
[ 19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
[ 19.617504] WARNING: CPU: 3 PID: 1300 at fs/nfs/super.c:857 nfs_request_mount.constprop.0.isra.0+0x1c0/0x1f0
```

## Likely Source of Failure

Looking at `nfs_request_mount()` in `fs/nfs/super.c`, I see this code:

```c
// Around line 850
struct nfs_mount_request request = {
.sap = &ctx->mount_server._address,
// ... other fields
};

// Later, around line 881
if (ctx->mount_server.address.sa_family == AF_UNSPEC) {
memcpy(request.sap, &ctx->nfs_server._address, ctx->nfs_server.addrlen);
ctx->mount_server.addrlen = ctx->nfs_server.addrlen;
}
```

My understanding is:
1. `request.sap` points to `ctx->mount_server._address`
2. We're copying from `ctx->nfs_server._address` (which could be 28 bytes for IPv6)
3. Into whatever `mount_server._address` points to (which might be smaller?)

The weird size value (18446744073709551615) in the warning makes me think there might be memory corruption happening.

Does this seem like a real issue? If so, would adding a size check before the memcpy make sense, something like:

```c
if (ctx->mount_server.address.sa_family == AF_UNSPEC) {
if (ctx->nfs_server.addrlen <= sizeof(ctx->mount_server._address)) {
memcpy(request.sap, &ctx->nfs_server._address, ctx->nfs_server.addrlen);
ctx->mount_server.addrlen = ctx->nfs_server.addrlen;
} else {
// handle error case; maybe -EINVAL?
return -EINVAL;
}
}
```

I could easily be misunderstanding something fundamental here, so please let me know if I'm off track. I just wanted to share this in case it's helpful.

Thanks for your time and for maintaining NFS!

Best regards, SSH

[-- Attachment #1.2: Type: text/html, Size: 5245 bytes --]

[-- Attachment #2: publickey - originalssh@pm.me - 0x69004F2D.asc --]
[-- Type: application/pgp-keys, Size: 832 bytes --]

Re: Question about potential buffer issue in nfs_request_mount() - seeking feedback

[Jeff Layton]

On Mon, 2025-09-01 at 01:38 +0000, SSH wrote:
> Hi NFS maintainers,
> 
> I was looking at a kernel warning from 6.1-rc1 to understand it better and tried to trace through the code to understand what was happening. I think I may have found something, although now the most up-to-date kernel HEAD is August, 2025 and most of all, I'm not a kernel developer so I wanted to ask for your feedback on whether my analysis makes sense.
> 
> ## Context
> * This was on all NFS v3 TCP mounts
> * The warning came from kernel's hardened memcpy detection
> * The mount seemed to work despite the warning
> 
> ### Additional Context
> I noticed this warning was originally reported around 6.1-rc1 timeframe (~2022), but checking the current kernel source, it would appear that the same code pattern exists.
> I'm not sure if this was previously reported to the NFS maintainers specifically, or if there's a reason it wasn't addressed. Either way, I thought it was worth bringing up again in case it got missed or deprioritized.
> 
> Source: https://lkml.org/lkml/2022/10/16/461
> 
> ## The Original Warning
> I saw this warning during NFS v3 TCP mount:
> 
> ```
> [   19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
> [   19.617504] WARNING: CPU: 3 PID: 1300 at fs/nfs/super.c:857 nfs_request_mount.constprop.0.isra.0+0x1c0/0x1f0
> ```
> 
> ## Likely Source of Failure
> 
> Looking at `nfs_request_mount()` in `fs/nfs/super.c`, I see this code:
> 
> ```c
> // Around line 850
> struct nfs_mount_request request = {
>     .sap = &ctx->mount_server._address,
>     // ... other fields
> };
> 
> // Later, around line 881
> if (ctx->mount_server.address.sa_family == AF_UNSPEC) {
>     memcpy(request.sap, &ctx->nfs_server._address, ctx->nfs_server.addrlen);
>     ctx->mount_server.addrlen = ctx->nfs_server.addrlen;
> }
> ```
> 
> My understanding is:
> 1. `request.sap` points to `ctx->mount_server._address`
> 2. We're copying from `ctx->nfs_server._address` (which could be 28 bytes for IPv6)
> 3. Into whatever `mount_server._address` points to (which might be smaller?)
> 
> The weird size value (18446744073709551615) in the warning makes me think there might be memory corruption happening.
> 
> Does this seem like a real issue? If so, would adding a size check before the memcpy make sense, something like:
> 
> ```c
> if (ctx->mount_server.address.sa_family == AF_UNSPEC) {
>     if (ctx->nfs_server.addrlen <= sizeof(ctx->mount_server._address)) {
>         memcpy(request.sap, &ctx->nfs_server._address, ctx->nfs_server.addrlen);
>         ctx->mount_server.addrlen = ctx->nfs_server.addrlen;
>     } else {
>         // handle error case; maybe -EINVAL?
>         return -EINVAL;
>     }
> }
> ```
> 
> I could easily be misunderstanding something fundamental here, so please let me know if I'm off track. I just wanted to share this in case it's helpful.
> 
> Thanks for your time and for maintaining NFS!
> 

(cc'ing Kees, our resident hardening expert)

FYI, that large size field is 0xffffffffffffffff (a 64-bit integer with
all bits set to 1). The doc header over __fortify_memcpy_chk()
definition is a little helpful, but the commit it refers to
(6f7630b1b5bc) has a bit more info.

It looks like that means that the size detection was broken for this
memcpy check? That commit mentions that this may be due to a GCC bug.

Kees, any thoughts?
-- 
Jeff Layton <jlayton@kernel.org>

Re: Question about potential buffer issue in nfs_request_mount() - seeking feedback

[Kees Cook]

On September 1, 2025 5:25:29 AM PDT, Jeff Layton <jlayton@kernel.org> wrote:
>On Mon, 2025-09-01 at 01:38 +0000, SSH wrote:
>> Hi NFS maintainers,
>> 
>> I was looking at a kernel warning from 6.1-rc1 to understand it better and tried to trace through the code to understand what was happening. I think I may have found something, although now the most up-to-date kernel HEAD is August, 2025 and most of all, I'm not a kernel developer so I wanted to ask for your feedback on whether my analysis makes sense.
>> 
>> ## Context
>> * This was on all NFS v3 TCP mounts
>> * The warning came from kernel's hardened memcpy detection
>> * The mount seemed to work despite the warning
>> 
>> ### Additional Context
>> I noticed this warning was originally reported around 6.1-rc1 timeframe (~2022), but checking the current kernel source, it would appear that the same code pattern exists.
>> I'm not sure if this was previously reported to the NFS maintainers specifically, or if there's a reason it wasn't addressed. Either way, I thought it was worth bringing up again in case it got missed or deprioritized.
>> 
>> Source: https://lkml.org/lkml/2022/10/16/461
>> 
>> ## The Original Warning
>> I saw this warning during NFS v3 TCP mount:
>> 
>> ```
>> [   19.617475] memcpy: detected field-spanning write (size 28) of single field "request.sap" at fs/nfs/super.c:857 (size 18446744073709551615)
>> [   19.617504] WARNING: CPU: 3 PID: 1300 at fs/nfs/super.c:857 nfs_request_mount.constprop.0.isra.0+0x1c0/0x1f0
>> ```
>> 
>> ## Likely Source of Failure
>> 
>> Looking at `nfs_request_mount()` in `fs/nfs/super.c`, I see this code:
>> 
>> ```c
>> // Around line 850
>> struct nfs_mount_request request = {
>>     .sap = &ctx->mount_server._address,
>>     // ... other fields
>> };
>> 
>> // Later, around line 881
>> if (ctx->mount_server.address.sa_family == AF_UNSPEC) {
>>     memcpy(request.sap, &ctx->nfs_server._address, ctx->nfs_server.addrlen);
>>     ctx->mount_server.addrlen = ctx->nfs_server.addrlen;
>> }
>> ```
>> 
>> My understanding is:
>> 1. `request.sap` points to `ctx->mount_server._address`
>> 2. We're copying from `ctx->nfs_server._address` (which could be 28 bytes for IPv6)
>> 3. Into whatever `mount_server._address` points to (which might be smaller?)
>> 
>> The weird size value (18446744073709551615) in the warning makes me think there might be memory corruption happening.
>> 
>> Does this seem like a real issue? If so, would adding a size check before the memcpy make sense, something like:
>> 
>> ```c
>> if (ctx->mount_server.address.sa_family == AF_UNSPEC) {
>>     if (ctx->nfs_server.addrlen <= sizeof(ctx->mount_server._address)) {
>>         memcpy(request.sap, &ctx->nfs_server._address, ctx->nfs_server.addrlen);
>>         ctx->mount_server.addrlen = ctx->nfs_server.addrlen;
>>     } else {
>>         // handle error case; maybe -EINVAL?
>>         return -EINVAL;
>>     }
>> }
>> ```
>> 
>> I could easily be misunderstanding something fundamental here, so please let me know if I'm off track. I just wanted to share this in case it's helpful.
>> 
>> Thanks for your time and for maintaining NFS!
>> 
>
>(cc'ing Kees, our resident hardening expert)
>
>FYI, that large size field is 0xffffffffffffffff (a 64-bit integer with
>all bits set to 1). The doc header over __fortify_memcpy_chk()
>definition is a little helpful, but the commit it refers to
>(6f7630b1b5bc) has a bit more info.
>
>It looks like that means that the size detection was broken for this
>memcpy check? That commit mentions that this may be due to a GCC bug.
>
>Kees, any thoughts?

Yup, the referenced commit in the comment is specifically fixing the above report (v6.1-rc1)

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/include/linux/fortify-string.h?id=6f7630b1b5bc672b54c1285ee6aba752b446672c


-- 
Kees Cook