[Bug 2150318] [NEW] NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3)

Public bug reported: Ubuntu Kernel - NFS Client - Regression in 6.8.0-110 Package linux (source) Component fs/nfs/client.c - nfs_server_copy_userdata() Guilty commit ae0cf4493dd3 - NFS: Fix inheritance of the block sizes when automounting Severity High - data write failure, EIO returned to applications Affects Ubuntu 24.04 LTS (Noble) - kernel 6.8.0-110+, kernel 6.17.x (HWE) Not affected Ubuntu 24.04 LTS kernel 6.8.0-107 and earlier Mitigated in Ubuntu 26.04 kernel 7.0 (retry on error, but root cause still present) Protocol NFSv4.1 and NFSv4.2 only (NFSv4.0 and NFSv3 not affected) Title NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3) Summary Commit ae0cf4493dd3 ("NFS: Fix inheritance of the block sizes when automounting"), backported in kernel 6.8.0-110.110, introduced a regression in nfs_server_copy_userdata() (fs/nfs/client.c). The patch made the copy of wsize/rsize conditional on NFS_AUTOMOUNT_INHERIT_WSIZE/RSIZE flags. These flags are only set when the user explicitly specifies wsize/rsize at mount time. When mounting with default options (the standard case), the session-negotiated wsize/rsize values (with COMPOUND overhead correctly subtracted by nfs4_session_limit_rwsize()) are no longer propagated. The client ends up using the raw ca_maxrequestsize value, generating oversized RPC WRITE requests that the server rejects with NFS4ERR_REQ_TOO_BIG. Impact Any application performing writes of 1 MiB or larger on an NFSv4.1/4.2 mount where the server's Write Transfer Max Size equals the negotiated wsize will experience data write failures (EIO on fsync). This affects dd, cp, rsync, and any application using large write buffers. The issue impacts any enterprise NAS platform where ca_maxrequestsize equals the maximum write payload (common with Dell PowerScale, NetApp ONTAP, and other platforms). Root cause analysis The guilty commit Commit: ae0cf4493dd3 Title: NFS: Fix inheritance of the block sizes when automounting File: fs/nfs/client.c Function: nfs_server_copy_userdata() Function BEFORE the regression (kernel 6.8.0-107, working) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->rsize = source->rsize; target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } wsize and rsize are always copied unconditionally. Values computed by nfs4_session_limit_rwsize() (subtracting nfs41_maxwrite_overhead from ca_maxrequestsize) are correctly propagated. Function AFTER the regression (kernel 6.8.0-110, broken) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_RSIZE) /* <-- BUG */ target->rsize = source->rsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_WSIZE) /* <-- BUG */ target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } Copy of wsize/rsize is now conditional on INHERIT flags. These flags are only set when the user explicitly passes wsize=/rsize= at mount time (ctx->wsize != 0). In the default mount case, the flags are never set and the negotiated values are silently dropped. Proposed fix (tested and validated) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; target->rsize = source->rsize; /* FIXED */ target->wsize = source->wsize; /* FIXED */ target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } Restores unconditional copy of wsize/rsize while keeping the new automount_inherit field and the conditional copy of bsize (the original intent of the commit). This fix was compiled as a replacement nfs.ko module, installed on a test machine running kernel 6.8.0-110-generic, and validated: wsize reverted from 1,048,576 to 1,047,532 and all write operations succeeded. The chain of events 1. Client mounts NFSv4.2 without explicit wsize (default behavior). 2. CREATE_SESSION negotiates ca_maxrequestsize = 1,048,576 bytes. 3. nfs4_session_limit_rwsize() correctly computes wsize = 1,048,576 - 1,044 = 1,047,532. 4. NFS_AUTOMOUNT_INHERIT_WSIZE is NOT set (ctx->wsize was 0). 5. nfs_server_copy_userdata() skips copying the negotiated wsize. 6. The server object ends up with wsize = 1,048,576 (raw ca_maxrequestsize). 7. WRITE RPC: 1,048,576 payload + ~1,044 overhead = ~1,049,620 bytes total. 8. Server rejects with NFS4ERR_REQ_TOO_BIG (RFC 8881 Section 18.36). 9. Client enters a retry loop, sequence IDs desynchronize, returns EIO. Why NFSv4.0 is not affected NFSv4.0 does not use sessions (no CREATE_SESSION, no ca_maxrequestsize, no nfs4_session_limit_rwsize()). Confirmed by testing: NFSv4.0 works correctly on all kernel versions. Note on kernel 7.0 (Ubuntu 26.04) behavior While kernel 7.0 does not exhibit the EIO failure, the underlying bug is still present. Kernel 7.0 negotiates the same incorrect wsize=1,048,576 (verified via nfsstat -m), and the server still rejects the oversized RPC with NFS4ERR_REQ_TOO_BIG (verified via tcpdump). The difference is that kernel 7.0 handles the error by reducing the write size and retrying. This approach has several drawbacks: Every first WRITE at 1 MiB is rejected by the server, generating unnecessary network round-trips and latency on every large write operation. The NFS4ERR_SEQ_MISORDERED errors following each rejection indicate sequence ID desynchronization, which impacts session slot efficiency. The retry mechanism masks the negotiation defect without eliminating it: the client systematically sends packets the server has to reject. On high-throughput workloads (backups, large file transfers), the cumulative cost of rejected-then-retried RPCs can impact performance. The proper fix is to restore correct wsize/rsize negotiation so that RPC WRITE requests never exceed ca_maxrequestsize in the first place. The retry handling in kernel 7.0 is a valuable defense-in-depth mechanism and should be backported to the Noble kernel series, but it should not be considered a substitute for fixing the negotiation logic. Bisection results Kernel bisection on the same machine, same NFS export, same default mount options. Only the kernel changed between reboots. Kernel Date wsize negotiated dd bs=1M Status 6.8.0-100 Feb 2026 1,047,532 OK OK 6.8.0-107 13 Mar 2026 1,047,532 OK Last good 6.8.0-110 19 Mar 2026 1,048,576 EIO First bad Git source confirmation: diff between tags Ubuntu-6.8.0-107.107 and Ubuntu-6.8.0-110.110 on git.launchpad.net confirms that commit ae0cf4493dd3 is the only change to fs/nfs/client.c affecting wsize/rsize handling. Full client test matrix OS Kernel wsize dd bs=1M Result Note Ubuntu 22.04 5.15.0-176 1,047,532 OK OK Reference Ubuntu 24.04 6.8.0-100 1,047,532 OK OK Ubuntu 24.04 6.8.0-107 1,047,532 OK OK Last good Ubuntu 24.04 6.8.0-110 1,048,576 EIO BUG First bad Ubuntu 24.04 6.8.0-110* 1,047,532 OK FIXED Patched nfs.ko Ubuntu 24.04 6.17.0-22 1,048,576 EIO BUG HWE Ubuntu 26.04 7.0 1,048,576 OK** Mitig. Retry masks bug * Patched nfs.ko with unconditional wsize/rsize copy restored in nfs_server_copy_userdata(). ** OK via retry after NFS4ERR_REQ_TOO_BIG. The negotiation bug is still present (wsize=1,048,576), only the error handling compensates. NFSv4.0: NOT affected (no sessions). NFSv3: NOT affected. Evidence tcpdump on kernel 6.8.0-110 (failing) 1222 2.970s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 2289 2.979s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 6622 3.015s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED [... 20+ repetitions, client never recovers, returns EIO ...] tcpdump on kernel 7.0 (mitigated, not fixed) 135 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 137 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED 296 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 298 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED Write completes after retry. Errors still occur on every large write. nfsstat -m comparison Kernel wsize rsize 5.15 / 6.8.0-107 1,047,532 (correct) 1,047,672 (correct) 6.8.0-110 1,048,576 (regression) 1,048,576 (regression) 6.8.0-110 patched 1,047,532 (fixed) 1,047,672 (fixed) 7.0 (26.04) 1,048,576 (still wrong) 1,048,576 (still wrong) Dichotomy tests - exact failure thresholds Kernel 6.8.0-110: bs (bytes) Result Note 1,044,480 (1020 KiB) OK Last passing 1,048,576 (1024 KiB) EIO = negotiated wsize Kernel 6.17.0-22 (HWE): bs (bytes) Result Note 1,048,328 OK Last passing 1,048,329 EIO First failing Delta on 6.17: 248 bytes (vs ~1,044 on working kernels). Suggests partial overhead subtraction, insufficient. Environment Parameter Value Server platform Dell PowerScale OneFS 9.7 Protocol NFSv4.2 (also reproduces on NFSv4.1) Write Transfer Max Size 1 MiB (1,048,576 bytes) Write Transfer Size (preferred) 512 KiB Write Transfer Multiple 512 bytes Client mount options Default (no explicit wsize/rsize) Workarounds Option 1 - Force wsize/rsize at mount time (recommended): mount -o vers=4.2,wsize=524288,rsize=524288 server:/export /mnt Sets the NFS_AUTOMOUNT_INHERIT_WSIZE flag, so the value is propagated. Configurable in /etc/fstab, autofs maps, or systemd mount units. Option 2 - Boot on kernel 6.8.0-107 or earlier: Not a long-term solution (missing security patches from -110+). Option 3 - Use NFSv4.0: Not affected (no sessions). Loses NFSv4.1+ features (sessions, trunking, pNFS). Requested action Two complementary fixes are recommended: 1. Fix the regression in nfs_server_copy_userdata(): restore the unconditional copy of wsize/rsize while keeping the conditional copy of bsize. The proposed fix has been compiled, tested, and validated on kernel 6.8.0-110-generic (see "Proposed fix" section above). 2. Backport the NFS4ERR_REQ_TOO_BIG retry logic from kernel 7.0 as defense-in-depth. This protects against future negotiation issues but should not be considered a substitute for correct negotiation, as it generates unnecessary rejected RPCs, sequence desynchronization, and added latency on every large write operation. Ubuntu 24.04 LTS is supported until 2029. This regression affects any NFSv4.1/4.2 deployment where the server's ca_maxrequestsize equals the maximum write payload size. Package versions linux-image-6.8.0-110-generic 6.8.0-110.110 (first bad) linux-image-6.8.0-107-generic 6.8.0-107.107 (last good) nfs-common 1:2.6.4-3ubuntu5.1 libnfsidmap1 1:2.6.4-3ubuntu5.1 libtirpc3t64 1.3.4+ds-1.1build1 rpcbind 1.2.6-7ubuntu2 Git source reference Repository: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble Tags compared: Ubuntu-6.8.0-107.107 .. Ubuntu-6.8.0-110.110 Guilty commit: ae0cf4493dd3 NFS: Fix inheritance of the block sizes when automounting Files changed: fs/nfs/client.c (nfs_init_server, nfs_server_copy_userdata) Related references Upstream commit 943cff67b842: "NFSv4.1: Fix the r/wsize checking" by Trond Myklebust. RFC 8881, Section 18.36: CREATE_SESSION - defines ca_maxrequestsize and NFS4ERR_REQ_TOO_BIG. ** Affects: linux (Ubuntu) Importance: Undecided Status: New ** Tags: kernel nfs regression-update ** Tags added: kernel nfs regression-update -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2150318 Title: NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3) Status in linux package in Ubuntu: New Bug description: Ubuntu Kernel - NFS Client - Regression in 6.8.0-110 Package linux (source) Component fs/nfs/client.c - nfs_server_copy_userdata() Guilty commit ae0cf4493dd3 - NFS: Fix inheritance of the block sizes when automounting Severity High - data write failure, EIO returned to applications Affects Ubuntu 24.04 LTS (Noble) - kernel 6.8.0-110+, kernel 6.17.x (HWE) Not affected Ubuntu 24.04 LTS kernel 6.8.0-107 and earlier Mitigated in Ubuntu 26.04 kernel 7.0 (retry on error, but root cause still present) Protocol NFSv4.1 and NFSv4.2 only (NFSv4.0 and NFSv3 not affected) Title NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3) Summary Commit ae0cf4493dd3 ("NFS: Fix inheritance of the block sizes when automounting"), backported in kernel 6.8.0-110.110, introduced a regression in nfs_server_copy_userdata() (fs/nfs/client.c). The patch made the copy of wsize/rsize conditional on NFS_AUTOMOUNT_INHERIT_WSIZE/RSIZE flags. These flags are only set when the user explicitly specifies wsize/rsize at mount time. When mounting with default options (the standard case), the session-negotiated wsize/rsize values (with COMPOUND overhead correctly subtracted by nfs4_session_limit_rwsize()) are no longer propagated. The client ends up using the raw ca_maxrequestsize value, generating oversized RPC WRITE requests that the server rejects with NFS4ERR_REQ_TOO_BIG. Impact Any application performing writes of 1 MiB or larger on an NFSv4.1/4.2 mount where the server's Write Transfer Max Size equals the negotiated wsize will experience data write failures (EIO on fsync). This affects dd, cp, rsync, and any application using large write buffers. The issue impacts any enterprise NAS platform where ca_maxrequestsize equals the maximum write payload (common with Dell PowerScale, NetApp ONTAP, and other platforms). Root cause analysis The guilty commit Commit: ae0cf4493dd3 Title: NFS: Fix inheritance of the block sizes when automounting File: fs/nfs/client.c Function: nfs_server_copy_userdata() Function BEFORE the regression (kernel 6.8.0-107, working) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->rsize = source->rsize; target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } wsize and rsize are always copied unconditionally. Values computed by nfs4_session_limit_rwsize() (subtracting nfs41_maxwrite_overhead from ca_maxrequestsize) are correctly propagated. Function AFTER the regression (kernel 6.8.0-110, broken) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_RSIZE) /* <-- BUG */ target->rsize = source->rsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_WSIZE) /* <-- BUG */ target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } Copy of wsize/rsize is now conditional on INHERIT flags. These flags are only set when the user explicitly passes wsize=/rsize= at mount time (ctx->wsize != 0). In the default mount case, the flags are never set and the negotiated values are silently dropped. Proposed fix (tested and validated) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; target->rsize = source->rsize; /* FIXED */ target->wsize = source->wsize; /* FIXED */ target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } Restores unconditional copy of wsize/rsize while keeping the new automount_inherit field and the conditional copy of bsize (the original intent of the commit). This fix was compiled as a replacement nfs.ko module, installed on a test machine running kernel 6.8.0-110-generic, and validated: wsize reverted from 1,048,576 to 1,047,532 and all write operations succeeded. The chain of events 1. Client mounts NFSv4.2 without explicit wsize (default behavior). 2. CREATE_SESSION negotiates ca_maxrequestsize = 1,048,576 bytes. 3. nfs4_session_limit_rwsize() correctly computes wsize = 1,048,576 - 1,044 = 1,047,532. 4. NFS_AUTOMOUNT_INHERIT_WSIZE is NOT set (ctx->wsize was 0). 5. nfs_server_copy_userdata() skips copying the negotiated wsize. 6. The server object ends up with wsize = 1,048,576 (raw ca_maxrequestsize). 7. WRITE RPC: 1,048,576 payload + ~1,044 overhead = ~1,049,620 bytes total. 8. Server rejects with NFS4ERR_REQ_TOO_BIG (RFC 8881 Section 18.36). 9. Client enters a retry loop, sequence IDs desynchronize, returns EIO. Why NFSv4.0 is not affected NFSv4.0 does not use sessions (no CREATE_SESSION, no ca_maxrequestsize, no nfs4_session_limit_rwsize()). Confirmed by testing: NFSv4.0 works correctly on all kernel versions. Note on kernel 7.0 (Ubuntu 26.04) behavior While kernel 7.0 does not exhibit the EIO failure, the underlying bug is still present. Kernel 7.0 negotiates the same incorrect wsize=1,048,576 (verified via nfsstat -m), and the server still rejects the oversized RPC with NFS4ERR_REQ_TOO_BIG (verified via tcpdump). The difference is that kernel 7.0 handles the error by reducing the write size and retrying. This approach has several drawbacks: Every first WRITE at 1 MiB is rejected by the server, generating unnecessary network round-trips and latency on every large write operation. The NFS4ERR_SEQ_MISORDERED errors following each rejection indicate sequence ID desynchronization, which impacts session slot efficiency. The retry mechanism masks the negotiation defect without eliminating it: the client systematically sends packets the server has to reject. On high-throughput workloads (backups, large file transfers), the cumulative cost of rejected-then-retried RPCs can impact performance. The proper fix is to restore correct wsize/rsize negotiation so that RPC WRITE requests never exceed ca_maxrequestsize in the first place. The retry handling in kernel 7.0 is a valuable defense-in-depth mechanism and should be backported to the Noble kernel series, but it should not be considered a substitute for fixing the negotiation logic. Bisection results Kernel bisection on the same machine, same NFS export, same default mount options. Only the kernel changed between reboots. Kernel Date wsize negotiated dd bs=1M Status 6.8.0-100 Feb 2026 1,047,532 OK OK 6.8.0-107 13 Mar 2026 1,047,532 OK Last good 6.8.0-110 19 Mar 2026 1,048,576 EIO First bad Git source confirmation: diff between tags Ubuntu-6.8.0-107.107 and Ubuntu-6.8.0-110.110 on git.launchpad.net confirms that commit ae0cf4493dd3 is the only change to fs/nfs/client.c affecting wsize/rsize handling. Full client test matrix OS Kernel wsize dd bs=1M Result Note Ubuntu 22.04 5.15.0-176 1,047,532 OK OK Reference Ubuntu 24.04 6.8.0-100 1,047,532 OK OK Ubuntu 24.04 6.8.0-107 1,047,532 OK OK Last good Ubuntu 24.04 6.8.0-110 1,048,576 EIO BUG First bad Ubuntu 24.04 6.8.0-110* 1,047,532 OK FIXED Patched nfs.ko Ubuntu 24.04 6.17.0-22 1,048,576 EIO BUG HWE Ubuntu 26.04 7.0 1,048,576 OK** Mitig. Retry masks bug * Patched nfs.ko with unconditional wsize/rsize copy restored in nfs_server_copy_userdata(). ** OK via retry after NFS4ERR_REQ_TOO_BIG. The negotiation bug is still present (wsize=1,048,576), only the error handling compensates. NFSv4.0: NOT affected (no sessions). NFSv3: NOT affected. Evidence tcpdump on kernel 6.8.0-110 (failing) 1222 2.970s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 2289 2.979s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 6622 3.015s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED [... 20+ repetitions, client never recovers, returns EIO ...] tcpdump on kernel 7.0 (mitigated, not fixed) 135 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 137 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED 296 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 298 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED Write completes after retry. Errors still occur on every large write. nfsstat -m comparison Kernel wsize rsize 5.15 / 6.8.0-107 1,047,532 (correct) 1,047,672 (correct) 6.8.0-110 1,048,576 (regression) 1,048,576 (regression) 6.8.0-110 patched 1,047,532 (fixed) 1,047,672 (fixed) 7.0 (26.04) 1,048,576 (still wrong) 1,048,576 (still wrong) Dichotomy tests - exact failure thresholds Kernel 6.8.0-110: bs (bytes) Result Note 1,044,480 (1020 KiB) OK Last passing 1,048,576 (1024 KiB) EIO = negotiated wsize Kernel 6.17.0-22 (HWE): bs (bytes) Result Note 1,048,328 OK Last passing 1,048,329 EIO First failing Delta on 6.17: 248 bytes (vs ~1,044 on working kernels). Suggests partial overhead subtraction, insufficient. Environment Parameter Value Server platform Dell PowerScale OneFS 9.7 Protocol NFSv4.2 (also reproduces on NFSv4.1) Write Transfer Max Size 1 MiB (1,048,576 bytes) Write Transfer Size (preferred) 512 KiB Write Transfer Multiple 512 bytes Client mount options Default (no explicit wsize/rsize) Workarounds Option 1 - Force wsize/rsize at mount time (recommended): mount -o vers=4.2,wsize=524288,rsize=524288 server:/export /mnt Sets the NFS_AUTOMOUNT_INHERIT_WSIZE flag, so the value is propagated. Configurable in /etc/fstab, autofs maps, or systemd mount units. Option 2 - Boot on kernel 6.8.0-107 or earlier: Not a long-term solution (missing security patches from -110+). Option 3 - Use NFSv4.0: Not affected (no sessions). Loses NFSv4.1+ features (sessions, trunking, pNFS). Requested action Two complementary fixes are recommended: 1. Fix the regression in nfs_server_copy_userdata(): restore the unconditional copy of wsize/rsize while keeping the conditional copy of bsize. The proposed fix has been compiled, tested, and validated on kernel 6.8.0-110-generic (see "Proposed fix" section above). 2. Backport the NFS4ERR_REQ_TOO_BIG retry logic from kernel 7.0 as defense-in-depth. This protects against future negotiation issues but should not be considered a substitute for correct negotiation, as it generates unnecessary rejected RPCs, sequence desynchronization, and added latency on every large write operation. Ubuntu 24.04 LTS is supported until 2029. This regression affects any NFSv4.1/4.2 deployment where the server's ca_maxrequestsize equals the maximum write payload size. Package versions linux-image-6.8.0-110-generic 6.8.0-110.110 (first bad) linux-image-6.8.0-107-generic 6.8.0-107.107 (last good) nfs-common 1:2.6.4-3ubuntu5.1 libnfsidmap1 1:2.6.4-3ubuntu5.1 libtirpc3t64 1.3.4+ds-1.1build1 rpcbind 1.2.6-7ubuntu2 Git source reference Repository: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble Tags compared: Ubuntu-6.8.0-107.107 .. Ubuntu-6.8.0-110.110 Guilty commit: ae0cf4493dd3 NFS: Fix inheritance of the block sizes when automounting Files changed: fs/nfs/client.c (nfs_init_server, nfs_server_copy_userdata) Related references Upstream commit 943cff67b842: "NFSv4.1: Fix the r/wsize checking" by Trond Myklebust. RFC 8881, Section 18.36: CREATE_SESSION - defines ca_maxrequestsize and NFS4ERR_REQ_TOO_BIG. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150318/+subscriptions

