Skip to content

L
linux
Switch branch/tag
  1. 17 Apr, 2023 1 commit
    • Chuck Lever's avatar
      SUNRPC: Fix failures of checksum Kunit tests · d5142519
      Chuck Lever authored 
      Scott reports that when the new GSS krb5 Kunit tests are built as
a separate module and loaded, the RFC 6803 and RFC 8009 checksum
tests all fail, even though they pass when run under kunit.py.

It appears that passing a buffer backed by static const memory to
gss_krb5_checksum() is a problem. A printk in checksum_case() shows
the correct plaintext, but by the time the buffer has been converted
to a scatterlist and arrives at checksummer(), it contains all
zeroes.

Replacing this buffer with one that is dynamically allocated fixes
the issue.
Reported-by: default avatarScott Mayhew <smayhew@redhat.com>
Fixes: 02142b2c ("SUNRPC: Add checksum KUnit tests for the RFC 6803 encryption types")
Tested-by: default avatarScott Mayhew <smayhew@redhat.com>
Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      d5142519
  3. 13 Apr, 2023 1 commit
  5. 04 Apr, 2023 3 commits
  7. 31 Mar, 2023 2 commits
  9. 22 Mar, 2023 1 commit
    • Chuck Lever's avatar
      SUNRPC: Fix a crash in gss_krb5_checksum() · 5f24a872
      Chuck Lever authored 
      Anna says:
> KASAN reports [...] a slab-out-of-bounds in gss_krb5_checksum(),
> and it can cause my client to panic when running cthon basic
> tests with krb5p.

> Running faddr2line gives me:
>
> gss_krb5_checksum+0x4b6/0x630:
> ahash_request_free at
> /home/anna/Programs/linux-nfs.git/./include/crypto/hash.h:619
> (inlined by) gss_krb5_checksum at
> /home/anna/Programs/linux-nfs.git/net/sunrpc/auth_gss/gss_krb5_crypto.c:358

My diagnosis is that the memcpy() at the end of gss_krb5_checksum()
reads past the end of the buffer containing the checksum data
because the callers have ignored gss_krb5_checksum()'s API contract:

 * Caller provides the truncation length of the output token (h) in
 * cksumout.len.

Instead they provide the fixed length of the hmac buffer. This
length happens to be larger than the value returned by
crypto_ahash_digestsize().

Change these errant callers to work like krb5_etm_{en,de}crypt().
As a defensive measure, bound the length of the byte copy at the
end of gss_krb5_checksum().

Kunit sez:
Testing complete. Ran 68 tests: passed: 68
Elapsed time: 81.680s total, 5.875s configuring, 75.610s building, 0.103s running
Reported-by: default avatarAnna Schumaker <schumaker.anna@gmail.com>
Fixes: 8270dbfc ("SUNRPC: Obscure Kerberos integrity keys")
Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      5f24a872
  11. 17 Mar, 2023 1 commit
    • Jeff Layton's avatar
      nfsd: don't replace page in rq_pages if it's a continuation of last page · 27c934dd
      Jeff Layton authored 
      The splice read calls nfsd_splice_actor to put the pages containing file
data into the svc_rqst->rq_pages array. It's possible however to get a
splice result that only has a partial page at the end, if (e.g.) the
filesystem hands back a short read that doesn't cover the whole page.

nfsd_splice_actor will plop the partial page into its rq_pages array and
return. Then later, when nfsd_splice_actor is called again, the
remainder of the page may end up being filled out. At this point,
nfsd_splice_actor will put the page into the array _again_ corrupting
the reply. If this is done enough times, rq_next_page will overrun the
array and corrupt the trailing fields -- the rq_respages and
rq_next_page pointers themselves.

If we've already added the page to the array in the last pass, don't add
it to the array a second time when dealing with a splice continuation.
This was originally handled properly in nfsd_splice_actor, but commit
91e23b1c ("NFSD: Clean up nfsd_splice_actor()") removed the check
for it.

Fixes: 91e23b1c ("NFSD: Clean up nfsd_splice_actor()")
Cc: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: default avatarDario Lesca <d.lesca@solinos.it>
Tested-by: default avatarDavid Critch <dcritch@redhat.com>
Link: https://bugzilla.redhat.com/show_bug.cgi?id=2150630Signed-off-by: default avatarJeff Layton <jlayton@kernel.org>
Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      27c934dd
  13. 10 Mar, 2023 1 commit
    • Chuck Lever's avatar
      NFS & NFSD: Update GSS dependencies · e57d0652
      Chuck Lever authored 
      Geert reports that:
> On v6.2, "make ARCH=m68k defconfig" gives you
> CONFIG_RPCSEC_GSS_KRB5=m
> On v6.3, it became builtin, due to dropping the dependencies on
> the individual crypto modules.
>
> $ grep -E "CRYPTO_(MD5|DES|CBC|CTS|ECB|HMAC|SHA1|AES)" .config
> CONFIG_CRYPTO_AES=y
> CONFIG_CRYPTO_AES_TI=m
> CONFIG_CRYPTO_DES=m
> CONFIG_CRYPTO_CBC=m
> CONFIG_CRYPTO_CTS=m
> CONFIG_CRYPTO_ECB=m
> CONFIG_CRYPTO_HMAC=m
> CONFIG_CRYPTO_MD5=m
> CONFIG_CRYPTO_SHA1=m

This behavior is triggered by the "default y" in the definition of
RPCSEC_GSS.

The "default y" was added in 2010 by commit df486a25 ("NFS: Fix
the selection of security flavours in Kconfig"). However,
svc_gss_principal was removed in 2012 by commit 03a4e1f6
("nfsd4: move principal name into svc_cred"), so the 2010 fix is
no longer necessary. We can safely change the NFS_V4 and NFSD_V4
dependencies back to RPCSEC_GSS_KRB5 to get the nicer v6.2
behavior back.

Selecting KRB5 symbolically represents the true requirement here:
that all spec-compliant NFSv4 implementations must have Kerberos
available to use.
Reported-by: default avatarGeert Uytterhoeven <geert@linux-m68k.org>
Fixes: dfe9a123 ("SUNRPC: Enable rpcsec_gss_krb5.ko to be built without CRYPTO_DES")
Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      e57d0652
  15. 08 Mar, 2023 1 commit
  17. 07 Mar, 2023 1 commit
  19. 27 Feb, 2023 2 commits
  21. 20 Feb, 2023 26 commits
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7