allow dma-buf-io ctx reuse across files

include/linux/dma-buf-io.h struct dma_buf_io_ctx { · line 75

[Severity: High]
Can file->f_dma_io_tag contain uninitialized or stale slab data here and in dma_buf_io_ctx_create() in drivers/dma-buf/dma-buf-io.c?

In fs/file_table.c, alloc_empty_file(), alloc_empty_file_noaccount(), and alloc_empty_backing_file() allocate struct file objects from filp_cache and bfilp_cache via kmem_cache_alloc() without __GFP_ZERO. Because those caches use SLAB_TYPESAFE_BY_RCU, init_file() explicitly initializes the fields of struct file on allocation and reuse:

fs/file_table.c:init_file() {
	...
	f->f_iocb_flags = 0;
	f->f_pos	= 0;
	f->f_wb_err	= 0;
	f->f_sb_err	= 0;

	file_ref_init(&f->f_ref, 1);
	return 0;
}

Since init_file() does not zero f->f_dma_io_tag, if a tagged file is closed and its slab object is reused for an unrelated file whose open path does not set f_dma_io_tag, wouldn't the new file retain the previous file's f_dma_io_tag and cause dma_buf_io_file_compatible() to report a match?

include/linux/fs.h struct file { · line 1301

[Severity: Low]
struct file in include/linux/fs.h has a kernel-doc comment block above its definition. Should an @f_dma_io_tag entry be added there as well so scripts/kernel-doc does not warn about an undescribed struct member during documentation or W=1 builds?

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=1

block/fops.c static int blkdev_open(struct inode *inode, struct file *filp) · line 689

[Severity: High]
Can this trigger a use-after-free of bdev when bdev_open() fails?

In blkdev_open(), blkdev_get_no_open() acquires a reference to bdev->bd_device and drops the temporary blockdev_superblock inode reference. If bdev_open() returns an error (for example, when racing with disk or partition removal, or when bdev_disk_changed() drops partitions), blkdev_put_no_open(bdev) calls put_device(&bdev->bd_device) and drops blkdev_open()'s only reference to bdev:

block/fops.c:blkdev_open()

    bdev = blkdev_get_no_open(inode->i_rdev, true);
    ...
    ret = bdev_open(bdev, mode, filp->private_data, NULL, filp);
    if (ret)
        blkdev_put_no_open(bdev);
            put_device(&bdev->bd_device);
                disk_release() / part_release()
                    bdev_drop(bdev);
    filp->f_dma_io_tag = (unsigned long)bdev->bd_disk;

Dereferencing bdev->bd_disk unconditionally after blkdev_put_no_open(bdev) reads from bdev after it may already have been freed. Should blkdev_open() return early on error, or set f_dma_io_tag inside bdev_open() alongside the other bdev_file fields?

[Severity: High]
Also, is it safe to use the raw bdev->bd_disk pointer as f_dma_io_tag without pinning the gendisk for the lifetime of the dma_buf_io_ctx?

When a dmabuf is registered via __io_register_dmabuf(), dma_buf_io_ctx_create() stores file->f_dma_io_tag in ctx->importer_tag and calls into the block layer:

dma_buf_io_ctx_create()

    ctx->importer_tag = file->f_dma_io_tag;
    blkdev_init_dma_buf_io_ctx()
        nvme_init_dma_buf_io_ctx()
            __nvme_init_dma_buf_io_ctx()
                nvme_init_io_ctx_locked()

nvme_init_io_ctx_locked() only takes a reference to struct nvme_ctrl via nvme_get_ctrl(ctrl); neither blkdev_init_dma_buf_io_ctx() nor nvme_init_dma_buf_io_ctx() pins bdev->bd_disk or struct nvme_ns.

Once the registration file is closed (or dropped in __io_register_dmabuf()), if the NVMe namespace is removed while the controller stays live (such as via nvme_ns_remove()), del_gendisk() and put_disk() can free the struct gendisk while ctx remains active with ctx->is_dead still false.

If a new struct gendisk is later allocated at the same address for a different NVMe controller or a non-NVMe block device, opening that device will assign the same address to filp->f_dma_io_tag. Subsequent I/O using the registered dmabuf will pass dma_buf_io_file_compatible() and dispatch a REQ_DMABUF bio carrying nvme_dmabuf_map to the unrelated block device, where a non-NVMe driver will interpret bio->bi_io_vec (aliased with bio->bi_dmabuf_map) as a bio_vec array. Could this cause cross-device DMA or type confusion?

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=2

io_uring/dma-buf.c int __io_register_dmabuf(struct io_ring_ctx *ctx, · line 60

[Severity: Critical]
Does dropping target_file in __io_register_dmabuf() instead of holding it until io_release_dmabuf() leave the struct gendisk pointer stored in ctx->importer_tag unpinned, allowing ABA tag aliasing if the disk is freed?

When a block device is opened, blkdev_open() sets filp->f_dma_io_tag to the raw struct gendisk pointer:

block/fops.c:blkdev_open() {
	...
	filp->f_dma_io_tag = (unsigned long)bdev->bd_disk;
}

During registration, dma_buf_io_ctx_create() saves target_file->f_dma_io_tag into ctx->importer_tag, while nvme_init_dma_buf_io_ctx() -> nvme_init_io_ctx_locked() only calls nvme_get_ctrl(ctrl) without taking a reference on target_file, bdev, struct gendisk, or struct nvme_ns:

drivers/nvme/host/pci-dmabuf.c:nvme_init_io_ctx_locked() {
	...
	nvme_get_ctrl(ctrl);
	list_add(&nvme_ctx->list, &buf_list->ctxs);
}

Previously, keeping bd->target_file until io_release_dmabuf() pinned bdev and bdev->bd_disk for the lifetime of the registered buffer. With fput(target_file) called immediately in __io_register_dmabuf(), closing target_fd and removing the namespace (via nvme_ns_remove() -> del_gendisk() -> nvme_put_ns() -> nvme_free_ns() -> put_disk(ns->disk)) can free the struct gendisk while bd->ctx remains active.

If a new struct gendisk is later allocated at the same address for a different block device (such as another NVMe controller/IOMMU domain or a non-NVMe driver like loop, scsi, virtio_blk, or dm), opening that device will assign the same f_dma_io_tag address. Subsequent IORING_OP_READ_FIXED or IORING_OP_WRITE_FIXED requests on the new file will then pass dma_buf_io_file_compatible() in io_import_dmabuf_map() and submit REQ_DMABUF bios (where bio->bi_dmabuf_map aliases bio->bi_io_vec with bi_max_vecs == 0) to an incompatible device or driver.

io_uring/dma-buf.h static inline int io_import_dmabuf_map(struct io_kiocb *req, · line 69

[Severity: Critical]
Can dma_buf_io_file_compatible() in io_import_dmabuf_map() match unrelated files due to uninitialized f_dma_io_tag in init_file()?

In fs/file_table.c, alloc_empty_file() and alloc_empty_file_noaccount() allocate struct file objects from filp_cache (which uses SLAB_TYPESAFE_BY_RCU without __GFP_ZERO or a slab constructor), and init_file() initializes fields individually without clearing f->f_dma_io_tag:

fs/file_table.c:init_file() {
	...
	f->f_iocb_flags = 0;
	f->f_pos	= 0;
	f->f_wb_err	= 0;
	f->f_sb_err	= 0;

	file_ref_init(&f->f_ref, 1);
	return 0;
}

When a block device file is closed (including target_file after __io_register_dmabuf() calls fput(target_file)), its struct file is returned to filp_cache still holding its stale f_dma_io_tag value. If that struct file is recycled for a non-block file (for example, an O_DIRECT regular file on a filesystem backed by loop, scsi, virtio_blk, dm, or another NVMe controller), req->file->f_dma_io_tag will still equal ctx->importer_tag.

Wouldn't dma_buf_io_file_compatible() then return true in io_import_dmabuf_map(), allowing ITER_DMABUF_MAP / REQ_DMABUF bios (with bio->bi_io_vec aliased to struct dma_buf_io_map *) to be submitted to incompatible filesystems and block drivers?

[Severity: High]
Also related to how f_dma_io_tag is populated for dma_buf_io_file_compatible() in this series, in block/fops.c:blkdev_open():

block/fops.c:blkdev_open() {
	...
	ret = bdev_open(bdev, mode, filp->private_data, NULL, filp);
	if (ret)
		blkdev_put_no_open(bdev);
	filp->f_dma_io_tag = (unsigned long)bdev->bd_disk;
	return ret;
}

When bdev_open() fails, blkdev_put_no_open(bdev) drops the reference on bdev acquired by blkdev_get_no_open(). Doesn't setting filp->f_dma_io_tag = (unsigned long)bdev->bd_disk right after blkdev_put_no_open(bdev) cause a use-after-free read of bdev?

Sashiko AI review · https://sashiko.dev/#/patchset/[email protected]?part=4