[Bug 990368] Re: CVE-2012-2133

The task "linux-lts-saucy (Ubuntu)" has expired because it has had no new comments or updates for more than three years. If this issue is still present in an Ubuntu LTS kernel still under active support, please reopen the bug and provide updated details. If this issue was reported against an Ubuntu kernel no longer under active support but the issue still exists in a currently supported Ubuntu kernel, please open a new bug against that kernel version and provide the updated details, with a reference link to the original bug. This action was performed by an automated process maintained by the Ubuntu Kernel Team. ** Tags added: kernel-autoclosed kernel-autoclosed-expired ** Changed in: linux-lts-saucy (Ubuntu) Status: New => Expired -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/990368 Title: CVE-2012-2133 Status in linux package in Ubuntu: Invalid Status in linux-armadaxp package in Ubuntu: Invalid Status in linux-ec2 package in Ubuntu: Invalid Status in linux-flo package in Ubuntu: Invalid Status in linux-fsl-imx51 package in Ubuntu: Invalid Status in linux-goldfish package in Ubuntu: Invalid Status in linux-lts-backport-maverick package in Ubuntu: Invalid Status in linux-lts-backport-natty package in Ubuntu: Invalid Status in linux-lts-backport-oneiric package in Ubuntu: Invalid Status in linux-lts-quantal package in Ubuntu: Invalid Status in linux-lts-raring package in Ubuntu: Invalid Status in linux-lts-saucy package in Ubuntu: Expired Status in linux-lts-trusty package in Ubuntu: Invalid Status in linux-lts-utopic package in Ubuntu: Invalid Status in linux-lts-vivid package in Ubuntu: Invalid Status in linux-lts-wily package in Ubuntu: Invalid Status in linux-lts-xenial package in Ubuntu: Invalid Status in linux-mako package in Ubuntu: Invalid Status in linux-manta package in Ubuntu: Invalid Status in linux-mvl-dove package in Ubuntu: Invalid Status in linux-raspi2 package in Ubuntu: Fix Committed Status in linux-snapdragon package in Ubuntu: Expired Status in linux-ti-omap4 package in Ubuntu: Invalid Status in linux-lts-backport-maverick source package in Lucid: Invalid Status in linux-lts-backport-natty source package in Lucid: Fix Released Status in linux-lts-backport-oneiric source package in Lucid: Fix Released Status in linux-lts-backport-maverick source package in Oneiric: Invalid Status in linux-lts-backport-natty source package in Oneiric: Invalid Status in linux-lts-backport-oneiric source package in Oneiric: Invalid Status in linux source package in Precise: Fix Released Status in linux-armadaxp source package in Precise: Fix Released Status in linux-ec2 source package in Precise: Invalid Status in linux-flo source package in Precise: Invalid Status in linux-fsl-imx51 source package in Precise: Invalid Status in linux-goldfish source package in Precise: Invalid Status in linux-lts-backport-maverick source package in Precise: Invalid Status in linux-lts-backport-natty source package in Precise: Invalid Status in linux-lts-backport-oneiric source package in Precise: Invalid Status in linux-lts-quantal source package in Precise: Invalid Status in linux-lts-raring source package in Precise: Invalid Status in linux-lts-saucy source package in Precise: Won't Fix Status in linux-lts-trusty source package in Precise: Invalid Status in linux-lts-utopic source package in Precise: Invalid Status in linux-lts-vivid source package in Precise: Invalid Status in linux-lts-wily source package in Precise: Invalid Status in linux-lts-xenial source package in Precise: Invalid Status in linux-mako source package in Precise: Invalid Status in linux-manta source package in Precise: Invalid Status in linux-mvl-dove source package in Precise: Invalid Status in linux-raspi2 source package in Precise: Invalid Status in linux-snapdragon source package in Precise: Invalid Status in linux-ti-omap4 source package in Precise: Fix Released Status in linux-lts-backport-maverick source package in Quantal: Invalid Status in linux-lts-backport-natty source package in Quantal: Invalid Status in linux-lts-backport-oneiric source package in Quantal: Invalid Status in linux-lts-backport-maverick source package in Raring: Invalid Status in linux-lts-backport-natty source package in Raring: Invalid Status in linux-lts-backport-oneiric source package in Raring: Invalid Status in linux-lts-backport-maverick source package in Saucy: Invalid Status in linux-lts-backport-natty source package in Saucy: Invalid Status in linux-lts-backport-oneiric source package in Saucy: Invalid Status in linux source package in Trusty: Invalid Status in linux-armadaxp source package in Trusty: Invalid Status in linux-ec2 source package in Trusty: Invalid Status in linux-flo source package in Trusty: Invalid Status in linux-fsl-imx51 source package in Trusty: Invalid Status in linux-goldfish source package in Trusty: Invalid Status in linux-lts-backport-maverick source package in Trusty: Invalid Status in linux-lts-backport-natty source package in Trusty: Invalid Status in linux-lts-backport-oneiric source package in Trusty: Invalid Status in linux-lts-quantal source package in Trusty: Invalid Status in linux-lts-raring source package in Trusty: Invalid Status in linux-lts-saucy source package in Trusty: Expired Status in linux-lts-trusty source package in Trusty: Invalid Status in linux-lts-utopic source package in Trusty: Invalid Status in linux-lts-vivid source package in Trusty: Fix Committed Status in linux-lts-wily source package in Trusty: Invalid Status in linux-lts-xenial source package in Trusty: Fix Committed Status in linux-mako source package in Trusty: Invalid Status in linux-manta source package in Trusty: Invalid Status in linux-mvl-dove source package in Trusty: Invalid Status in linux-raspi2 source package in Trusty: Invalid Status in linux-snapdragon source package in Trusty: Invalid Status in linux-ti-omap4 source package in Trusty: Invalid Status in linux-lts-backport-maverick source package in Utopic: Invalid Status in linux-lts-backport-natty source package in Utopic: Invalid Status in linux-lts-backport-oneiric source package in Utopic: Invalid Status in linux source package in Vivid: Invalid Status in linux-armadaxp source package in Vivid: Invalid Status in linux-ec2 source package in Vivid: Invalid Status in linux-flo source package in Vivid: Invalid Status in linux-fsl-imx51 source package in Vivid: Invalid Status in linux-goldfish source package in Vivid: Invalid Status in linux-lts-backport-maverick source package in Vivid: Invalid Status in linux-lts-backport-natty source package in Vivid: Invalid Status in linux-lts-backport-oneiric source package in Vivid: Invalid Status in linux-lts-quantal source package in Vivid: Invalid Status in linux-lts-raring source package in Vivid: Invalid Status in linux-lts-saucy source package in Vivid: Won't Fix Status in linux-lts-trusty source package in Vivid: Invalid Status in linux-lts-utopic source package in Vivid: Invalid Status in linux-lts-vivid source package in Vivid: Invalid Status in linux-lts-wily source package in Vivid: Invalid Status in linux-lts-xenial source package in Vivid: Won't Fix Status in linux-mako source package in Vivid: Invalid Status in linux-manta source package in Vivid: Invalid Status in linux-mvl-dove source package in Vivid: Invalid Status in linux-raspi2 source package in Vivid: Invalid Status in linux-snapdragon source package in Vivid: Won't Fix Status in linux-ti-omap4 source package in Vivid: Invalid Status in linux source package in Wily: Invalid Status in linux-armadaxp source package in Wily: Invalid Status in linux-ec2 source package in Wily: Invalid Status in linux-flo source package in Wily: Invalid Status in linux-fsl-imx51 source package in Wily: Invalid Status in linux-goldfish source package in Wily: Invalid Status in linux-lts-backport-maverick source package in Wily: Invalid Status in linux-lts-backport-natty source package in Wily: Invalid Status in linux-lts-backport-oneiric source package in Wily: Invalid Status in linux-lts-quantal source package in Wily: Invalid Status in linux-lts-raring source package in Wily: Invalid Status in linux-lts-saucy source package in Wily: Won't Fix Status in linux-lts-trusty source package in Wily: Invalid Status in linux-lts-utopic source package in Wily: Invalid Status in linux-lts-vivid source package in Wily: Invalid Status in linux-lts-wily source package in Wily: Invalid Status in linux-lts-xenial source package in Wily: Invalid Status in linux-mako source package in Wily: Invalid Status in linux-manta source package in Wily: Invalid Status in linux-mvl-dove source package in Wily: Invalid Status in linux-raspi2 source package in Wily: Invalid Status in linux-snapdragon source package in Wily: Invalid Status in linux-ti-omap4 source package in Wily: Invalid Status in linux source package in Xenial: Invalid Status in linux-armadaxp source package in Xenial: Invalid Status in linux-ec2 source package in Xenial: Invalid Status in linux-flo source package in Xenial: Invalid Status in linux-fsl-imx51 source package in Xenial: Invalid Status in linux-goldfish source package in Xenial: Invalid Status in linux-lts-backport-maverick source package in Xenial: Invalid Status in linux-lts-backport-natty source package in Xenial: Invalid Status in linux-lts-backport-oneiric source package in Xenial: Invalid Status in linux-lts-quantal source package in Xenial: Invalid Status in linux-lts-raring source package in Xenial: Invalid Status in linux-lts-saucy source package in Xenial: Expired Status in linux-lts-trusty source package in Xenial: Invalid Status in linux-lts-utopic source package in Xenial: Invalid Status in linux-lts-vivid source package in Xenial: Invalid Status in linux-lts-wily source package in Xenial: Invalid Status in linux-lts-xenial source package in Xenial: Invalid Status in linux-mako source package in Xenial: Invalid Status in linux-manta source package in Xenial: Invalid Status in linux-mvl-dove source package in Xenial: Invalid Status in linux-raspi2 source package in Xenial: Fix Committed Status in linux-snapdragon source package in Xenial: Invalid Status in linux-ti-omap4 source package in Xenial: Invalid Status in linux-lts-backport-maverick source package in Hardy: Invalid Status in linux-lts-backport-natty source package in Hardy: Invalid Status in linux-lts-backport-oneiric source package in Hardy: Invalid Bug description: Use-after-free vulnerability in the Linux kernel before 3.3.6, when huge pages are enabled, allows local users to cause a denial of service (system crash) or possibly gain privileges by interacting with a hugetlbfs filesystem, as demonstrated by a umount operation that triggers improper handling of quota data. Break-Fix: - 90481622d75715bfcb68501280a917dbfe516029 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/990368/+subscriptions

