Skip to content
  1. Feb 12, 2022
    • Kumar Kartikeya Dwivedi's avatar
      bpf: Fix crash due to incorrect copy_map_value · a8abb0c3
      Kumar Kartikeya Dwivedi authored
      When both bpf_spin_lock and bpf_timer are present in a BPF map value,
      copy_map_value needs to skirt both objects when copying a value into and
      out of the map. However, the current code does not set both s_off and
      t_off in copy_map_value, which leads to a crash when e.g. bpf_spin_lock
      is placed in map value with bpf_timer, as bpf_map_update_elem call will
      be able to overwrite the other timer object.
      
      When the issue is not fixed, an overwriting can produce the following
      splat:
      
      [root@(none) bpf]# ./test_progs -t timer_crash
      [   15.930339] bpf_testmod: loading out-of-tree module taints kernel.
      [   16.037849] ==================================================================
      [   16.038458] BUG: KASAN: user-memory-access in __pv_queued_spin_lock_slowpath+0x32b/0x520
      [   16.038944] Write of size 8 at addr 0000000000043ec0 by task test_progs/325
      [   16.039399]
      [   16.039514] CPU: 0 PID: 325 Comm: test_progs Tainted: G           OE     5.16.0+ #278
      [   16.039983] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ArchLinux 1.15.0-1 04/01/2014
      [   16.040485] Call Trace:
      [   16.040645]  <TASK>
      [   16.040805]  dump_stack_lvl+0x59/0x73
      [   16.041069]  ? __pv_queued_spin_lock_slowpath+0x32b/0x520
      [   16.041427]  kasan_report.cold+0x116/0x11b
      [   16.041673]  ? __pv_queued_spin_lock_slowpath+0x32b/0x520
      [   16.042040]  __pv_queued_spin_lock_slowpath+0x32b/0x520
      [   16.042328]  ? memcpy+0x39/0x60
      [   16.042552]  ? pv_hash+0xd0/0xd0
      [   16.042785]  ? lockdep_hardirqs_off+0x95/0xd0
      [   16.043079]  __bpf_spin_lock_irqsave+0xdf/0xf0
      [   16.043366]  ? bpf_get_current_comm+0x50/0x50
      [   16.043608]  ? jhash+0x11a/0x270
      [   16.043848]  bpf_timer_cancel+0x34/0xe0
      [   16.044119]  bpf_prog_c4ea1c0f7449940d_sys_enter+0x7c/0x81
      [   16.044500]  bpf_trampoline_6442477838_0+0x36/0x1000
      [   16.044836]  __x64_sys_nanosleep+0x5/0x140
      [   16.045119]  do_syscall_64+0x59/0x80
      [   16.045377]  ? lock_is_held_type+0xe4/0x140
      [   16.045670]  ? irqentry_exit_to_user_mode+0xa/0x40
      [   16.046001]  ? mark_held_locks+0x24/0x90
      [   16.046287]  ? asm_exc_page_fault+0x1e/0x30
      [   16.046569]  ? asm_exc_page_fault+0x8/0x30
      [   16.046851]  ? lockdep_hardirqs_on+0x7e/0x100
      [   16.047137]  entry_SYSCALL_64_after_hwframe+0x44/0xae
      [   16.047405] RIP: 0033:0x7f9e4831718d
      [   16.047602] Code: b4 0c 00 0f 05 eb a9 66 0f 1f 44 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d b3 6c 0c 00 f7 d8 64 89 01 48
      [   16.048764] RSP: 002b:00007fff488086b8 EFLAGS: 00000206 ORIG_RAX: 0000000000000023
      [   16.049275] RAX: ffffffffffffffda RBX: 00007f9e48683740 RCX: 00007f9e4831718d
      [   16.049747] RDX: 0000000000000000 RSI: 0000000000000000 RDI: 00007fff488086d0
      [   16.050225] RBP: 00007fff488086f0 R08: 00007fff488085d7 R09: 00007f9e4cb594a0
      [   16.050648] R10: 0000000000000000 R11: 0000000000000206 R12: 00007f9e484cde30
      [   16.051124] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
      [   16.051608]  </TASK>
      [   16.051762] ==================================================================
      
      Fixes: 68134668
      
       ("bpf: Add map side support for bpf timers.")
      Signed-off-by: default avatarKumar Kartikeya Dwivedi <memxor@gmail.com>
      Signed-off-by: default avatarAlexei Starovoitov <ast@kernel.org>
      Link: https://lore.kernel.org/bpf/20220209070324.1093182-2-memxor@gmail.com
      a8abb0c3
  2. Feb 11, 2022
  3. Feb 10, 2022
  4. Feb 09, 2022
    • Chuck Lever's avatar
      NFSD: Deprecate NFS_OFFSET_MAX · c306d737
      Chuck Lever authored
      
      
      NFS_OFFSET_MAX was introduced way back in Linux v2.3.y before there
      was a kernel-wide OFFSET_MAX value. As a clean up, replace the last
      few uses of it with its generic equivalent, and get rid of it.
      
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      c306d737
    • Chuck Lever's avatar
      NFSD: Fix offset type in I/O trace points · 6a4d333d
      Chuck Lever authored
      
      
      NFSv3 and NFSv4 use u64 offset values on the wire. Record these values
      verbatim without the implicit type case to loff_t.
      
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      6a4d333d
    • Chuck Lever's avatar
      NFSD: COMMIT operations must not return NFS?ERR_INVAL · 3f965021
      Chuck Lever authored
      
      
      Since, well, forever, the Linux NFS server's nfsd_commit() function
      has returned nfserr_inval when the passed-in byte range arguments
      were non-sensical.
      
      However, according to RFC 1813 section 3.3.21, NFSv3 COMMIT requests
      are permitted to return only the following non-zero status codes:
      
            NFS3ERR_IO
            NFS3ERR_STALE
            NFS3ERR_BADHANDLE
            NFS3ERR_SERVERFAULT
      
      NFS3ERR_INVAL is not included in that list. Likewise, NFS4ERR_INVAL
      is not listed in the COMMIT row of Table 6 in RFC 8881.
      
      RFC 7530 does permit COMMIT to return NFS4ERR_INVAL, but does not
      specify when it can or should be used.
      
      Instead of dropping or failing a COMMIT request in a byte range that
      is not supported, turn it into a valid request by treating one or
      both arguments as zero. Offset zero means start-of-file, count zero
      means until-end-of-file, so we only ever extend the commit range.
      NFS servers are always allowed to commit more and sooner than
      requested.
      
      The range check is no longer bounded by NFS_OFFSET_MAX, but rather
      by the value that is returned in the maxfilesize field of the NFSv3
      FSINFO procedure or the NFSv4 maxfilesize file attribute.
      
      Note that this change results in a new pynfs failure:
      
      CMT4     st_commit.testCommitOverflow                             : RUNNING
      CMT4     st_commit.testCommitOverflow                             : FAILURE
                 COMMIT with offset + count overflow should return
                 NFS4ERR_INVAL, instead got NFS4_OK
      
      IMO the test is not correct as written: RFC 8881 does not allow the
      COMMIT operation to return NFS4ERR_INVAL.
      
      Reported-by: default avatarDan Aloni <dan.aloni@vastdata.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      Reviewed-by: default avatarBruce Fields <bfields@fieldses.org>
      3f965021
    • Chuck Lever's avatar
      NFSD: Clamp WRITE offsets · 6260d9a5
      Chuck Lever authored
      
      
      Ensure that a client cannot specify a WRITE range that falls in a
      byte range outside what the kernel's internal types (such as loff_t,
      which is signed) can represent. The kiocb iterators, invoked in
      nfsd_vfs_write(), should properly limit write operations to within
      the underlying file system's s_maxbytes.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      6260d9a5
    • Chuck Lever's avatar
      NFSD: Fix NFSv3 SETATTR/CREATE's handling of large file sizes · a648fdeb
      Chuck Lever authored
      
      
      iattr::ia_size is a loff_t, so these NFSv3 procedures must be
      careful to deal with incoming client size values that are larger
      than s64_max without corrupting the value.
      
      Silently capping the value results in storing a different value
      than the client passed in which is unexpected behavior, so remove
      the min_t() check in decode_sattr3().
      
      Note that RFC 1813 permits only the WRITE procedure to return
      NFS3ERR_FBIG. We believe that NFSv3 reference implementations
      also return NFS3ERR_FBIG when ia_size is too large.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      a648fdeb
    • Chuck Lever's avatar
      NFSD: Fix ia_size underflow · e6faac3f
      Chuck Lever authored
      
      
      iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and
      NFSv4 both define file size as an unsigned 64-bit type. Thus there
      is a range of valid file size values an NFS client can send that is
      already larger than Linux can handle.
      
      Currently decode_fattr4() dumps a full u64 value into ia_size. If
      that value happens to be larger than S64_MAX, then ia_size
      underflows. I'm about to fix up the NFSv3 behavior as well, so let's
      catch the underflow in the common code path: nfsd_setattr().
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarChuck Lever <chuck.lever@oracle.com>
      e6faac3f