| Message ID | 20240909202855.510399-1-smayhew@redhat.com (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
From: Chuck Lever <chuck.lever@oracle.com> On Mon, 09 Sep 2024 16:28:53 -0400, Scott Mayhew wrote: > diff --git a/utils/nfsdcld/sqlite.c b/utils/nfsdcld/sqlite.c > index 03016fb9..fb900c7b 100644 > Applied to nfsd-next for v6.12, thanks! [1/1] nfsd: enforce upper limit for namelen in __cld_pipe_inprogress_downcall() commit: 2760ad9b89938ce09705ab30e2087c1fb29a5bb4 -- Chuck Lever
diff --git a/utils/nfsdcld/sqlite.c b/utils/nfsdcld/sqlite.c index 03016fb9..fb900c7b 100644 --- a/utils/nfsdcld/sqlite.c +++ b/utils/nfsdcld/sqlite.c @@ -1335,8 +1335,6 @@ sqlite_iterate_recovery(int (*cb)(struct cld_client *clnt), struct cld_client *c id = sqlite3_column_blob(stmt, 0); id_len = sqlite3_column_bytes(stmt, 0); - if (id_len > NFS4_OPAQUE_LIMIT) - id_len = NFS4_OPAQUE_LIMIT; memset(&cmsg->cm_u, 0, sizeof(cmsg->cm_u)); #if UPCALL_VERSION >= 2
This patch is intended to go on top of "nfsd: return -EINVAL when namelen is 0" from Li Lingfeng. Li's patch checks for 0, but we should be enforcing an upper bound as well. Note that if nfsdcld somehow gets an id > NFS4_OPAQUE_LIMIT in its database, it'll truncate it to NFS4_OPAQUE_LIMIT when it does the downcall anyway... so to test, I had to run nfsdcld with that check removed: ---8<--- ---8<--- I ran the following python script to add some dummy records of varying lengths (0, 1, 1024, 1025) to the sqlite db: ---8<--- import sqlite3 NFS4_OPAQUE_LIMIT=1024 con = sqlite3.connect("/var/lib/nfs/nfsdcld/main.sqlite") con.row_factory = sqlite3.Row for row in con.execute("select * from grace"): epoch = int(row['current']) query = 'insert into "rec-{:016x}" (id) values (?)'.format(epoch) w = None x = 'x'.encode() y = ('y' * NFS4_OPAQUE_LIMIT).encode() z = ('z' * (NFS4_OPAQUE_LIMIT + 1)).encode() con.execute(query, (w,)) con.execute(query, (x,)) con.execute(query, (y,)) con.execute(query, (z,)) con.commit() con.close() ---8<--- Additionally, I ensured I had a record from a valid client in the db and that that client had a file open. I enabled NFSDDBG_PROC, restarted nfsd, and checked for the following messages: Sep 09 15:30:27 rhel9.smayhew.redhat.com.nfsv4.dev kernel: __cld_pipe_inprogress_downcall: invalid namelen (0) Sep 09 15:30:27 rhel9.smayhew.redhat.com.nfsv4.dev kernel: __cld_pipe_inprogress_downcall: invalid namelen (1025) I also verified in wireshark that my actual client was able to reclaim its open file. -Scott Scott Mayhew (1): nfsd: enforce upper limit for namelen in __cld_pipe_inprogress_downcall() fs/nfsd/nfs4recover.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-)