[Bug 1202992] Re: CVE-2013-4127

The task "linux-lts-xenial (Ubuntu Vivid)" has been closed automatically because it was filed against an Ubuntu release that is now end-of-life. If this issue is still present in a supported Ubuntu kernel, please open a new bug and provide updated details. This action was performed by an automated process maintained by the Ubuntu Kernel Team. ** Changed in: linux-lts-xenial (Ubuntu Vivid) Status: New => Won't Fix -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1202992 Title: CVE-2013-4127 Status in linux package in Ubuntu: Invalid Status in linux-armadaxp package in Ubuntu: Invalid Status in linux-ec2 package in Ubuntu: Invalid Status in linux-flo package in Ubuntu: Invalid Status in linux-fsl-imx51 package in Ubuntu: Invalid Status in linux-goldfish package in Ubuntu: Invalid Status in linux-lts-backport-maverick package in Ubuntu: Won't Fix Status in linux-lts-backport-natty package in Ubuntu: Won't Fix Status in linux-lts-quantal package in Ubuntu: Invalid Status in linux-lts-raring package in Ubuntu: Invalid Status in linux-lts-saucy package in Ubuntu: Expired Status in linux-lts-trusty package in Ubuntu: Invalid Status in linux-lts-utopic package in Ubuntu: Invalid Status in linux-lts-vivid package in Ubuntu: Invalid Status in linux-lts-wily package in Ubuntu: Invalid Status in linux-lts-xenial package in Ubuntu: Invalid Status in linux-mako package in Ubuntu: Invalid Status in linux-manta package in Ubuntu: Invalid Status in linux-mvl-dove package in Ubuntu: Invalid Status in linux-raspi2 package in Ubuntu: Fix Committed Status in linux-ti-omap4 package in Ubuntu: Invalid Status in linux-lts-backport-maverick source package in Lucid: Won't Fix Status in linux-lts-backport-natty source package in Lucid: Won't Fix Status in linux source package in Precise: Invalid Status in linux-armadaxp source package in Precise: Invalid Status in linux-ec2 source package in Precise: Invalid Status in linux-flo source package in Precise: Invalid Status in linux-fsl-imx51 source package in Precise: Invalid Status in linux-goldfish source package in Precise: Invalid Status in linux-lts-backport-maverick source package in Precise: Won't Fix Status in linux-lts-backport-natty source package in Precise: Won't Fix Status in linux-lts-quantal source package in Precise: Invalid Status in linux-lts-raring source package in Precise: Fix Released Status in linux-lts-saucy source package in Precise: Won't Fix Status in linux-lts-trusty source package in Precise: Invalid Status in linux-lts-utopic source package in Precise: Invalid Status in linux-lts-vivid source package in Precise: Invalid Status in linux-lts-wily source package in Precise: Invalid Status in linux-lts-xenial source package in Precise: Invalid Status in linux-mako source package in Precise: Invalid Status in linux-manta source package in Precise: Invalid Status in linux-mvl-dove source package in Precise: Invalid Status in linux-raspi2 source package in Precise: Invalid Status in linux-ti-omap4 source package in Precise: Invalid Status in linux-lts-backport-maverick source package in Quantal: Won't Fix Status in linux-lts-backport-natty source package in Quantal: Won't Fix Status in linux-lts-backport-maverick source package in Raring: Won't Fix Status in linux-lts-backport-natty source package in Raring: Won't Fix Status in linux-lts-backport-maverick source package in Saucy: Won't Fix Status in linux-lts-backport-natty source package in Saucy: Won't Fix Status in linux source package in Trusty: Invalid Status in linux-armadaxp source package in Trusty: Invalid Status in linux-ec2 source package in Trusty: Invalid Status in linux-flo source package in Trusty: Invalid Status in linux-fsl-imx51 source package in Trusty: Invalid Status in linux-goldfish source package in Trusty: Invalid Status in linux-lts-backport-maverick source package in Trusty: New Status in linux-lts-backport-natty source package in Trusty: New Status in linux-lts-quantal source package in Trusty: Invalid Status in linux-lts-raring source package in Trusty: Invalid Status in linux-lts-saucy source package in Trusty: Expired Status in linux-lts-trusty source package in Trusty: Invalid Status in linux-lts-utopic source package in Trusty: Invalid Status in linux-lts-vivid source package in Trusty: Fix Committed Status in linux-lts-wily source package in Trusty: Invalid Status in linux-lts-xenial source package in Trusty: Fix Committed Status in linux-mako source package in Trusty: Invalid Status in linux-manta source package in Trusty: Invalid Status in linux-mvl-dove source package in Trusty: Invalid Status in linux-raspi2 source package in Trusty: Invalid Status in linux-ti-omap4 source package in Trusty: Invalid Status in linux-lts-backport-maverick source package in Utopic: Won't Fix Status in linux-lts-backport-natty source package in Utopic: Won't Fix Status in linux source package in Vivid: Invalid Status in linux-armadaxp source package in Vivid: Invalid Status in linux-ec2 source package in Vivid: Invalid Status in linux-flo source package in Vivid: Invalid Status in linux-fsl-imx51 source package in Vivid: Invalid Status in linux-goldfish source package in Vivid: Invalid Status in linux-lts-backport-maverick source package in Vivid: New Status in linux-lts-backport-natty source package in Vivid: New Status in linux-lts-quantal source package in Vivid: Invalid Status in linux-lts-raring source package in Vivid: Invalid Status in linux-lts-saucy source package in Vivid: Won't Fix Status in linux-lts-trusty source package in Vivid: Invalid Status in linux-lts-utopic source package in Vivid: Invalid Status in linux-lts-vivid source package in Vivid: Invalid Status in linux-lts-wily source package in Vivid: Invalid Status in linux-lts-xenial source package in Vivid: Won't Fix Status in linux-mako source package in Vivid: Invalid Status in linux-manta source package in Vivid: Invalid Status in linux-mvl-dove source package in Vivid: Invalid Status in linux-raspi2 source package in Vivid: Invalid Status in linux-ti-omap4 source package in Vivid: Invalid Status in linux source package in Wily: Invalid Status in linux-armadaxp source package in Wily: Invalid Status in linux-ec2 source package in Wily: Invalid Status in linux-flo source package in Wily: Invalid Status in linux-fsl-imx51 source package in Wily: Invalid Status in linux-goldfish source package in Wily: Invalid Status in linux-lts-backport-maverick source package in Wily: Won't Fix Status in linux-lts-backport-natty source package in Wily: Won't Fix Status in linux-lts-quantal source package in Wily: Invalid Status in linux-lts-raring source package in Wily: Invalid Status in linux-lts-saucy source package in Wily: Won't Fix Status in linux-lts-trusty source package in Wily: Invalid Status in linux-lts-utopic source package in Wily: Invalid Status in linux-lts-vivid source package in Wily: Invalid Status in linux-lts-wily source package in Wily: Invalid Status in linux-lts-xenial source package in Wily: Invalid Status in linux-mako source package in Wily: Invalid Status in linux-manta source package in Wily: Invalid Status in linux-mvl-dove source package in Wily: Invalid Status in linux-raspi2 source package in Wily: Invalid Status in linux-ti-omap4 source package in Wily: Invalid Status in linux source package in Xenial: Invalid Status in linux-armadaxp source package in Xenial: Invalid Status in linux-ec2 source package in Xenial: Invalid Status in linux-flo source package in Xenial: Invalid Status in linux-fsl-imx51 source package in Xenial: Invalid Status in linux-goldfish source package in Xenial: Invalid Status in linux-lts-backport-maverick source package in Xenial: Won't Fix Status in linux-lts-backport-natty source package in Xenial: Won't Fix Status in linux-lts-quantal source package in Xenial: Invalid Status in linux-lts-raring source package in Xenial: Invalid Status in linux-lts-saucy source package in Xenial: Expired Status in linux-lts-trusty source package in Xenial: Invalid Status in linux-lts-utopic source package in Xenial: Invalid Status in linux-lts-vivid source package in Xenial: Invalid Status in linux-lts-wily source package in Xenial: Invalid Status in linux-lts-xenial source package in Xenial: Invalid Status in linux-mako source package in Xenial: Invalid Status in linux-manta source package in Xenial: Invalid Status in linux-mvl-dove source package in Xenial: Invalid Status in linux-raspi2 source package in Xenial: Fix Committed Status in linux-ti-omap4 source package in Xenial: Invalid Bug description: Use-after-free vulnerability in the vhost_net_set_backend function in drivers/vhost/net.c in the Linux kernel through 3.10.3 allows local users to cause a denial of service (OOPS and system crash) via vectors involving powering on a virtual machine. Break-Fix: 1280c27f8e29acf4af2da914e80ec27c3dbd5c01 dd7633ecd553a5e304d349aa6f8eb8a0417098c5 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1202992/+subscriptions

