1. 01 Dec, 2023 1 commit
  2. 29 Nov, 2023 1 commit
  3. 28 Nov, 2023 2 commits
  4. 24 Nov, 2023 1 commit
    • Markus Weippert's avatar
      bcache: revert replacing IS_ERR_OR_NULL with IS_ERR · bb6cc253
      Markus Weippert authored
      Commit 028ddcac ("bcache: Remove unnecessary NULL point check in
      node allocations") replaced IS_ERR_OR_NULL by IS_ERR. This leads to a
      NULL pointer dereference.
      
      BUG: kernel NULL pointer dereference, address: 0000000000000080
      Call Trace:
       ? __die_body.cold+0x1a/0x1f
       ? page_fault_oops+0xd2/0x2b0
       ? exc_page_fault+0x70/0x170
       ? asm_exc_page_fault+0x22/0x30
       ? btree_node_free+0xf/0x160 [bcache]
       ? up_write+0x32/0x60
       btree_gc_coalesce+0x2aa/0x890 [bcache]
       ? bch_extent_bad+0x70/0x170 [bcache]
       btree_gc_recurse+0x130/0x390 [bcache]
       ? btree_gc_mark_node+0x72/0x230 [bcache]
       bch_btree_gc+0x5da/0x600 [bcache]
       ? cpuusage_read+0x10/0x10
       ? bch_btree_gc+0x600/0x600 [bcache]
       bch_gc_thread+0x135/0x180 [bcache]
      
      The relevant code starts with:
      
          new_nodes[0] = NULL;
      
          for (i = 0; i < nodes; i++) {
              if (__bch_keylist_realloc(&keylist, bkey_u64s(&r[i].b->key)))
                  goto out_nocoalesce;
          // ...
      out_nocoalesce:
          // ...
          for (i = 0; i < nodes; i++)
              if (!IS_ERR(new_nodes[i])) {  // IS_ERR_OR_NULL before
      028ddcac
                  btree_node_free(new_nodes[i]);  // new_nodes[0] is NULL
                  rw_unlock(true, new_nodes[i]);
              }
      
      This patch replaces IS_ERR() by IS_ERR_OR_NULL() to fix this.
      
      Fixes: 028ddcac ("bcache: Remove unnecessary NULL point check in node allocations")
      Link: https://lore.kernel.org/all/3DF4A87A-2AC1-4893-AE5F-E921478419A9@suse.de/
      Cc: stable@vger.kernel.org
      Cc: Zheng Wang <zyytlz.wz@163.com>
      Cc: Coly Li <colyli@suse.de>
      Signed-off-by: default avatarMarkus Weippert <markus@gekmihesg.de>
      Signed-off-by: default avatarJens Axboe <axboe@kernel.dk>
      bb6cc253
  5. 23 Nov, 2023 3 commits
    • Arnd Bergmann's avatar
      nvme: tcp: fix compile-time checks for TLS mode · 0e6c4fe7
      Arnd Bergmann authored
      When CONFIG_NVME_KEYRING is enabled as a loadable module, but the TCP
      host code is built-in, it fails to link:
      
      arm-linux-gnueabi-ld: drivers/nvme/host/tcp.o: in function `nvme_tcp_setup_ctrl':
      tcp.c:(.text+0x1940): undefined reference to `nvme_tls_psk_default'
      
      The problem is that the compile-time conditionals are inconsistent here,
      using a mix of #ifdef CONFIG_NVME_TCP_TLS, IS_ENABLED(CONFIG_NVME_TCP_TLS)
      and IS_ENABLED(CONFIG_NVME_KEYRING) checks, with CONFIG_NVME_KEYRING
      controlling whether the implementation is actually built.
      
      Change it to use IS_ENABLED(CONFIG_NVME_KEYRING) checks consistently,
      which should help readability and make it less error-prone. Combining
      it with the check for the ctrl->opts->tls flag lets the compiler drop
      all the TLS code in configurations without this feature, which also
      helps runtime behavior in addition to avoiding the link failure.
      
      To make it possible for the compiler to build the dead code, both
      the tls_handshake_timeout variable and the TLS specific members
      of nvme_tcp_queue need to be moved out of the #ifdef block as well,
      but at least the former of these gets optimized out again.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20231122224719.4042108-4-arnd@kernel.orgSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      0e6c4fe7
    • Arnd Bergmann's avatar
      nvme: target: fix Kconfig select statements · 65e2a74c
      Arnd Bergmann authored
      When the NVME target code is built-in but its TCP frontend is a loadable
      module, enabling keyring support causes a link failure:
      
      x86_64-linux-ld: vmlinux.o: in function `nvmet_ports_make':
      configfs.c:(.text+0x100a2110): undefined reference to `nvme_keyring_id'
      
      The problem is that CONFIG_NVME_TARGET_TCP_TLS is a 'bool' symbol that
      depends on the tristate CONFIG_NVME_TARGET_TCP, so any 'select' from
      it inherits the state of the tristate symbol rather than the intended
      CONFIG_NVME_TARGET one that contains the actual call.
      
      The same thing is true for CONFIG_KEYS, which itself is required for
      NVME_KEYRING.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20231122224719.4042108-3-arnd@kernel.orgSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      65e2a74c
    • Arnd Bergmann's avatar
      nvme: target: fix nvme_keyring_id() references · d78abcba
      Arnd Bergmann authored
      In configurations without CONFIG_NVME_TARGET_TCP_TLS, the keyring
      code might not be available, or using it will result in a runtime
      failure:
      
      x86_64-linux-ld: vmlinux.o: in function `nvmet_ports_make':
      configfs.c:(.text+0x100a2110): undefined reference to `nvme_keyring_id'
      
      Add a check to ensure we only check the keyring if there is a chance
      of it being used, which avoids both the runtime and link-time
      problems.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Link: https://lore.kernel.org/r/20231122224719.4042108-2-arnd@kernel.orgSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      d78abcba
  6. 22 Nov, 2023 2 commits
  7. 21 Nov, 2023 1 commit
    • Li Nan's avatar
      nbd: pass nbd_sock to nbd_read_reply() instead of index · 98c598af
      Li Nan authored
      If a socket is processing ioctl 'NBD_SET_SOCK', config->socks might be
      krealloc in nbd_add_socket(), and a garbage request is received now, a UAF
      may occurs.
      
        T1
        nbd_ioctl
         __nbd_ioctl
          nbd_add_socket
           blk_mq_freeze_queue
      				T2
        				recv_work
        				 nbd_read_reply
        				  sock_xmit
           krealloc config->socks
      				   def config->socks
      
      Pass nbd_sock to nbd_read_reply(). And introduce a new function
      sock_xmit_recv(), which differs from sock_xmit only in the way it get
      socket.
      
      ==================================================================
      BUG: KASAN: use-after-free in sock_xmit+0x525/0x550
      Read of size 8 at addr ffff8880188ec428 by task kworker/u12:1/18779
      
      Workqueue: knbd4-recv recv_work
      Call Trace:
       __dump_stack
       dump_stack+0xbe/0xfd
       print_address_description.constprop.0+0x19/0x170
       __kasan_report.cold+0x6c/0x84
       kasan_report+0x3a/0x50
       sock_xmit+0x525/0x550
       nbd_read_reply+0xfe/0x2c0
       recv_work+0x1c2/0x750
       process_one_work+0x6b6/0xf10
       worker_thread+0xdd/0xd80
       kthread+0x30a/0x410
       ret_from_fork+0x22/0x30
      
      Allocated by task 18784:
       kasan_save_stack+0x1b/0x40
       kasan_set_track
       set_alloc_info
       __kasan_kmalloc
       __kasan_kmalloc.constprop.0+0xf0/0x130
       slab_post_alloc_hook
       slab_alloc_node
       slab_alloc
       __kmalloc_track_caller+0x157/0x550
       __do_krealloc
       krealloc+0x37/0xb0
       nbd_add_socket
       +0x2d3/0x880
       __nbd_ioctl
       nbd_ioctl+0x584/0x8e0
       __blkdev_driver_ioctl
       blkdev_ioctl+0x2a0/0x6e0
       block_ioctl+0xee/0x130
       vfs_ioctl
       __do_sys_ioctl
       __se_sys_ioctl+0x138/0x190
       do_syscall_64+0x33/0x40
       entry_SYSCALL_64_after_hwframe+0x61/0xc6
      
      Freed by task 18784:
       kasan_save_stack+0x1b/0x40
       kasan_set_track+0x1c/0x30
       kasan_set_free_info+0x20/0x40
       __kasan_slab_free.part.0+0x13f/0x1b0
       slab_free_hook
       slab_free_freelist_hook
       slab_free
       kfree+0xcb/0x6c0
       krealloc+0x56/0xb0
       nbd_add_socket+0x2d3/0x880
       __nbd_ioctl
       nbd_ioctl+0x584/0x8e0
       __blkdev_driver_ioctl
       blkdev_ioctl+0x2a0/0x6e0
       block_ioctl+0xee/0x130
       vfs_ioctl
       __do_sys_ioctl
       __se_sys_ioctl+0x138/0x190
       do_syscall_64+0x33/0x40
       entry_SYSCALL_64_after_hwframe+0x61/0xc6
      Signed-off-by: default avatarLi Nan <linan122@huawei.com>
      Reviewed-by: default avatarYu Kuai <yukuai3@huawei.com>
      Reviewed-by: default avatarMing Lei <ming.lei@redhat.com>
      Link: https://lore.kernel.org/r/20230911023308.3467802-1-linan666@huaweicloud.comSigned-off-by: default avatarJens Axboe <axboe@kernel.dk>
      98c598af
  8. 20 Nov, 2023 26 commits
  9. 17 Nov, 2023 3 commits