| Message ID | YcIjJ4jN3ax1rqaE@debian-BULLSEYE-live-builder-AMD64 (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | nfs: check nf pointer for validity before use | expand |
Hi- > On Dec 21, 2021, at 1:55 PM, Muhammad Usama Anjum <usama.anjum@collabora.com> wrote: > > Pointer nf can be NULL. It should be validated before dereferencing it. > > Fixes: 8628027ba8 ("nfs: block notification on fs with its own ->lock") > Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> Thanks. To avoid confusion I've squashed this into 8628027 and refreshed my for-next branch. Btw, b4 complained about collabora.com's DKIM: [cel@bazille linux]$ b4 am https://lore.kernel.org/linux-nfs/YcIjJ4jN3ax1rqaE@debian-BULLSEYE-live-builder-AMD64/raw Grabbing thread from lore.kernel.org/linux-nfs/YcIjJ4jN3ax1rqaE%40debian-BULLSEYE-live-builder-AMD64/t.mbox.gz Analyzing 1 messages in the thread Checking attestation on all messages, may take a moment... --- ✗ [PATCH] nfs: check nf pointer for validity before use --- ✗ BADSIG: DKIM/collabora.com --- Total patches: 1 --- Link: https://lore.kernel.org/r/YcIjJ4jN3ax1rqaE@debian-BULLSEYE-live-builder-AMD64 Base: not specified git am ./20211221_usama_anjum_nfs_check_nf_pointer_for_validity_before_use.mbx [cel@bazille linux]$ The patch is obviously correct, so I applied it despite the attestation failure. > --- > fs/nfsd/nfs4state.c | 10 +++++----- > 1 file changed, 5 insertions(+), 5 deletions(-) > > diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c > index a526d4183348..bdd30988e615 100644 > --- a/fs/nfsd/nfs4state.c > +++ b/fs/nfsd/nfs4state.c > @@ -6947,6 +6947,11 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, > goto out; > } > > + if (!nf) { > + status = nfserr_openmode; > + goto out; > + } > + > /* > * Most filesystems with their own ->lock operations will block > * the nfsd thread waiting to acquire the lock. That leads to > @@ -6957,11 +6962,6 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, > if (nf->nf_file->f_op->lock) > fl_flags &= ~FL_SLEEP; > > - if (!nf) { > - status = nfserr_openmode; > - goto out; > - } > - > nbl = find_or_allocate_block(lock_sop, &fp->fi_fhandle, nn); > if (!nbl) { > dprintk("NFSD: %s: unable to allocate block!\n", __func__); > -- > 2.30.2 > -- Chuck Lever
December 21, 2021 3:00 PM, "Chuck Lever III" <chuck.lever@oracle.com> wrote: > Btw, b4 complained about collabora.com's DKIM: > > [cel@bazille linux]$ b4 am > https://lore.kernel.org/linux-nfs/YcIjJ4jN3ax1rqaE@debian-BULLSEYE-live-builder-AMD64/raw > Grabbing thread from > lore.kernel.org/linux-nfs/YcIjJ4jN3ax1rqaE%40debian-BULLSEYE-live-builder-AMD64/t.mbox.gz > Analyzing 1 messages in the thread > Checking attestation on all messages, may take a moment... > --- > ✗ [PATCH] nfs: check nf pointer for validity before use > --- > ✗ BADSIG: DKIM/collabora.com This is because collabora.com has DKIM canonicalization configured as "c=simple/simple". See my previous message to intel.com for why this should be changed to c=relaxed/simple: https://lore.kernel.org/lkml/20211214150032.nioelgvmase7yyus@meerkat.local/ Hope this helps. -K
On 12/21/21 11:18 PM, Konstantin Ryabitsev wrote: > December 21, 2021 3:00 PM, "Chuck Lever III" <chuck.lever@oracle.com> wrote: >> Btw, b4 complained about collabora.com's DKIM: >> >> [cel@bazille linux]$ b4 am >> https://lore.kernel.org/linux-nfs/YcIjJ4jN3ax1rqaE@debian-BULLSEYE-live-builder-AMD64/raw >> Grabbing thread from >> lore.kernel.org/linux-nfs/YcIjJ4jN3ax1rqaE%40debian-BULLSEYE-live-builder-AMD64/t.mbox.gz >> Analyzing 1 messages in the thread >> Checking attestation on all messages, may take a moment... >> --- >> ✗ [PATCH] nfs: check nf pointer for validity before use >> --- >> ✗ BADSIG: DKIM/collabora.com > > This is because collabora.com has DKIM canonicalization configured as "c=simple/simple". See my previous message to intel.com for why this should be changed to c=relaxed/simple: > > https://lore.kernel.org/lkml/20211214150032.nioelgvmase7yyus@meerkat.local/ Thank you both, Chuck and Konstantin, I have forwarded this conversation to our sysadmin team. Best regards, Tomeu
diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index a526d4183348..bdd30988e615 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -6947,6 +6947,11 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, goto out; } + if (!nf) { + status = nfserr_openmode; + goto out; + } + /* * Most filesystems with their own ->lock operations will block * the nfsd thread waiting to acquire the lock. That leads to @@ -6957,11 +6962,6 @@ nfsd4_lock(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, if (nf->nf_file->f_op->lock) fl_flags &= ~FL_SLEEP; - if (!nf) { - status = nfserr_openmode; - goto out; - } - nbl = find_or_allocate_block(lock_sop, &fp->fi_fhandle, nn); if (!nbl) { dprintk("NFSD: %s: unable to allocate block!\n", __func__);
Pointer nf can be NULL. It should be validated before dereferencing it. Fixes: 8628027ba8 ("nfs: block notification on fs with its own ->lock") Signed-off-by: Muhammad Usama Anjum <usama.anjum@collabora.com> --- fs/nfsd/nfs4state.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-)