[Bug 2149872] Re: iptables connlimit traffic loss

Thanks for that info! Here's another test kernel, this time with only de8a70cefcb26cdceaafdc5ac144712681419c29 added to Noble generic. https://people.canonical.com/~tswhison/bugs/2149872/noble2.tar.gz Best, Tim -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2149872 Title: iptables connlimit traffic loss Status in linux package in Ubuntu: New Bug description: There seems to be a bug related to the iptables connlimit module in the latest Ubuntu 24.04.4 LTS kernel 6.8.0-110. I use the following iptables rule to limit the connections per IPv4 address to a webserver: iptables -I INPUT -p tcp --syn -m multiport --dports 80,443 -m connlimit --connlimit-above 200 -j DROP With this firewall rule installed, network traffic to the webserver is randomly dropped or delayed despite being well below the intended connection limit. It seems that the localhost address range is particularly affected, the first request from a local IP usually works, follwing requests are dropped or delayed. The problem also occurs if I choose ACCEPT instead of DROP as the target: iptables -I INPUT -p tcp --syn -m multiport --dports 80,443 -m connlimit --connlimit-above 200 -j ACCEPT The problem also occurs with the latest Ubuntu 24.04 proposed kernel 6.8.0-114, it does not occur with the previous kernel 6.8.0-107. It also occurs with Ubuntu 22.04.5 LTS kernel 5.15.0-174 and 5.15.0-176, I have not tested other kernel versions. This issue could be related to recent changes in the netfilter code regarding CVE-2026-23111. --- ProblemType: Bug ApportVersion: 2.28.1-0ubuntu3.8 Architecture: amd64 AudioDevicesInUse: USER PID ACCESS COMMAND /dev/snd/seq: tobias 1694 F.... pipewire CRDA: N/A CasperMD5CheckResult: unknown CurrentDesktop: KDE DistroRelease: Ubuntu 24.04 HibernationDevice: RESUME=UUID=eaf0df5b-1533-4971-a82f-5efb004bff46 InstallationDate: Installed on 2012-10-10 (4944 days ago) InstallationMedia: Kubuntu 12.04.1 LTS "Precise Pangolin" - Release amd64 (20120820.1) IwConfig: lo no wireless extensions. eth0 no wireless extensions. virbr0 no wireless extensions. Lsusb: Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub Bus 001 Device 002: ID 80ee:0021 VirtualBox USB Tablet Lsusb-t: /: Bus 001.Port 001: Dev 001, Class=root_hub, Driver=ohci-pci/12p, 12M |__ Port 001: Dev 002, If 0, Class=Human Interface Device, Driver=usbhid, 12M MachineType: innotek GmbH VirtualBox Package: linux (not installed) ProcFB: 0 vmwgfxdrmfb ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-6.8.0-114-generic root=UUID=d9d0da57-a29f-4c02-a10b-9aea6411bc6b ro noplymouth ProcVersionSignature: Ubuntu 6.8.0-114.114-generic 6.8.12 PulseList: Error: command ['pacmd', 'list'] failed with exit code 1: No PulseAudio daemon running, or not running as session daemon. RelatedPackageVersions: linux-restricted-modules-6.8.0-114-generic N/A linux-backports-modules-6.8.0-114-generic N/A linux-firmware 20240318.git3b128b60-0ubuntu2.26 RfKill: Tags: noble Uname: Linux 6.8.0-114-generic x86_64 UpgradeStatus: Upgraded to noble on 2025-01-05 (474 days ago) UserGroups: adm cdrom dip libvirt libvirtd lpadmin plugdev sambashare sudo _MarkForUpload: True dmi.bios.date: 12/01/2006 dmi.bios.vendor: innotek GmbH dmi.bios.version: VirtualBox dmi.board.name: VirtualBox dmi.board.vendor: Oracle Corporation dmi.board.version: 1.2 dmi.chassis.type: 1 dmi.chassis.vendor: Oracle Corporation dmi.modalias: dmi:bvninnotekGmbH:bvrVirtualBox:bd12/01/2006:svninnotekGmbH:pnVirtualBox:pvr1.2:rvnOracleCorporation:rnVirtualBox:rvr1.2:cvnOracleCorporation:ct1:cvr:sku: dmi.product.family: Virtual Machine dmi.product.name: VirtualBox dmi.product.version: 1.2 dmi.sys.vendor: innotek GmbH To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2149872/+subscriptions

[Bug 2150318] Re: NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3)

Related upstream bug: Debian Bug#1128834: https://bugs.debian.org/1128834 Same root cause, same commit, confirmed on Debian Bookworm kernel 6.1.162 with Dell EMC Isilon/PowerScale NFSv4.2. Trond Myklebust (NFS maintainer) responded on 2026-03-14. ** Bug watch added: Debian Bug tracker #1128834 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1128834 -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2150318 Title: NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3) Status in linux package in Ubuntu: New Bug description: NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3) ================================================================================================= Package: linux (source) Component: fs/nfs/client.c - nfs_server_copy_userdata() Guilty commit: ae0cf4493dd3 - NFS: Fix inheritance of the block sizes when automounting Severity: High - data write failure, EIO returned to applications Affects: Ubuntu 24.04 LTS (Noble) - kernel 6.8.0-110+, kernel 6.17.x (HWE) Not affected: Ubuntu 24.04 LTS kernel 6.8.0-107 and earlier Mitigated in: Ubuntu 26.04 kernel 7.0 (retry on error, but root cause still present) Protocol: NFSv4.1 and NFSv4.2 only (NFSv4.0 and NFSv3 not affected) Impact: Identified on over 100 production Ubuntu 24.04 LTS workstations in an enterprise environment SUMMARY ------- Commit ae0cf4493dd3 ("NFS: Fix inheritance of the block sizes when automounting"), backported in kernel 6.8.0-110.110, introduced a regression in nfs_server_copy_userdata() (fs/nfs/client.c). The patch made the copy of wsize/rsize conditional on NFS_AUTOMOUNT_INHERIT_WSIZE/RSIZE flags. These flags are only set when the user explicitly specifies wsize/rsize at mount time. When mounting with default options (the standard case), the session-negotiated wsize/rsize values (with COMPOUND overhead correctly subtracted by nfs4_session_limit_rwsize()) are no longer propagated. The client ends up using the raw ca_maxrequestsize value, generating oversized RPC WRITE requests that the server rejects with NFS4ERR_REQ_TOO_BIG. IMPACT ------ Any application performing writes of 1 MiB or larger on an NFSv4.1/4.2 mount where the server's Write Transfer Max Size equals the negotiated wsize will experience data write failures (EIO on fsync). This affects dd, cp, rsync, and any application using large write buffers. The issue impacts any enterprise NAS platform where ca_maxrequestsize equals the maximum write payload (common with Dell PowerScale, NetApp ONTAP, and other platforms). ROOT CAUSE ANALYSIS ------------------- ### The guilty commit Commit: ae0cf4493dd3 Title: NFS: Fix inheritance of the block sizes when automounting File: fs/nfs/client.c Function: nfs_server_copy_userdata() ### Function BEFORE the regression (kernel 6.8.0-107, working) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->rsize = source->rsize; target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } wsize and rsize are always copied unconditionally. Values computed by nfs4_session_limit_rwsize() (subtracting nfs41_maxwrite_overhead from ca_maxrequestsize) are correctly propagated. ### Function AFTER the regression (kernel 6.8.0-110, broken) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_RSIZE) /* <-- BUG */ target->rsize = source->rsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_WSIZE) /* <-- BUG */ target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } Copy of wsize/rsize is now conditional on INHERIT flags. These flags are only set when the user explicitly passes wsize=/rsize= at mount time (ctx->wsize != 0). In the default mount case, the flags are never set and the negotiated values are silently dropped. ### Proposed fix (tested and validated) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; target->rsize = source->rsize; /* FIXED */ target->wsize = source->wsize; /* FIXED */ target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } Restores unconditional copy of wsize/rsize while keeping the new automount_inherit field and the conditional copy of bsize (the original intent of the commit). This fix was compiled as a replacement nfs.ko module, installed on a test machine running kernel 6.8.0-110-generic, and validated: wsize reverted from 1,048,576 to 1,047,532 and all write operations succeeded. ### The chain of events 1. Client mounts NFSv4.2 without explicit wsize (default behavior). 2. CREATE_SESSION negotiates ca_maxrequestsize = 1,048,576 bytes. 3. nfs4_session_limit_rwsize() correctly computes wsize = 1,048,576 - 1,044 = 1,047,532. 4. NFS_AUTOMOUNT_INHERIT_WSIZE is NOT set (ctx->wsize was 0). 5. nfs_server_copy_userdata() skips copying the negotiated wsize. 6. The server object ends up with wsize = 1,048,576 (raw ca_maxrequestsize). 7. WRITE RPC: 1,048,576 payload + ~1,044 overhead = ~1,049,620 bytes total. 8. Server rejects with NFS4ERR_REQ_TOO_BIG (RFC 8881 Section 18.36). 9. Client enters a retry loop, sequence IDs desynchronize, returns EIO. ### Why NFSv4.0 is not affected NFSv4.0 does not use sessions (no CREATE_SESSION, no ca_maxrequestsize, no nfs4_session_limit_rwsize()). Confirmed by testing: NFSv4.0 works correctly on all kernel versions. NOTE ON KERNEL 7.0 (UBUNTU 26.04) BEHAVIOR ------------------------------------------- While kernel 7.0 does not exhibit the EIO failure, the underlying bug is still present. Kernel 7.0 negotiates the same incorrect wsize=1,048,576 (verified via nfsstat -m), and the server still rejects the oversized RPC with NFS4ERR_REQ_TOO_BIG (verified via tcpdump). The difference is that kernel 7.0 handles the error by reducing the write size and retrying. This approach has several drawbacks: - Every first WRITE at 1 MiB is rejected, generating unnecessary network round-trips and latency on every large write operation. - NFS4ERR_SEQ_MISORDERED errors following each rejection indicate sequence ID desynchronization, impacting session slot efficiency. - The retry mechanism masks the negotiation defect without eliminating it: the client systematically sends packets the server has to reject. - On high-throughput workloads (backups, large file transfers), the cumulative cost of rejected-then-retried RPCs can impact performance. The proper fix is to restore correct wsize/rsize negotiation so that RPC WRITE requests never exceed ca_maxrequestsize in the first place. The retry handling in kernel 7.0 is a valuable defense-in-depth mechanism and should be backported, but it should not be considered a substitute for fixing the negotiation logic. BISECTION RESULTS ----------------- Kernel bisection on the same machine, same NFS export, same default mount options. Only the kernel changed between reboots. Kernel Date wsize negotiated dd bs=1M Status ----------- ----------- ---------------- -------- ---------- 6.8.0-100 Feb 2026 1,047,532 OK OK 6.8.0-107 13 Mar 2026 1,047,532 OK Last good 6.8.0-110 19 Mar 2026 1,048,576 EIO First bad Git source confirmation: diff between tags Ubuntu-6.8.0-107.107 and Ubuntu-6.8.0-110.110 on git.launchpad.net confirms that commit ae0cf4493dd3 is the only change to fs/nfs/client.c affecting wsize/rsize handling. FULL CLIENT TEST MATRIX ----------------------- OS Kernel wsize dd bs=1M Result Note ------------- ----------- ---------- -------- ------ ---------------- Ubuntu 22.04 5.15.0-176 1,047,532 OK OK Reference Ubuntu 24.04 6.8.0-100 1,047,532 OK OK Ubuntu 24.04 6.8.0-107 1,047,532 OK OK Last good Ubuntu 24.04 6.8.0-110 1,048,576 EIO BUG First bad Ubuntu 24.04 6.8.0-110* 1,047,532 OK FIXED Patched nfs.ko Ubuntu 24.04 6.17.0-22 1,048,576 EIO BUG HWE Ubuntu 26.04 7.0 1,048,576 OK** Mitig. Retry masks bug * Patched nfs.ko with unconditional wsize/rsize copy restored. ** OK via retry after NFS4ERR_REQ_TOO_BIG. Negotiation bug still present. NFSv4.0: NOT affected (no sessions). NFSv3: NOT affected. EVIDENCE -------- ### tcpdump on kernel 6.8.0-110 (failing) 1222 2.970s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 2289 2.979s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 6622 3.015s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED [... 20+ repetitions, client never recovers, returns EIO ...] ### tcpdump on kernel 7.0 (mitigated, not fixed) 135 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 137 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED 296 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 298 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED Write completes after retry. Errors still occur on every large write. ### nfsstat -m comparison Kernel wsize rsize ------------------ ----------------------- ----------------------- 5.15 / 6.8.0-107 1,047,532 (correct) 1,047,672 (correct) 6.8.0-110 1,048,576 (regression) 1,048,576 (regression) 6.8.0-110 patched 1,047,532 (fixed) 1,047,672 (fixed) 7.0 (26.04) 1,048,576 (still wrong) 1,048,576 (still wrong) ### Dichotomy tests - exact failure thresholds Kernel 6.8.0-110: bs = 1,044,480 (1020 KiB) -> OK (last passing) bs = 1,048,576 (1024 KiB) -> EIO (= negotiated wsize) Kernel 6.17.0-22 (HWE): bs = 1,048,328 -> OK (last passing) bs = 1,048,329 -> EIO (first failing) Delta: 248 bytes (vs ~1,044 on working kernels). Partial overhead subtraction. STEPS TO REPRODUCE ------------------ 1. Install Ubuntu 24.04 with kernel 6.8.0-110-generic (or later). 2. Mount an NFSv4.2 export from a server with Write Transfer Max Size = 1 MiB without specifying wsize: mount -t nfs4 -o vers=4.2 server:/export /mnt/nfs 3. Verify the negotiated wsize: nfsstat -m | grep wsize Result on -110: wsize=1048576 (BUG - raw value, no overhead subtracted) Result on -107: wsize=1047532 (correct - overhead subtracted) 4. Attempt a write: dd if=/dev/zero of=/mnt/nfs/test bs=1M count=1 conv=fsync 5. On -110: dd returns "Input/output error". On -107: dd succeeds. 6. Capture with tcpdump on port 2049 shows NFS4ERR_REQ_TOO_BIG from server. ENVIRONMENT ----------- Server platform: Dell PowerScale OneFS 9.7 Protocol: NFSv4.2 (also reproduces on NFSv4.1) Write Transfer Max Size: 1 MiB (1,048,576 bytes) Write Transfer Size (pref.): 512 KiB Write Transfer Multiple: 512 bytes Client mount options: Default (no explicit wsize/rsize) WORKAROUNDS ----------- Option 1 - Force wsize/rsize at mount time (recommended): mount -o vers=4.2,wsize=524288,rsize=524288 server:/export /mnt Sets the NFS_AUTOMOUNT_INHERIT_WSIZE flag. Configurable in /etc/fstab, autofs maps, or systemd mount units. Option 2 - Boot on kernel 6.8.0-107 or earlier: Not a long-term solution (missing security patches from -110+). Option 3 - Use NFSv4.0: mount -o vers=4.0 server:/export /mnt Not affected (no sessions). Loses NFSv4.1+ features. REQUESTED ACTION ---------------- Two complementary fixes are recommended: 1. Fix the regression in nfs_server_copy_userdata(): restore the unconditional copy of wsize/rsize while keeping the conditional copy of bsize. The proposed fix has been compiled, tested, and validated on kernel 6.8.0-110-generic. 2. Backport the NFS4ERR_REQ_TOO_BIG retry logic from kernel 7.0 as defense-in-depth. This should not be considered a substitute for correct negotiation, as it generates unnecessary rejected RPCs, sequence desynchronization, and added latency on every large write operation. Ubuntu 24.04 LTS is supported until 2029. This regression affects any NFSv4.1/4.2 deployment where the server's ca_maxrequestsize equals the maximum write payload size. PACKAGE VERSIONS ---------------- linux-image-6.8.0-110-generic 6.8.0-110.110 (first bad) linux-image-6.8.0-107-generic 6.8.0-107.107 (last good) nfs-common 1:2.6.4-3ubuntu5.1 libnfsidmap1 1:2.6.4-3ubuntu5.1 libtirpc3t64 1.3.4+ds-1.1build1 rpcbind 1.2.6-7ubuntu2 GIT SOURCE REFERENCE -------------------- Repository: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble Tags compared: Ubuntu-6.8.0-107.107 .. Ubuntu-6.8.0-110.110 Guilty commit: ae0cf4493dd3 NFS: Fix inheritance of the block sizes when automounting Files changed: fs/nfs/client.c (nfs_init_server, nfs_server_copy_userdata) RELATED REFERENCES ------------------- Upstream commit 943cff67b842: "NFSv4.1: Fix the r/wsize checking" by Trond Myklebust. RFC 8881, Section 18.36: CREATE_SESSION - defines ca_maxrequestsize and NFS4ERR_REQ_TOO_BIG. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150318/+subscriptions

