1. 13 9月, 2016 1 次提交
    • C
      svcauth_gss: Revert 64c59a37 ("Remove unnecessary allocation") · bf2c4b6f
      Chuck Lever 提交于
      rsc_lookup steals the passed-in memory to avoid doing an allocation of
      its own, so we can't just pass in a pointer to memory that someone else
      is using.
      
      If we really want to avoid allocation there then maybe we should
      preallocate somwhere, or reference count these handles.
      
      For now we should revert.
      
      On occasion I see this on my server:
      
      kernel: kernel BUG at /home/cel/src/linux/linux-2.6/mm/slub.c:3851!
      kernel: invalid opcode: 0000 [#1] SMP
      kernel: Modules linked in: cts rpcsec_gss_krb5 sb_edac edac_core x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd btrfs xor iTCO_wdt iTCO_vendor_support raid6_pq pcspkr i2c_i801 i2c_smbus lpc_ich mfd_core mei_me sg mei shpchp wmi ioatdma ipmi_si ipmi_msghandler acpi_pad acpi_power_meter rpcrdma ib_ipoib rdma_ucm ib_ucm ib_uverbs ib_umad rdma_cm ib_cm iw_cm nfsd nfs_acl lockd grace auth_rpcgss sunrpc ip_tables xfs libcrc32c mlx4_ib mlx4_en ib_core sr_mod cdrom sd_mod ast drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm drm crc32c_intel igb mlx4_core ahci libahci libata ptp pps_core dca i2c_algo_bit i2c_core dm_mirror dm_region_hash dm_log dm_mod
      kernel: CPU: 7 PID: 145 Comm: kworker/7:2 Not tainted 4.8.0-rc4-00006-g9d06b0b #15
      kernel: Hardware name: Supermicro Super Server/X10SRL-F, BIOS 1.0c 09/09/2015
      kernel: Workqueue: events do_cache_clean [sunrpc]
      kernel: task: ffff8808541d8000 task.stack: ffff880854344000
      kernel: RIP: 0010:[<ffffffff811e7075>]  [<ffffffff811e7075>] kfree+0x155/0x180
      kernel: RSP: 0018:ffff880854347d70  EFLAGS: 00010246
      kernel: RAX: ffffea0020fe7660 RBX: ffff88083f9db064 RCX: 146ff0f9d5ec5600
      kernel: RDX: 000077ff80000000 RSI: ffff880853f01500 RDI: ffff88083f9db064
      kernel: RBP: ffff880854347d88 R08: ffff8808594ee000 R09: ffff88087fdd8780
      kernel: R10: 0000000000000000 R11: ffffea0020fe76c0 R12: ffff880853f01500
      kernel: R13: ffffffffa013cf76 R14: ffffffffa013cff0 R15: ffffffffa04253a0
      kernel: FS:  0000000000000000(0000) GS:ffff88087fdc0000(0000) knlGS:0000000000000000
      kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      kernel: CR2: 00007fed60b020c3 CR3: 0000000001c06000 CR4: 00000000001406e0
      kernel: Stack:
      kernel: ffff8808589f2f00 ffff880853f01500 0000000000000001 ffff880854347da0
      kernel: ffffffffa013cf76 ffff8808589f2f00 ffff880854347db8 ffffffffa013d006
      kernel: ffff8808589f2f20 ffff880854347e00 ffffffffa0406f60 0000000057c7044f
      kernel: Call Trace:
      kernel: [<ffffffffa013cf76>] rsc_free+0x16/0x90 [auth_rpcgss]
      kernel: [<ffffffffa013d006>] rsc_put+0x16/0x30 [auth_rpcgss]
      kernel: [<ffffffffa0406f60>] cache_clean+0x2e0/0x300 [sunrpc]
      kernel: [<ffffffffa04073ee>] do_cache_clean+0xe/0x70 [sunrpc]
      kernel: [<ffffffff8109a70f>] process_one_work+0x1ff/0x3b0
      kernel: [<ffffffff8109b15c>] worker_thread+0x2bc/0x4a0
      kernel: [<ffffffff8109aea0>] ? rescuer_thread+0x3a0/0x3a0
      kernel: [<ffffffff810a0ba4>] kthread+0xe4/0xf0
      kernel: [<ffffffff8169c47f>] ret_from_fork+0x1f/0x40
      kernel: [<ffffffff810a0ac0>] ? kthread_stop+0x110/0x110
      kernel: Code: f7 ff ff eb 3b 65 8b 05 da 30 e2 7e 89 c0 48 0f a3 05 a0 38 b8 00 0f 92 c0 84 c0 0f 85 d1 fe ff ff 0f 1f 44 00 00 e9 f5 fe ff ff <0f> 0b 49 8b 03 31 f6 f6 c4 40 0f 85 62 ff ff ff e9 61 ff ff ff
      kernel: RIP  [<ffffffff811e7075>] kfree+0x155/0x180
      kernel: RSP <ffff880854347d70>
      kernel: ---[ end trace 3fdec044969def26 ]---
      
      It seems to be most common after a server reboot where a client has been
      using a Kerberos mount, and reconnects to continue its workload.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      bf2c4b6f
  2. 14 7月, 2016 1 次提交
  3. 23 5月, 2016 1 次提交
    • T
      sunrpc: fix stripping of padded MIC tokens · c0cb8bf3
      Tomáš Trnka 提交于
      The length of the GSS MIC token need not be a multiple of four bytes.
      It is then padded by XDR to a multiple of 4 B, but unwrap_integ_data()
      would previously only trim mic.len + 4 B. The remaining up to three
      bytes would then trigger a check in nfs4svc_decode_compoundargs(),
      leading to a "garbage args" error and mount failure:
      
      nfs4svc_decode_compoundargs: compound not properly padded!
      nfsd: failed to decode arguments!
      
      This would prevent older clients using the pre-RFC 4121 MIC format
      (37-byte MIC including a 9-byte OID) from mounting exports from v3.9+
      servers using krb5i.
      
      The trimming was introduced by commit 4c190e2f ("sunrpc: trim off
      trailing checksum before returning decrypted or integrity authenticated
      buffer").
      
      Fixes: 4c190e2f "unrpc: trim off trailing checksum..."
      Signed-off-by: NTomáš Trnka <ttrnka@mail.muni.cz>
      Cc: stable@vger.kernel.org
      Acked-by: NJeff Layton <jlayton@poochiereds.net>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      c0cb8bf3
  4. 04 5月, 2016 1 次提交
  5. 27 2月, 2015 1 次提交
  6. 10 12月, 2014 1 次提交
  7. 25 11月, 2014 1 次提交
  8. 23 6月, 2014 1 次提交
  9. 31 5月, 2014 1 次提交
  10. 08 1月, 2014 1 次提交
  11. 07 1月, 2014 3 次提交
  12. 09 10月, 2013 1 次提交
  13. 01 8月, 2013 1 次提交
  14. 02 7月, 2013 2 次提交
  15. 29 6月, 2013 1 次提交
  16. 29 5月, 2013 1 次提交
  17. 13 5月, 2013 1 次提交
  18. 01 5月, 2013 1 次提交
  19. 30 4月, 2013 1 次提交
  20. 26 4月, 2013 2 次提交
  21. 30 3月, 2013 1 次提交
    • C
      SUNRPC: Consider qop when looking up pseudoflavors · 83523d08
      Chuck Lever 提交于
      The NFSv4 SECINFO operation returns a list of security flavors that
      the server supports for a particular share.  An NFSv4 client is
      supposed to pick a pseudoflavor it supports that corresponds to one
      of the flavors returned by the server.
      
      GSS flavors in this list have a GSS tuple that identify a specific
      GSS pseudoflavor.
      
      Currently our client ignores the GSS tuple's "qop" value.  A
      matching pseudoflavor is chosen based only on the OID and service
      value.
      
      So far this omission has not had much effect on Linux.  The NFSv4
      protocol currently supports only one qop value: GSS_C_QOP_DEFAULT,
      also known as zero.
      
      However, if an NFSv4 server happens to return something other than
      zero in the qop field, our client won't notice.  This could cause
      the client to behave in incorrect ways that could have security
      implications.
      Signed-off-by: NChuck Lever <chuck.lever@oracle.com>
      Signed-off-by: NTrond Myklebust <Trond.Myklebust@netapp.com>
      83523d08
  22. 06 3月, 2013 1 次提交
    • J
      nfsd: fix krb5 handling of anonymous principals · 3c34ae11
      J. Bruce Fields 提交于
      krb5 mounts started failing as of
      683428fa "sunrpc: Update svcgss xdr
      handle to rpsec_contect cache".
      
      The problem is that mounts are usually done with some host principal
      which isn't normally mapped to any user, in which case svcgssd passes
      down uid -1, which the kernel is then expected to map to the
      export-specific anonymous uid or gid.
      
      The new uid_valid/gid_valid checks were therefore causing that downcall
      to fail.
      
      (Note the regression may not have been seen with older userspace that
      tended to map unknown principals to an anonymous id on their own rather
      than leaving it to the kernel.)
      Reviewed-by: N"Eric W. Biederman" <ebiederm@xmission.com>
      Signed-off-by: NJ. Bruce Fields <bfields@redhat.com>
      3c34ae11
  23. 15 2月, 2013 2 次提交
  24. 13 2月, 2013 1 次提交
  25. 09 2月, 2013 1 次提交
    • J
      sunrpc: trim off trailing checksum before returning decrypted or integrity authenticated buffer · 4c190e2f
      Jeff Layton 提交于
      When GSSAPI integrity signatures are in use, or when we're using GSSAPI
      privacy with the v2 token format, there is a trailing checksum on the
      xdr_buf that is returned.
      
      It's checked during the authentication stage, and afterward nothing
      cares about it. Ordinarily, it's not a problem since the XDR code
      generally ignores it, but it will be when we try to compute a checksum
      over the buffer to help prevent XID collisions in the duplicate reply
      cache.
      
      Fix the code to trim off the checksums after verifying them. Note that
      in unwrap_integ_data, we must avoid trying to reverify the checksum if
      the request was deferred since it will no longer be present when it's
      revisited.
      Signed-off-by: NJeff Layton <jlayton@redhat.com>
      4c190e2f
  26. 01 6月, 2012 2 次提交
  27. 03 5月, 2012 1 次提交
  28. 26 4月, 2012 1 次提交
  29. 01 2月, 2012 1 次提交
  30. 31 3月, 2011 1 次提交
  31. 18 12月, 2010 1 次提交
  32. 22 9月, 2010 2 次提交
  33. 15 5月, 2010 1 次提交