[Bug 1117336] Re: CVE-2013-0231

The task "linux-lts-raring (Ubuntu Xenial)" has expired because it has had no new comments or updates for more than three years. If this issue is still present in an Ubuntu LTS kernel still under active support, please reopen the bug and provide updated details. If this issue was reported against an Ubuntu kernel no longer under active support but the issue still exists in a currently supported Ubuntu kernel, please open a new bug against that kernel version and provide the updated details, with a reference link to the original bug. This action was performed by an automated process maintained by the Ubuntu Kernel Team. ** Changed in: linux-lts-raring (Ubuntu Xenial) Status: New => Expired -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/1117336 Title: CVE-2013-0231 Status in linux package in Ubuntu: Fix Released Status in linux-armadaxp package in Ubuntu: Invalid Status in linux-ec2 package in Ubuntu: Invalid Status in linux-flo package in Ubuntu: Invalid Status in linux-fsl-imx51 package in Ubuntu: Invalid Status in linux-goldfish package in Ubuntu: Invalid Status in linux-lts-backport-maverick package in Ubuntu: Invalid Status in linux-lts-backport-natty package in Ubuntu: Invalid Status in linux-lts-backport-oneiric package in Ubuntu: Invalid Status in linux-lts-quantal package in Ubuntu: Invalid Status in linux-lts-raring package in Ubuntu: Expired Status in linux-lts-saucy package in Ubuntu: Expired Status in linux-lts-trusty package in Ubuntu: Invalid Status in linux-lts-utopic package in Ubuntu: Invalid Status in linux-lts-vivid package in Ubuntu: Invalid Status in linux-lts-wily package in Ubuntu: Invalid Status in linux-lts-xenial package in Ubuntu: Invalid Status in linux-mako package in Ubuntu: Invalid Status in linux-manta package in Ubuntu: Invalid Status in linux-mvl-dove package in Ubuntu: Invalid Status in linux-raspi2 package in Ubuntu: Fix Committed Status in linux-ti-omap4 package in Ubuntu: Invalid Status in linux-lts-backport-maverick source package in Lucid: Invalid Status in linux-lts-backport-natty source package in Lucid: Invalid Status in linux-lts-backport-oneiric source package in Lucid: Invalid Status in linux-lts-backport-maverick source package in Oneiric: Invalid Status in linux-lts-backport-natty source package in Oneiric: Invalid Status in linux-lts-backport-oneiric source package in Oneiric: Invalid Status in linux source package in Precise: Fix Released Status in linux-armadaxp source package in Precise: Fix Released Status in linux-ec2 source package in Precise: Invalid Status in linux-flo source package in Precise: Invalid Status in linux-fsl-imx51 source package in Precise: Invalid Status in linux-goldfish source package in Precise: Invalid Status in linux-lts-backport-maverick source package in Precise: Invalid Status in linux-lts-backport-natty source package in Precise: Invalid Status in linux-lts-backport-oneiric source package in Precise: Invalid Status in linux-lts-quantal source package in Precise: Fix Released Status in linux-lts-raring source package in Precise: Won't Fix Status in linux-lts-saucy source package in Precise: Won't Fix Status in linux-lts-trusty source package in Precise: Invalid Status in linux-lts-utopic source package in Precise: Invalid Status in linux-lts-vivid source package in Precise: Invalid Status in linux-lts-wily source package in Precise: Invalid Status in linux-lts-xenial source package in Precise: Invalid Status in linux-mako source package in Precise: Invalid Status in linux-manta source package in Precise: Invalid Status in linux-mvl-dove source package in Precise: Invalid Status in linux-raspi2 source package in Precise: Invalid Status in linux-ti-omap4 source package in Precise: Fix Released Status in linux-lts-backport-maverick source package in Quantal: Invalid Status in linux-lts-backport-natty source package in Quantal: Invalid Status in linux-lts-backport-oneiric source package in Quantal: Invalid Status in linux-lts-backport-maverick source package in Raring: Invalid Status in linux-lts-backport-natty source package in Raring: Invalid Status in linux-lts-backport-oneiric source package in Raring: Invalid Status in linux source package in Trusty: Invalid Status in linux-armadaxp source package in Trusty: Invalid Status in linux-ec2 source package in Trusty: Invalid Status in linux-flo source package in Trusty: Invalid Status in linux-fsl-imx51 source package in Trusty: Invalid Status in linux-goldfish source package in Trusty: Invalid Status in linux-lts-backport-maverick source package in Trusty: New Status in linux-lts-backport-natty source package in Trusty: New Status in linux-lts-backport-oneiric source package in Trusty: New Status in linux-lts-quantal source package in Trusty: Invalid Status in linux-lts-raring source package in Trusty: Expired Status in linux-lts-saucy source package in Trusty: Expired Status in linux-lts-trusty source package in Trusty: Invalid Status in linux-lts-utopic source package in Trusty: Invalid Status in linux-lts-vivid source package in Trusty: Fix Committed Status in linux-lts-wily source package in Trusty: Invalid Status in linux-lts-xenial source package in Trusty: Fix Committed Status in linux-mako source package in Trusty: Invalid Status in linux-manta source package in Trusty: Invalid Status in linux-mvl-dove source package in Trusty: Invalid Status in linux-raspi2 source package in Trusty: Invalid Status in linux-ti-omap4 source package in Trusty: Invalid Status in linux-lts-backport-maverick source package in Utopic: Won't Fix Status in linux-lts-backport-natty source package in Utopic: Won't Fix Status in linux-lts-backport-oneiric source package in Utopic: Won't Fix Status in linux source package in Vivid: Invalid Status in linux-armadaxp source package in Vivid: Invalid Status in linux-ec2 source package in Vivid: Invalid Status in linux-flo source package in Vivid: Invalid Status in linux-fsl-imx51 source package in Vivid: Invalid Status in linux-goldfish source package in Vivid: Invalid Status in linux-lts-backport-maverick source package in Vivid: New Status in linux-lts-backport-natty source package in Vivid: New Status in linux-lts-backport-oneiric source package in Vivid: New Status in linux-lts-quantal source package in Vivid: Invalid Status in linux-lts-raring source package in Vivid: Won't Fix Status in linux-lts-saucy source package in Vivid: Won't Fix Status in linux-lts-trusty source package in Vivid: Invalid Status in linux-lts-utopic source package in Vivid: Invalid Status in linux-lts-vivid source package in Vivid: Invalid Status in linux-lts-wily source package in Vivid: Invalid Status in linux-lts-xenial source package in Vivid: Won't Fix Status in linux-mako source package in Vivid: Invalid Status in linux-manta source package in Vivid: Invalid Status in linux-mvl-dove source package in Vivid: Invalid Status in linux-raspi2 source package in Vivid: Invalid Status in linux-ti-omap4 source package in Vivid: Invalid Status in linux source package in Wily: Fix Released Status in linux-armadaxp source package in Wily: Invalid Status in linux-ec2 source package in Wily: Invalid Status in linux-flo source package in Wily: Invalid Status in linux-fsl-imx51 source package in Wily: Invalid Status in linux-goldfish source package in Wily: Invalid Status in linux-lts-backport-maverick source package in Wily: Invalid Status in linux-lts-backport-natty source package in Wily: Invalid Status in linux-lts-backport-oneiric source package in Wily: Invalid Status in linux-lts-quantal source package in Wily: Invalid Status in linux-lts-raring source package in Wily: Won't Fix Status in linux-lts-saucy source package in Wily: Won't Fix Status in linux-lts-trusty source package in Wily: Invalid Status in linux-lts-utopic source package in Wily: Invalid Status in linux-lts-vivid source package in Wily: Invalid Status in linux-lts-wily source package in Wily: Invalid Status in linux-lts-xenial source package in Wily: Invalid Status in linux-mako source package in Wily: Invalid Status in linux-manta source package in Wily: Invalid Status in linux-mvl-dove source package in Wily: Invalid Status in linux-raspi2 source package in Wily: Invalid Status in linux-ti-omap4 source package in Wily: Invalid Status in linux source package in Xenial: Fix Released Status in linux-armadaxp source package in Xenial: Invalid Status in linux-ec2 source package in Xenial: Invalid Status in linux-flo source package in Xenial: Invalid Status in linux-fsl-imx51 source package in Xenial: Invalid Status in linux-goldfish source package in Xenial: Invalid Status in linux-lts-backport-maverick source package in Xenial: Invalid Status in linux-lts-backport-natty source package in Xenial: Invalid Status in linux-lts-backport-oneiric source package in Xenial: Invalid Status in linux-lts-quantal source package in Xenial: Invalid Status in linux-lts-raring source package in Xenial: Expired Status in linux-lts-saucy source package in Xenial: Expired Status in linux-lts-trusty source package in Xenial: Invalid Status in linux-lts-utopic source package in Xenial: Invalid Status in linux-lts-vivid source package in Xenial: Invalid Status in linux-lts-wily source package in Xenial: Invalid Status in linux-lts-xenial source package in Xenial: Invalid Status in linux-mako source package in Xenial: Invalid Status in linux-manta source package in Xenial: Invalid Status in linux-mvl-dove source package in Xenial: Invalid Status in linux-raspi2 source package in Xenial: Fix Committed Status in linux-ti-omap4 source package in Xenial: Invalid Status in linux-lts-backport-maverick source package in Hardy: Invalid Status in linux-lts-backport-natty source package in Hardy: Invalid Status in linux-lts-backport-oneiric source package in Hardy: Invalid Bug description: The pciback_enable_msi function in the PCI backend driver (drivers/xen/pciback/conf_space_capability_msi.c) in Xen for the Linux kernel 2.6.18 and 3.8 allows guest OS users with PCI device access to cause a denial of service via a large number of kernel log messages. NOTE: some of these details are obtained from third party information. Break-Fix: - 51ac8893a7a51b196501164e645583bf78138699 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1117336/+subscriptions

[Bug 2150318] Re: NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3)

** Description changed: - Ubuntu Kernel - NFS Client - Regression in 6.8.0-110 - - Package - linux (source) - Component - fs/nfs/client.c - nfs_server_copy_userdata() - Guilty commit - ae0cf4493dd3 - NFS: Fix inheritance of the block sizes when automounting - Severity - High - data write failure, EIO returned to applications - Affects - Ubuntu 24.04 LTS (Noble) - kernel 6.8.0-110+, kernel 6.17.x (HWE) - Not affected - Ubuntu 24.04 LTS kernel 6.8.0-107 and earlier - Mitigated in - Ubuntu 26.04 kernel 7.0 (retry on error, but root cause still present) - Protocol - NFSv4.1 and NFSv4.2 only (NFSv4.0 and NFSv3 not affected) - - - Title NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3) - Summary - Commit ae0cf4493dd3 ("NFS: Fix inheritance of the block sizes when automounting"), backported in kernel 6.8.0-110.110, introduced a regression in nfs_server_copy_userdata() (fs/nfs/client.c). The patch made the copy of wsize/rsize conditional on NFS_AUTOMOUNT_INHERIT_WSIZE/RSIZE flags. These flags are only set when the user explicitly specifies wsize/rsize at mount time. When mounting with default options (the standard case), the session-negotiated wsize/rsize values (with COMPOUND overhead correctly subtracted by nfs4_session_limit_rwsize()) are no longer propagated. The client ends up using the raw ca_maxrequestsize value, generating oversized RPC WRITE requests that the server rejects with NFS4ERR_REQ_TOO_BIG. - Impact - Any application performing writes of 1 MiB or larger on an NFSv4.1/4.2 mount where the server's Write Transfer Max Size equals the negotiated wsize will experience data write failures (EIO on fsync). This affects dd, cp, rsync, and any application using large write buffers. The issue impacts any enterprise NAS platform where ca_maxrequestsize equals the maximum write payload (common with Dell PowerScale, NetApp ONTAP, and other platforms). - Root cause analysis - The guilty commit - Commit: ae0cf4493dd3 - Title: NFS: Fix inheritance of the block sizes when automounting - File: fs/nfs/client.c - Function: nfs_server_copy_userdata() - - Function BEFORE the regression (kernel 6.8.0-107, working) + ================================================================================================= + + Package: linux (source) + Component: fs/nfs/client.c - nfs_server_copy_userdata() + Guilty commit: ae0cf4493dd3 - NFS: Fix inheritance of the block sizes when automounting + Severity: High - data write failure, EIO returned to applications + Affects: Ubuntu 24.04 LTS (Noble) - kernel 6.8.0-110+, kernel 6.17.x (HWE) + Not affected: Ubuntu 24.04 LTS kernel 6.8.0-107 and earlier + Mitigated in: Ubuntu 26.04 kernel 7.0 (retry on error, but root cause still present) + Protocol: NFSv4.1 and NFSv4.2 only (NFSv4.0 and NFSv3 not affected) + Impact: Identified on over 100 production Ubuntu 24.04 LTS workstations in an enterprise environment + + + SUMMARY + ------- + + Commit ae0cf4493dd3 ("NFS: Fix inheritance of the block sizes when automounting"), + backported in kernel 6.8.0-110.110, introduced a regression in + nfs_server_copy_userdata() (fs/nfs/client.c). The patch made the copy of + wsize/rsize conditional on NFS_AUTOMOUNT_INHERIT_WSIZE/RSIZE flags. These flags + are only set when the user explicitly specifies wsize/rsize at mount time. When + mounting with default options (the standard case), the session-negotiated + wsize/rsize values (with COMPOUND overhead correctly subtracted by + nfs4_session_limit_rwsize()) are no longer propagated. The client ends up using + the raw ca_maxrequestsize value, generating oversized RPC WRITE requests that + the server rejects with NFS4ERR_REQ_TOO_BIG. + + + IMPACT + ------ + + Any application performing writes of 1 MiB or larger on an NFSv4.1/4.2 mount + where the server's Write Transfer Max Size equals the negotiated wsize will + experience data write failures (EIO on fsync). This affects dd, cp, rsync, and + any application using large write buffers. The issue impacts any enterprise NAS + platform where ca_maxrequestsize equals the maximum write payload (common with + Dell PowerScale, NetApp ONTAP, and other platforms). + + + ROOT CAUSE ANALYSIS + ------------------- + + ### The guilty commit + + Commit: ae0cf4493dd3 + Title: NFS: Fix inheritance of the block sizes when automounting + File: fs/nfs/client.c + Function: nfs_server_copy_userdata() + + + ### Function BEFORE the regression (kernel 6.8.0-107, working) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->rsize = source->rsize; target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } wsize and rsize are always copied unconditionally. Values computed by nfs4_session_limit_rwsize() (subtracting nfs41_maxwrite_overhead from ca_maxrequestsize) are correctly propagated. - Function AFTER the regression (kernel 6.8.0-110, broken) + + ### Function AFTER the regression (kernel 6.8.0-110, broken) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_RSIZE) /* <-- BUG */ target->rsize = source->rsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_WSIZE) /* <-- BUG */ target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } - Copy of wsize/rsize is now conditional on INHERIT flags. These flags are - only set when the user explicitly passes wsize=/rsize= at mount time - (ctx->wsize != 0). In the default mount case, the flags are never set - and the negotiated values are silently dropped. - - Proposed fix (tested and validated) + Copy of wsize/rsize is now conditional on INHERIT flags. These flags are only + set when the user explicitly passes wsize=/rsize= at mount time (ctx->wsize != 0). + In the default mount case, the flags are never set and the negotiated values are + silently dropped. + + + ### Proposed fix (tested and validated) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; target->rsize = source->rsize; /* FIXED */ target->wsize = source->wsize; /* FIXED */ target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } Restores unconditional copy of wsize/rsize while keeping the new - automount_inherit field and the conditional copy of bsize (the original - intent of the commit). This fix was compiled as a replacement nfs.ko - module, installed on a test machine running kernel 6.8.0-110-generic, - and validated: wsize reverted from 1,048,576 to 1,047,532 and all write - operations succeeded. - - The chain of events - 1. Client mounts NFSv4.2 without explicit wsize (default behavior). - 2. CREATE_SESSION negotiates ca_maxrequestsize = 1,048,576 bytes. - 3. nfs4_session_limit_rwsize() correctly computes wsize = 1,048,576 - 1,044 = 1,047,532. - 4. NFS_AUTOMOUNT_INHERIT_WSIZE is NOT set (ctx->wsize was 0). - 5. nfs_server_copy_userdata() skips copying the negotiated wsize. - 6. The server object ends up with wsize = 1,048,576 (raw ca_maxrequestsize). - 7. WRITE RPC: 1,048,576 payload + ~1,044 overhead = ~1,049,620 bytes total. - 8. Server rejects with NFS4ERR_REQ_TOO_BIG (RFC 8881 Section 18.36). - 9. Client enters a retry loop, sequence IDs desynchronize, returns EIO. - - Why NFSv4.0 is not affected - NFSv4.0 does not use sessions (no CREATE_SESSION, no ca_maxrequestsize, no nfs4_session_limit_rwsize()). Confirmed by testing: NFSv4.0 works correctly on all kernel versions. - - Note on kernel 7.0 (Ubuntu 26.04) behavior - While kernel 7.0 does not exhibit the EIO failure, the underlying bug is still present. Kernel 7.0 negotiates the same incorrect wsize=1,048,576 (verified via nfsstat -m), and the server still rejects the oversized RPC with NFS4ERR_REQ_TOO_BIG (verified via tcpdump). The difference is that kernel 7.0 handles the error by reducing the write size and retrying. + automount_inherit field and the conditional copy of bsize (the original intent + of the commit). This fix was compiled as a replacement nfs.ko module, installed + on a test machine running kernel 6.8.0-110-generic, and validated: wsize + reverted from 1,048,576 to 1,047,532 and all write operations succeeded. + + + ### The chain of events + + 1. Client mounts NFSv4.2 without explicit wsize (default behavior). + 2. CREATE_SESSION negotiates ca_maxrequestsize = 1,048,576 bytes. + 3. nfs4_session_limit_rwsize() correctly computes wsize = 1,048,576 - 1,044 = 1,047,532. + 4. NFS_AUTOMOUNT_INHERIT_WSIZE is NOT set (ctx->wsize was 0). + 5. nfs_server_copy_userdata() skips copying the negotiated wsize. + 6. The server object ends up with wsize = 1,048,576 (raw ca_maxrequestsize). + 7. WRITE RPC: 1,048,576 payload + ~1,044 overhead = ~1,049,620 bytes total. + 8. Server rejects with NFS4ERR_REQ_TOO_BIG (RFC 8881 Section 18.36). + 9. Client enters a retry loop, sequence IDs desynchronize, returns EIO. + + + ### Why NFSv4.0 is not affected + + NFSv4.0 does not use sessions (no CREATE_SESSION, no ca_maxrequestsize, no + nfs4_session_limit_rwsize()). Confirmed by testing: NFSv4.0 works correctly + on all kernel versions. + + + NOTE ON KERNEL 7.0 (UBUNTU 26.04) BEHAVIOR + ------------------------------------------- + + While kernel 7.0 does not exhibit the EIO failure, the underlying bug is still + present. Kernel 7.0 negotiates the same incorrect wsize=1,048,576 (verified via + nfsstat -m), and the server still rejects the oversized RPC with + NFS4ERR_REQ_TOO_BIG (verified via tcpdump). The difference is that kernel 7.0 + handles the error by reducing the write size and retrying. This approach has several drawbacks: - Every first WRITE at 1 MiB is rejected by the server, generating unnecessary network round-trips and latency on every large write operation. - The NFS4ERR_SEQ_MISORDERED errors following each rejection indicate sequence ID desynchronization, which impacts session slot efficiency. - The retry mechanism masks the negotiation defect without eliminating it: the client systematically sends packets the server has to reject. - On high-throughput workloads (backups, large file transfers), the cumulative cost of rejected-then-retried RPCs can impact performance. - - The proper fix is to restore correct wsize/rsize negotiation so that RPC - WRITE requests never exceed ca_maxrequestsize in the first place. The - retry handling in kernel 7.0 is a valuable defense-in-depth mechanism - and should be backported to the Noble kernel series, but it should not - be considered a substitute for fixing the negotiation logic. - - Bisection results - Kernel bisection on the same machine, same NFS export, same default mount options. Only the kernel changed between reboots. - - Kernel - Date - wsize negotiated - dd bs=1M - Status - 6.8.0-100 - Feb 2026 - 1,047,532 - OK - OK - 6.8.0-107 - 13 Mar 2026 - 1,047,532 - OK - Last good - 6.8.0-110 - 19 Mar 2026 - 1,048,576 - EIO - First bad - - - Git source confirmation: diff between tags Ubuntu-6.8.0-107.107 and Ubuntu-6.8.0-110.110 on git.launchpad.net confirms that commit ae0cf4493dd3 is the only change to fs/nfs/client.c affecting wsize/rsize handling. - Full client test matrix - OS - Kernel - wsize - dd bs=1M - Result - Note - Ubuntu 22.04 - 5.15.0-176 - 1,047,532 - OK - OK - Reference - Ubuntu 24.04 - 6.8.0-100 - 1,047,532 - OK - OK - - - Ubuntu 24.04 - 6.8.0-107 - 1,047,532 - OK - OK - Last good - Ubuntu 24.04 - 6.8.0-110 - 1,048,576 - EIO - BUG - First bad - Ubuntu 24.04 - 6.8.0-110* - 1,047,532 - OK - FIXED - Patched nfs.ko - Ubuntu 24.04 - 6.17.0-22 - 1,048,576 - EIO - BUG - HWE - Ubuntu 26.04 - 7.0 - 1,048,576 - OK** - Mitig. - Retry masks bug - - - * Patched nfs.ko with unconditional wsize/rsize copy restored in nfs_server_copy_userdata(). - ** OK via retry after NFS4ERR_REQ_TOO_BIG. The negotiation bug is still present (wsize=1,048,576), only the error handling compensates. - - NFSv4.0: NOT affected (no sessions). NFSv3: NOT affected. - - Evidence - tcpdump on kernel 6.8.0-110 (failing) + - Every first WRITE at 1 MiB is rejected, generating unnecessary network + round-trips and latency on every large write operation. + - NFS4ERR_SEQ_MISORDERED errors following each rejection indicate sequence + ID desynchronization, impacting session slot efficiency. + - The retry mechanism masks the negotiation defect without eliminating it: + the client systematically sends packets the server has to reject. + - On high-throughput workloads (backups, large file transfers), the + cumulative cost of rejected-then-retried RPCs can impact performance. + + The proper fix is to restore correct wsize/rsize negotiation so that RPC WRITE + requests never exceed ca_maxrequestsize in the first place. The retry handling + in kernel 7.0 is a valuable defense-in-depth mechanism and should be backported, + but it should not be considered a substitute for fixing the negotiation logic. + + + BISECTION RESULTS + ----------------- + + Kernel bisection on the same machine, same NFS export, same default mount + options. Only the kernel changed between reboots. + + Kernel Date wsize negotiated dd bs=1M Status + ----------- ----------- ---------------- -------- ---------- + 6.8.0-100 Feb 2026 1,047,532 OK OK + 6.8.0-107 13 Mar 2026 1,047,532 OK Last good + 6.8.0-110 19 Mar 2026 1,048,576 EIO First bad + + Git source confirmation: diff between tags Ubuntu-6.8.0-107.107 and + Ubuntu-6.8.0-110.110 on git.launchpad.net confirms that commit ae0cf4493dd3 + is the only change to fs/nfs/client.c affecting wsize/rsize handling. + + + FULL CLIENT TEST MATRIX + ----------------------- + + OS Kernel wsize dd bs=1M Result Note + ------------- ----------- ---------- -------- ------ ---------------- + Ubuntu 22.04 5.15.0-176 1,047,532 OK OK Reference + Ubuntu 24.04 6.8.0-100 1,047,532 OK OK + Ubuntu 24.04 6.8.0-107 1,047,532 OK OK Last good + Ubuntu 24.04 6.8.0-110 1,048,576 EIO BUG First bad + Ubuntu 24.04 6.8.0-110* 1,047,532 OK FIXED Patched nfs.ko + Ubuntu 24.04 6.17.0-22 1,048,576 EIO BUG HWE + Ubuntu 26.04 7.0 1,048,576 OK** Mitig. Retry masks bug + + * Patched nfs.ko with unconditional wsize/rsize copy restored. + ** OK via retry after NFS4ERR_REQ_TOO_BIG. Negotiation bug still present. + + NFSv4.0: NOT affected (no sessions). + NFSv3: NOT affected. + + + EVIDENCE + -------- + + ### tcpdump on kernel 6.8.0-110 (failing) + 1222 2.970s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 2289 2.979s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 6622 3.015s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED [... 20+ repetitions, client never recovers, returns EIO ...] - tcpdump on kernel 7.0 (mitigated, not fixed) + + ### tcpdump on kernel 7.0 (mitigated, not fixed) + 135 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 137 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED 296 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 298 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED - Write completes after retry. Errors still occur on every large write. - - nfsstat -m comparison - Kernel - wsize - rsize - 5.15 / 6.8.0-107 - 1,047,532 (correct) - 1,047,672 (correct) - 6.8.0-110 - 1,048,576 (regression) - 1,048,576 (regression) - 6.8.0-110 patched - 1,047,532 (fixed) - 1,047,672 (fixed) - 7.0 (26.04) - 1,048,576 (still wrong) - 1,048,576 (still wrong) - - - Dichotomy tests - exact failure thresholds - Kernel 6.8.0-110: - bs (bytes) - Result - Note - 1,044,480 (1020 KiB) - OK - Last passing - 1,048,576 (1024 KiB) - EIO - = negotiated wsize - - - Kernel 6.17.0-22 (HWE): - bs (bytes) - Result - Note - 1,048,328 - OK - Last passing - 1,048,329 - EIO - First failing - - Delta on 6.17: 248 bytes (vs ~1,044 on working kernels). Suggests - partial overhead subtraction, insufficient. - - Environment - Parameter - Value - Server platform - Dell PowerScale OneFS 9.7 - Protocol - NFSv4.2 (also reproduces on NFSv4.1) - Write Transfer Max Size - 1 MiB (1,048,576 bytes) - Write Transfer Size (preferred) - 512 KiB - Write Transfer Multiple - 512 bytes - Client mount options - Default (no explicit wsize/rsize) - - - Workarounds - Option 1 - Force wsize/rsize at mount time (recommended): - mount -o vers=4.2,wsize=524288,rsize=524288 server:/export /mnt - Sets the NFS_AUTOMOUNT_INHERIT_WSIZE flag, so the value is propagated. Configurable in /etc/fstab, autofs maps, or systemd mount units. - - Option 2 - Boot on kernel 6.8.0-107 or earlier: - Not a long-term solution (missing security patches from -110+). - - Option 3 - Use NFSv4.0: - Not affected (no sessions). Loses NFSv4.1+ features (sessions, trunking, pNFS). - - Requested action + Write completes after retry. Errors still occur on every large write. + + + ### nfsstat -m comparison + + Kernel wsize rsize + ------------------ ----------------------- ----------------------- + 5.15 / 6.8.0-107 1,047,532 (correct) 1,047,672 (correct) + 6.8.0-110 1,048,576 (regression) 1,048,576 (regression) + 6.8.0-110 patched 1,047,532 (fixed) 1,047,672 (fixed) + 7.0 (26.04) 1,048,576 (still wrong) 1,048,576 (still wrong) + + + ### Dichotomy tests - exact failure thresholds + + Kernel 6.8.0-110: + bs = 1,044,480 (1020 KiB) -> OK (last passing) + bs = 1,048,576 (1024 KiB) -> EIO (= negotiated wsize) + + Kernel 6.17.0-22 (HWE): + bs = 1,048,328 -> OK (last passing) + bs = 1,048,329 -> EIO (first failing) + Delta: 248 bytes (vs ~1,044 on working kernels). Partial overhead subtraction. + + + STEPS TO REPRODUCE + ------------------ + + 1. Install Ubuntu 24.04 with kernel 6.8.0-110-generic (or later). + 2. Mount an NFSv4.2 export from a server with Write Transfer Max Size = 1 MiB + without specifying wsize: + mount -t nfs4 -o vers=4.2 server:/export /mnt/nfs + 3. Verify the negotiated wsize: + nfsstat -m | grep wsize + Result on -110: wsize=1048576 (BUG - raw value, no overhead subtracted) + Result on -107: wsize=1047532 (correct - overhead subtracted) + 4. Attempt a write: + dd if=/dev/zero of=/mnt/nfs/test bs=1M count=1 conv=fsync + 5. On -110: dd returns "Input/output error". On -107: dd succeeds. + 6. Capture with tcpdump on port 2049 shows NFS4ERR_REQ_TOO_BIG from server. + + + ENVIRONMENT + ----------- + + Server platform: Dell PowerScale OneFS 9.7 + Protocol: NFSv4.2 (also reproduces on NFSv4.1) + Write Transfer Max Size: 1 MiB (1,048,576 bytes) + Write Transfer Size (pref.): 512 KiB + Write Transfer Multiple: 512 bytes + Client mount options: Default (no explicit wsize/rsize) + + + WORKAROUNDS + ----------- + + Option 1 - Force wsize/rsize at mount time (recommended): + mount -o vers=4.2,wsize=524288,rsize=524288 server:/export /mnt + Sets the NFS_AUTOMOUNT_INHERIT_WSIZE flag. Configurable in /etc/fstab, + autofs maps, or systemd mount units. + + Option 2 - Boot on kernel 6.8.0-107 or earlier: + Not a long-term solution (missing security patches from -110+). + + Option 3 - Use NFSv4.0: + mount -o vers=4.0 server:/export /mnt + Not affected (no sessions). Loses NFSv4.1+ features. + + + REQUESTED ACTION + ---------------- + Two complementary fixes are recommended: - 1. Fix the regression in nfs_server_copy_userdata(): restore the - unconditional copy of wsize/rsize while keeping the conditional copy of - bsize. The proposed fix has been compiled, tested, and validated on - kernel 6.8.0-110-generic (see "Proposed fix" section above). - - 2. Backport the NFS4ERR_REQ_TOO_BIG retry logic from kernel 7.0 as - defense-in-depth. This protects against future negotiation issues but - should not be considered a substitute for correct negotiation, as it - generates unnecessary rejected RPCs, sequence desynchronization, and - added latency on every large write operation. + 1. Fix the regression in nfs_server_copy_userdata(): restore the unconditional + copy of wsize/rsize while keeping the conditional copy of bsize. The proposed + fix has been compiled, tested, and validated on kernel 6.8.0-110-generic. + + 2. Backport the NFS4ERR_REQ_TOO_BIG retry logic from kernel 7.0 as + defense-in-depth. This should not be considered a substitute for correct + negotiation, as it generates unnecessary rejected RPCs, sequence + desynchronization, and added latency on every large write operation. Ubuntu 24.04 LTS is supported until 2029. This regression affects any NFSv4.1/4.2 deployment where the server's ca_maxrequestsize equals the maximum write payload size. - Package versions + + PACKAGE VERSIONS + ---------------- + linux-image-6.8.0-110-generic 6.8.0-110.110 (first bad) linux-image-6.8.0-107-generic 6.8.0-107.107 (last good) nfs-common 1:2.6.4-3ubuntu5.1 libnfsidmap1 1:2.6.4-3ubuntu5.1 libtirpc3t64 1.3.4+ds-1.1build1 rpcbind 1.2.6-7ubuntu2 - Git source reference - Repository: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble - Tags compared: Ubuntu-6.8.0-107.107 .. Ubuntu-6.8.0-110.110 - Guilty commit: ae0cf4493dd3 NFS: Fix inheritance of the block sizes when automounting - Files changed: fs/nfs/client.c (nfs_init_server, nfs_server_copy_userdata) - - Related references - Upstream commit 943cff67b842: "NFSv4.1: Fix the r/wsize checking" by Trond Myklebust. - RFC 8881, Section 18.36: CREATE_SESSION - defines ca_maxrequestsize and NFS4ERR_REQ_TOO_BIG. + + GIT SOURCE REFERENCE + -------------------- + + Repository: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble + Tags compared: Ubuntu-6.8.0-107.107 .. Ubuntu-6.8.0-110.110 + Guilty commit: ae0cf4493dd3 NFS: Fix inheritance of the block sizes when automounting + Files changed: fs/nfs/client.c (nfs_init_server, nfs_server_copy_userdata) + + + RELATED REFERENCES + ------------------- + + Upstream commit 943cff67b842: "NFSv4.1: Fix the r/wsize checking" by Trond Myklebust. + RFC 8881, Section 18.36: CREATE_SESSION - defines ca_maxrequestsize and NFS4ERR_REQ_TOO_BIG. -- You received this bug notification because you are subscribed to linux in Ubuntu. Matching subscriptions: Bgg, Bmail, Nb https://bugs.launchpad.net/bugs/2150318 Title: NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3) Status in linux package in Ubuntu: New Bug description: NFS: wsize/rsize regression in 6.8.0-110 causes EIO on NFSv4.1/4.2 writes (commit ae0cf4493dd3) ================================================================================================= Package: linux (source) Component: fs/nfs/client.c - nfs_server_copy_userdata() Guilty commit: ae0cf4493dd3 - NFS: Fix inheritance of the block sizes when automounting Severity: High - data write failure, EIO returned to applications Affects: Ubuntu 24.04 LTS (Noble) - kernel 6.8.0-110+, kernel 6.17.x (HWE) Not affected: Ubuntu 24.04 LTS kernel 6.8.0-107 and earlier Mitigated in: Ubuntu 26.04 kernel 7.0 (retry on error, but root cause still present) Protocol: NFSv4.1 and NFSv4.2 only (NFSv4.0 and NFSv3 not affected) Impact: Identified on over 100 production Ubuntu 24.04 LTS workstations in an enterprise environment SUMMARY ------- Commit ae0cf4493dd3 ("NFS: Fix inheritance of the block sizes when automounting"), backported in kernel 6.8.0-110.110, introduced a regression in nfs_server_copy_userdata() (fs/nfs/client.c). The patch made the copy of wsize/rsize conditional on NFS_AUTOMOUNT_INHERIT_WSIZE/RSIZE flags. These flags are only set when the user explicitly specifies wsize/rsize at mount time. When mounting with default options (the standard case), the session-negotiated wsize/rsize values (with COMPOUND overhead correctly subtracted by nfs4_session_limit_rwsize()) are no longer propagated. The client ends up using the raw ca_maxrequestsize value, generating oversized RPC WRITE requests that the server rejects with NFS4ERR_REQ_TOO_BIG. IMPACT ------ Any application performing writes of 1 MiB or larger on an NFSv4.1/4.2 mount where the server's Write Transfer Max Size equals the negotiated wsize will experience data write failures (EIO on fsync). This affects dd, cp, rsync, and any application using large write buffers. The issue impacts any enterprise NAS platform where ca_maxrequestsize equals the maximum write payload (common with Dell PowerScale, NetApp ONTAP, and other platforms). ROOT CAUSE ANALYSIS ------------------- ### The guilty commit Commit: ae0cf4493dd3 Title: NFS: Fix inheritance of the block sizes when automounting File: fs/nfs/client.c Function: nfs_server_copy_userdata() ### Function BEFORE the regression (kernel 6.8.0-107, working) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->rsize = source->rsize; target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } wsize and rsize are always copied unconditionally. Values computed by nfs4_session_limit_rwsize() (subtracting nfs41_maxwrite_overhead from ca_maxrequestsize) are correctly propagated. ### Function AFTER the regression (kernel 6.8.0-110, broken) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_RSIZE) /* <-- BUG */ target->rsize = source->rsize; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_WSIZE) /* <-- BUG */ target->wsize = source->wsize; target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } Copy of wsize/rsize is now conditional on INHERIT flags. These flags are only set when the user explicitly passes wsize=/rsize= at mount time (ctx->wsize != 0). In the default mount case, the flags are never set and the negotiated values are silently dropped. ### Proposed fix (tested and validated) void nfs_server_copy_userdata(struct nfs_server *target, struct nfs_server *source) { target->flags = source->flags; target->automount_inherit = source->automount_inherit; if (source->automount_inherit & NFS_AUTOMOUNT_INHERIT_BSIZE) target->bsize = source->bsize; target->rsize = source->rsize; /* FIXED */ target->wsize = source->wsize; /* FIXED */ target->acregmin = source->acregmin; target->acregmax = source->acregmax; target->acdirmin = source->acdirmin; target->acdirmax = source->acdirmax; target->options = source->options; target->auth_info = source->auth_info; target->port = source->port; } Restores unconditional copy of wsize/rsize while keeping the new automount_inherit field and the conditional copy of bsize (the original intent of the commit). This fix was compiled as a replacement nfs.ko module, installed on a test machine running kernel 6.8.0-110-generic, and validated: wsize reverted from 1,048,576 to 1,047,532 and all write operations succeeded. ### The chain of events 1. Client mounts NFSv4.2 without explicit wsize (default behavior). 2. CREATE_SESSION negotiates ca_maxrequestsize = 1,048,576 bytes. 3. nfs4_session_limit_rwsize() correctly computes wsize = 1,048,576 - 1,044 = 1,047,532. 4. NFS_AUTOMOUNT_INHERIT_WSIZE is NOT set (ctx->wsize was 0). 5. nfs_server_copy_userdata() skips copying the negotiated wsize. 6. The server object ends up with wsize = 1,048,576 (raw ca_maxrequestsize). 7. WRITE RPC: 1,048,576 payload + ~1,044 overhead = ~1,049,620 bytes total. 8. Server rejects with NFS4ERR_REQ_TOO_BIG (RFC 8881 Section 18.36). 9. Client enters a retry loop, sequence IDs desynchronize, returns EIO. ### Why NFSv4.0 is not affected NFSv4.0 does not use sessions (no CREATE_SESSION, no ca_maxrequestsize, no nfs4_session_limit_rwsize()). Confirmed by testing: NFSv4.0 works correctly on all kernel versions. NOTE ON KERNEL 7.0 (UBUNTU 26.04) BEHAVIOR ------------------------------------------- While kernel 7.0 does not exhibit the EIO failure, the underlying bug is still present. Kernel 7.0 negotiates the same incorrect wsize=1,048,576 (verified via nfsstat -m), and the server still rejects the oversized RPC with NFS4ERR_REQ_TOO_BIG (verified via tcpdump). The difference is that kernel 7.0 handles the error by reducing the write size and retrying. This approach has several drawbacks: - Every first WRITE at 1 MiB is rejected, generating unnecessary network round-trips and latency on every large write operation. - NFS4ERR_SEQ_MISORDERED errors following each rejection indicate sequence ID desynchronization, impacting session slot efficiency. - The retry mechanism masks the negotiation defect without eliminating it: the client systematically sends packets the server has to reject. - On high-throughput workloads (backups, large file transfers), the cumulative cost of rejected-then-retried RPCs can impact performance. The proper fix is to restore correct wsize/rsize negotiation so that RPC WRITE requests never exceed ca_maxrequestsize in the first place. The retry handling in kernel 7.0 is a valuable defense-in-depth mechanism and should be backported, but it should not be considered a substitute for fixing the negotiation logic. BISECTION RESULTS ----------------- Kernel bisection on the same machine, same NFS export, same default mount options. Only the kernel changed between reboots. Kernel Date wsize negotiated dd bs=1M Status ----------- ----------- ---------------- -------- ---------- 6.8.0-100 Feb 2026 1,047,532 OK OK 6.8.0-107 13 Mar 2026 1,047,532 OK Last good 6.8.0-110 19 Mar 2026 1,048,576 EIO First bad Git source confirmation: diff between tags Ubuntu-6.8.0-107.107 and Ubuntu-6.8.0-110.110 on git.launchpad.net confirms that commit ae0cf4493dd3 is the only change to fs/nfs/client.c affecting wsize/rsize handling. FULL CLIENT TEST MATRIX ----------------------- OS Kernel wsize dd bs=1M Result Note ------------- ----------- ---------- -------- ------ ---------------- Ubuntu 22.04 5.15.0-176 1,047,532 OK OK Reference Ubuntu 24.04 6.8.0-100 1,047,532 OK OK Ubuntu 24.04 6.8.0-107 1,047,532 OK OK Last good Ubuntu 24.04 6.8.0-110 1,048,576 EIO BUG First bad Ubuntu 24.04 6.8.0-110* 1,047,532 OK FIXED Patched nfs.ko Ubuntu 24.04 6.17.0-22 1,048,576 EIO BUG HWE Ubuntu 26.04 7.0 1,048,576 OK** Mitig. Retry masks bug * Patched nfs.ko with unconditional wsize/rsize copy restored. ** OK via retry after NFS4ERR_REQ_TOO_BIG. Negotiation bug still present. NFSv4.0: NOT affected (no sessions). NFSv3: NOT affected. EVIDENCE -------- ### tcpdump on kernel 6.8.0-110 (failing) 1222 2.970s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 2289 2.979s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 6622 3.015s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED [... 20+ repetitions, client never recovers, returns EIO ...] ### tcpdump on kernel 7.0 (mitigated, not fixed) 135 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 137 30.593s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED 296 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_REQ_TOO_BIG 298 44.304s nas -> client V4 Reply SEQUENCE: NFS4ERR_SEQ_MISORDERED Write completes after retry. Errors still occur on every large write. ### nfsstat -m comparison Kernel wsize rsize ------------------ ----------------------- ----------------------- 5.15 / 6.8.0-107 1,047,532 (correct) 1,047,672 (correct) 6.8.0-110 1,048,576 (regression) 1,048,576 (regression) 6.8.0-110 patched 1,047,532 (fixed) 1,047,672 (fixed) 7.0 (26.04) 1,048,576 (still wrong) 1,048,576 (still wrong) ### Dichotomy tests - exact failure thresholds Kernel 6.8.0-110: bs = 1,044,480 (1020 KiB) -> OK (last passing) bs = 1,048,576 (1024 KiB) -> EIO (= negotiated wsize) Kernel 6.17.0-22 (HWE): bs = 1,048,328 -> OK (last passing) bs = 1,048,329 -> EIO (first failing) Delta: 248 bytes (vs ~1,044 on working kernels). Partial overhead subtraction. STEPS TO REPRODUCE ------------------ 1. Install Ubuntu 24.04 with kernel 6.8.0-110-generic (or later). 2. Mount an NFSv4.2 export from a server with Write Transfer Max Size = 1 MiB without specifying wsize: mount -t nfs4 -o vers=4.2 server:/export /mnt/nfs 3. Verify the negotiated wsize: nfsstat -m | grep wsize Result on -110: wsize=1048576 (BUG - raw value, no overhead subtracted) Result on -107: wsize=1047532 (correct - overhead subtracted) 4. Attempt a write: dd if=/dev/zero of=/mnt/nfs/test bs=1M count=1 conv=fsync 5. On -110: dd returns "Input/output error". On -107: dd succeeds. 6. Capture with tcpdump on port 2049 shows NFS4ERR_REQ_TOO_BIG from server. ENVIRONMENT ----------- Server platform: Dell PowerScale OneFS 9.7 Protocol: NFSv4.2 (also reproduces on NFSv4.1) Write Transfer Max Size: 1 MiB (1,048,576 bytes) Write Transfer Size (pref.): 512 KiB Write Transfer Multiple: 512 bytes Client mount options: Default (no explicit wsize/rsize) WORKAROUNDS ----------- Option 1 - Force wsize/rsize at mount time (recommended): mount -o vers=4.2,wsize=524288,rsize=524288 server:/export /mnt Sets the NFS_AUTOMOUNT_INHERIT_WSIZE flag. Configurable in /etc/fstab, autofs maps, or systemd mount units. Option 2 - Boot on kernel 6.8.0-107 or earlier: Not a long-term solution (missing security patches from -110+). Option 3 - Use NFSv4.0: mount -o vers=4.0 server:/export /mnt Not affected (no sessions). Loses NFSv4.1+ features. REQUESTED ACTION ---------------- Two complementary fixes are recommended: 1. Fix the regression in nfs_server_copy_userdata(): restore the unconditional copy of wsize/rsize while keeping the conditional copy of bsize. The proposed fix has been compiled, tested, and validated on kernel 6.8.0-110-generic. 2. Backport the NFS4ERR_REQ_TOO_BIG retry logic from kernel 7.0 as defense-in-depth. This should not be considered a substitute for correct negotiation, as it generates unnecessary rejected RPCs, sequence desynchronization, and added latency on every large write operation. Ubuntu 24.04 LTS is supported until 2029. This regression affects any NFSv4.1/4.2 deployment where the server's ca_maxrequestsize equals the maximum write payload size. PACKAGE VERSIONS ---------------- linux-image-6.8.0-110-generic 6.8.0-110.110 (first bad) linux-image-6.8.0-107-generic 6.8.0-107.107 (last good) nfs-common 1:2.6.4-3ubuntu5.1 libnfsidmap1 1:2.6.4-3ubuntu5.1 libtirpc3t64 1.3.4+ds-1.1build1 rpcbind 1.2.6-7ubuntu2 GIT SOURCE REFERENCE -------------------- Repository: https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/noble Tags compared: Ubuntu-6.8.0-107.107 .. Ubuntu-6.8.0-110.110 Guilty commit: ae0cf4493dd3 NFS: Fix inheritance of the block sizes when automounting Files changed: fs/nfs/client.c (nfs_init_server, nfs_server_copy_userdata) RELATED REFERENCES ------------------- Upstream commit 943cff67b842: "NFSv4.1: Fix the r/wsize checking" by Trond Myklebust. RFC 8881, Section 18.36: CREATE_SESSION - defines ca_maxrequestsize and NFS4ERR_REQ_TOO_BIG. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2150318/+subscriptions