- 24 Sep, 2024 1 commit
-
-
Miklos Szeredi authored
The (!fiq->connected) check was moved into the queuing method resulting in the following: Fixes: 5de8acb4 ("fuse: cleanup request queuing towards virtiofs") Reported-by:
Lai, Yi <yi1.lai@linux.intel.com> Closes: https://lore.kernel.org/all/ZvFEAM6JfrBKsOU0@ly-workstation/Signed-off-by:
Miklos Szeredi <mszeredi@redhat.com>
-
- 23 Sep, 2024 4 commits
-
-
Alexander Mikhalitsyn authored
We should convert fs/fuse code to use a newly introduced invalid_mnt_idmap instead of passing a NULL as idmap pointer. Suggested-by:
Christian Brauner <brauner@kernel.org> Signed-off-by:
Alexander Mikhalitsyn <aleksandr.mikhalitsyn@canonical.com> Reviewed-by:
-
Alexander Mikhalitsyn authored
Link: https://lore.kernel.org/linux-fsdevel/20240904-baugrube-erhoben-b3c1c49a2645@brauner/Suggested-by:
-
Alexander Mikhalitsyn authored
Let's convert all existing callers properly. No functional changes intended. Suggested-by:
-
Alexander Mikhalitsyn authored
It was reported [1] that on linux-next/fs-next the following crash is reproducible: [ 42.659136] Oops: general protection fault, probably for non-canonical address 0xdffffc000000000b: 0000 [#1] PREEMPT SMP KASAN NOPTI [ 42.660501] fbcon: Taking over console [ 42.660930] KASAN: null-ptr-deref in range [0x0000000000000058-0x000000000000005f] [ 42.661752] CPU: 1 UID: 0 PID: 1589 Comm: dtprobed Not tainted 6.11.0-rc6+ #1 [ 42.662565] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.6.6 08/22/2023 [ 42.663472] RIP: 0010:fuse_get_req+0x36b/0x990 [fuse] [ 42.664046] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 8c 05 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6d 08 48 8d 7d 58 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 05 00 00 f6 45 59 20 0f 85 06 03 00 00 48 83 [ 42.666945] RSP: 0018:ffffc900009a7730 EFLAGS: 00010212 [ 42.668837] RAX: dffffc0000000000 RBX: 1ffff92000134eed RCX: ffffffffc20dec9a [ 42.670122] RDX: 000000000000000b RSI: 0000000000000008 RDI: 0000000000000058 [ 42.672154] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1022110172 [ 42.672160] R10: ffff888110880b97 R11: ffffc900009a737a R12: 0000000000000001 [ 42.672179] R13: ffff888110880b60 R14: ffff888110880b90 R15: ffff888169973840 [ 42.672186] FS: 00007f28cd21d7c0(0000) GS:ffff8883ef280000(0000) knlGS:0000000000000000 [ 42.672191] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 42.[ CR02: ;32m00007f3237366208 CR3: 0 OK 79e001 CR4: 0000000000770ef0 [ 42.672214] PKRU: 55555554 [ 42.672218] Call Trace: [ 42.672223] <TASK> [ 42.672226] ? die_addr+0x41/0xa0 [ 42.672238] ? exc_general_protection+0x14c/0x230 [ 42.672250] ? asm_exc_general_protection+0x26/0x30 [ 42.672260] ? fuse_get_req+0x77a/0x990 [fuse] [ 42.672281] ? fuse_get_req+0x36b/0x990 [fuse] [ 42.672300] ? kasan_unpoison+0x27/0x60 [ 42.672310] ? __pfx_fuse_get_req+0x10/0x10 [fuse] [ 42.672327] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.672333] ? alloc_pages_mpol_noprof+0x195/0x440 [ 42.672340] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.672345] ? kasan_unpoison+0x27/0x60 [ 42.672350] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.672355] ? __kasan_slab_alloc+0x4d/0x90 [ 42.672362] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.672367] ? __kmalloc_cache_noprof+0x134/0x350 [ 42.672376] fuse_simple_background+0xe7/0x180 [fuse] [ 42.672406] cuse_channel_open+0x540/0x710 [cuse] [ 42.672415] misc_open+0x2a7/0x3a0 [ 42.672424] chrdev_open+0x1ef/0x5f0 [ 42.672432] ? __pfx_chrdev_open+0x10/0x10 [ 42.672439] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.672443] ? security_file_open+0x3bb/0x720 [ 42.672451] do_dentry_open+0x43d/0x1200 [ 42.672459] ? __pfx_chrdev_open+0x10/0x10 [ 42.672468] vfs_open+0x79/0x340 [ 42.672475] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.672482] do_open+0x68c/0x11e0 [ 42.672489] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.672495] ? __pfx_do_open+0x10/0x10 [ 42.672501] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.672506] ? open_last_lookups+0x2a2/0x1370 [ 42.672515] path_openat+0x24f/0x640 [ 42.672522] ? __pfx_path_openat+0x10/0x10 [ 42.723972] ? stack_depot_save_flags+0x45/0x4b0 [ 42.724787] ? __fput+0x43c/0xa70 [ 42.725100] do_filp_open+0x1b3/0x3e0 [ 42.725710] ? poison_slab_object+0x10d/0x190 [ 42.726145] ? __kasan_slab_free+0x33/0x50 [ 42.726570] ? __pfx_do_filp_open+0x10/0x10 [ 42.726981] ? do_syscall_64+0x64/0x170 [ 42.727418] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 42.728018] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.728505] ? do_raw_spin_lock+0x131/0x270 [ 42.728922] ? __pfx_do_raw_spin_lock+0x10/0x10 [ 42.729494] ? do_raw_spin_unlock+0x14c/0x1f0 [ 42.729992] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.730889] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.732178] ? alloc_fd+0x176/0x5e0 [ 42.732585] do_sys_openat2+0x122/0x160 [ 42.732929] ? __pfx_do_sys_openat2+0x10/0x10 [ 42.733448] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.734013] ? __pfx_map_id_up+0x10/0x10 [ 42.734482] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.735529] ? __memcg_slab_free_hook+0x292/0x500 [ 42.736131] __x64_sys_openat+0x123/0x1e0 [ 42.736526] ? __pfx___x64_sys_openat+0x10/0x10 [ 42.737369] ? __x64_sys_close+0x7c/0xd0 [ 42.737717] ? srso_alias_return_thunk+0x5/0xfbef5 [ 42.738192] ? syscall_trace_enter+0x11e/0x1b0 [ 42.738739] do_syscall_64+0x64/0x170 [ 42.739113] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 42.739638] RIP: 0033:0x7f28cd13e87b [ 42.740038] Code: 25 00 00 41 00 3d 00 00 41 00 74 4b 64 8b 04 25 18 00 00 00 85 c0 75 67 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 <48> 3d 00 f0 ff ff 0f 87 91 00 00 00 48 8b 54 24 28 64 48 2b 14 25 [ 42.741943] RSP: 002b:00007ffc992546c0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101 [ 42.742951] RAX: ffffffffffffffda RBX: 00007f28cd44f1ee RCX: 00007f28cd13e87b [ 42.743660] RDX: 0000000000000002 RSI: 00007f28cd44f2fa RDI: 00000000ffffff9c [ 42.744518] RBP: 00007f28cd44f2fa R08: 0000000000000000 R09: 0000000000000001 [ 42.745211] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002 [ 42.745920] R13: 00007f28cd44f2fa R14: 0000000000000000 R15: 0000000000000003 [ 42.746708] </TASK> [ 42.746937] Modules linked in: cuse vfat fat ext4 mbcache jbd2 intel_rapl_msr intel_rapl_common kvm_amd ccp bochs drm_vram_helper kvm drm_ttm_helper ttm pcspkr i2c_piix4 drm_kms_helper i2c_smbus pvpanic_mmio pvpanic joydev sch_fq_codel drm fuse xfs nvme_tcp nvme_fabrics nvme_core sd_mod sg virtio_net net_failover virtio_scsi failover crct10dif_pclmul crc32_pclmul ata_generic pata_acpi ata_piix ghash_clmulni_intel virtio_pci sha512_ssse3 virtio_pci_legacy_dev sha256_ssse3 virtio_pci_modern_dev sha1_ssse3 libata serio_raw dm_multipath btrfs blake2b_generic xor zstd_compress raid6_pq sunrpc dm_mirror dm_region_hash dm_log dm_mod be2iscsi bnx2i cnic uio cxgb4i cxgb4 tls cxgb3i cxgb3 mdio libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi qemu_fw_cfg aesni_intel crypto_simd cryptd [ 42.754333] ---[ end trace 0000000000000000 ]--- [ 42.756899] RIP: 0010:fuse_get_req+0x36b/0x990 [fuse] [ 42.757851] Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 8c 05 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6d 08 48 8d 7d 58 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 4d 05 00 00 f6 45 59 20 0f 85 06 03 00 00 48 83 [ 42.760334] RSP: 0018:ffffc900009a7730 EFLAGS: 00010212 [ 42.760940] RAX: dffffc0000000000 RBX: 1ffff92000134eed RCX: ffffffffc20dec9a [ 42.761697] RDX: 000000000000000b RSI: 0000000000000008 RDI: 0000000000000058 [ 42.763009] RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed1022110172 [ 42.763920] R10: ffff888110880b97 R11: ffffc900009a737a R12: 0000000000000001 [ 42.764839] R13: ffff888110880b60 R14: ffff888110880b90 R15: ffff888169973840 [ 42.765716] FS: 00007f28cd21d7c0(0000) GS:ffff8883ef280000(0000) knlGS:0000000000000000 [ 42.766890] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 42.767828] CR2: 00007f3237366208 CR3: 000000012c79e001 CR4: 0000000000770ef0 [ 42.768730] PKRU: 55555554 [ 42.769022] Kernel panic - not syncing: Fatal exception [ 42.770758] Kernel Offset: 0x7200000 from 0xffffffff81000000 (relocation range: 0xffffffff80000000-0xffffffffbfffffff) [ 42.771947] ---[ end Kernel panic - not syncing: Fatal exception ]--- It's obviously CUSE related callstack. For CUSE case, we don't have superblock and our checks for SB_I_NOIDMAP flag does not make any sense. Let's handle this case gracefully. Fixes: aa16880d ("fuse: add basic infrastructure to support idmappings") Link: https://lore.kernel.org/linux-next/87v7z586py.fsf@debian-BULLSEYE-live-builder-AMD64/ [1] Reported-by:
Chandan Babu R <chandanbabu@kernel.org> Reported-by: syzbot+20c7e20cc8f5296dca12@syzkaller.appspotmail.com Signed-off-by:
-
- 19 Sep, 2024 1 commit
-
-
Miklos Szeredi authored
Only f_path is used from backing files registered with FUSE_DEV_IOC_BACKING_OPEN, so it makes sense to allow O_PATH descriptors. O_PATH files have an empty f_op, so don't check read_iter/write_iter. Reviewed-by:
Amir Goldstein <amir73il@gmail.com> Signed-off-by:
-
- 18 Sep, 2024 1 commit
-
-
Alexander Mikhalitsyn authored
Allow idmapped mounts for virtiofs. It's absolutely safe as for virtiofs we have the same feature negotiation mechanism as for classical fuse filesystems. This does not affect any existing setups anyhow. virtiofsd support: https://gitlab.com/virtio-fs/virtiofsd/-/merge_requests/245Signed-off-by:
Stefan Hajnoczi <stefanha@redhat.com> Signed-off-by:
-
- 04 Sep, 2024 14 commits
-
-
Alexander Mikhalitsyn authored
Now we have everything in place and we can allow idmapped mounts by setting the FS_ALLOW_IDMAP flag. Notice that real availability of idmapped mounts will depend on the fuse daemon. Fuse daemon have to set FUSE_ALLOW_IDMAP flag in the FUSE_INIT reply. To discuss: - we enable idmapped mounts support only if "default_permissions" mode is enabled, because otherwise we would need to deal with UID/GID mappings in the userspace side OR provide the userspace with idmapped req->in.h.uid/req->in.h.gid values which is not something that we probably want to. Idmapped mounts philosophy is not about faking caller uid/gid. Some extra links and examples: - libfuse support https://github.com/mihalicyn/libfuse/commits/idmap_support - fuse-overlayfs support: https://github.com/mihalicyn/fuse-overlayfs/commits/idmap_support - cephfs-fuse conversion example https://github.com/mihalicyn/ceph/commits/fuse_idmap - glusterfs conversion example https://github.com/mihalicyn/glusterfs/commits/fuse_idmapSigned-off-by:
-
Alexander Mikhalitsyn authored
It is not possible with the current fuse code, but let's protect ourselves from regressions in the future. Signed-off-by:
-
Alexander Mikhalitsyn authored
This is needed to properly clear suid/sgid. Signed-off-by:
-
Alexander Mikhalitsyn authored
RENAME_WHITEOUT is a special case of ->rename and we need to take idmappings into account there. Signed-off-by:
-
Alexander Mikhalitsyn authored
It's just a matter of adjusting a permission check condition for S_ISGID flag. All the rest is already handled in the generic VFS code. Notice that this permission check is the analog of what we have in posix_acl_update_mode() generic helper, but fuse doesn't use this helper as on the kernel side we don't care about ensuring that POSIX ACL and CHMOD permissions are in sync as it is a responsibility of a userspace daemon to handle that. For the same reason we don't have a calls to posix_acl_chmod(), while most of other filesystem do. Signed-off-by:
-
Alexander Mikhalitsyn authored
We don't need to have idmap in the __fuse_get_acl as we don't have any use for it. In the current POSIX ACL implementation, idmapped mounts are taken into account on the userspace/kernel border (see vfs_set_acl_idmapped_mnt() and vfs_posix_acl_to_xattr()). Signed-off-by:
-
Alexander Mikhalitsyn authored
Need to translate uid and gid in case of chown(2). Signed-off-by:
-
Alexander Mikhalitsyn authored
We only cover the case when "default_permissions" flag is used. A reason for that is that otherwise all the permission checks are done in the userspace and we have to deal with VFS idmapping in the userspace (which is bad), alternatively we have to provide the userspace with idmapped req->in.h.uid/req->in.h.gid which is also not align with VFS idmaps philosophy. Signed-off-by:
-
Alexander Mikhalitsyn authored
We have to: - pass an idmapping to the generic_fillattr() to properly handle UIG/GID mapping for the userspace. - pass -/- to fuse_fillattr() (analog of generic_fillattr() in fuse). Difference between these two is that generic_fillattr() takes all the stat() data from the inode directly, while fuse_fillattr() codepath takes a fresh data just from the userspace reply on the FUSE_GETATTR request. In some cases we can just pass &nop_mnt_idmap, because idmapping won't be used in these codepaths. For example, when 3rd argument of fuse_do_getattr() is NULL then idmap argument is not used. Signed-off-by:
-
Alexander Mikhalitsyn authored
We have all the infrastructure in place, we just need to pass an idmapping here. Signed-off-by:
-
Alexander Mikhalitsyn authored
We don't need to remap parent_gid, but have to adjust group membership checks and take idmapping into account. Signed-off-by:
-
Alexander Mikhalitsyn authored
If idmap == NULL *and* filesystem daemon declared idmapped mounts support, then uid/gid values in a fuse header will be -1. No functional changes intended. Signed-off-by:
-
Alexander Mikhalitsyn authored
Add some preparational changes in fuse_get_req/fuse_force_creds to handle idmappings. Miklos suggested [1], [2] to change the meaning of in.h.uid/in.h.gid fields when daemon declares support for idmapped mounts. In a new semantic, we fill uid/gid values in fuse header with a id-mapped caller uid/gid (for requests which create new inodes), for all the rest cases we just send -1 to userspace. No functional changes intended. Link: https://lore.kernel.org/all/CAJfpegsVY97_5mHSc06mSw79FehFWtoXT=hhTUK_E-Yhr7OAuQ@mail.gmail.com/ [1] Link: https://lore.kernel.org/all/CAJfpegtHQsEUuFq1k4ZbTD3E1h-GsrN3PWyv7X8cg6sfU_W2Yw@mail.gmail.com/ [2] Signed-off-by:
-
Alexander Mikhalitsyn authored
Right now we determine if filesystem support vfs idmappings or not basing on the FS_ALLOW_IDMAP flag presence. This "static" way works perfecly well for local filesystems like ext4, xfs, btrfs, etc. But for network-like filesystems like fuse, cephfs this approach is not ideal, because sometimes proper support of vfs idmaps requires some extensions for the on-wire protocol, which implies that changes have to be made not only in the Linux kernel code but also in the 3rd party components like libfuse, cephfs MDS server and so on. We have seen that issue during our work on cephfs idmapped mounts [1] with Christian, but right now I'm working on the idmapped mounts support for fuse/virtiofs and I think that it is a right time for this extension. [1] 5ccd8530 ("ceph: handle idmapped mounts in create_request_message()") Suggested-by:
-
- 29 Aug, 2024 11 commits
-
-
Aurelien Aptel authored
fuse_mount_list doesn't exist, use fuse_conn_list. Signed-off-by:
Aurelien Aptel <aaptel@nvidia.com> Reviewed-by:
Bernd Schubert <bschubert@ddn.com> Signed-off-by:
-
Josef Bacik authored
I've been timing various fuse operations and it's quite annoying to do with kprobes. Add two tracepoints for sending and ending fuse requests to make it easier to debug and time various operations. Signed-off-by:
Josef Bacik <josef@toxicpanda.com> Reviewed-by:
-
Joanne Koong authored
This change refactors the shared logic in fuse_writepages_fill() and fuse_writepages_locked() into two separate helper functions, fuse_writepage_args_page_fill() and fuse_writepage_args_setup(). No functional changes added. Signed-off-by:
Joanne Koong <joannelkoong@gmail.com> Reviewed-by:
-
Joanne Koong authored
Before this change, wpa->ia.ff is initialized with an acquired reference on the fuse file right before it submits the writeback request. If there are auxiliary writebacks, then the initialization and reference acquisition needs to also be set before we submit the auxiliary writeback request. To make the logic simpler and to pave the way for a subsequent refactoring of fuse_writepages_fill() and fuse_writepage_locked(), this change initializes and acquires wpa->ia.ff when the wpa is allocated. No functional changes added. Signed-off-by:
-
Joanne Koong authored
To pave the way for refactoring out the shared logic in fuse_writepages_fill() and fuse_writepage_locked(), this change converts the temporary page in fuse_writepages_fill() to use the folio API. This is similar to the change in commit e0887e09 ("fuse: Convert fuse_writepage_locked to take a folio"), which converted the tmp page in fuse_writepage_locked() to use the folio API. inc_node_page_state() is intentionally preserved here instead of converting to node_stat_add_folio() since it is updating the stat of the underlying page and to better maintain API symmetry with dec_node_page_stat() in fuse_writepage_finish_stat(). No functional changes added. Signed-off-by:
-
Joanne Koong authored
Prior to this change, data->ff is checked and if not initialized then initialized in the fuse_writepages_fill() callback, which gets called for every dirty page in the address space mapping. This logic is better placed in the main fuse_writepages() caller where data.ff is initialized before walking the dirty pages. No functional changes added. Signed-off-by:
-
Joanne Koong authored
Move the logic for updating the bdi and page stats for a finished writeback into a separate helper function, where it can be called from both fuse_writepage_finish() and fuse_writepage_add() (in the case where there is already an auxiliary write request for the page). No functional changes added. Suggested by: Jingbo Xu <jefflexu@linux.alibaba.com> Signed-off-by:
-
Joanne Koong authored
Drop the unused "struct fuse_mount *fm" arg in fuse_writepage_finish(). No functional changes added. Signed-off-by:
Jingbo Xu <jefflexu@linux.alibaba.com> Reviewed-by:
-
yangyun authored
In some cases, the fi->writepages may be empty. And there is no need to check fi->writepages with spin_lock, which may have an impact on performance due to lock contention. For example, in scenarios where multiple readers read the same file without any writers, or where the page cache is not enabled. Also remove the outdated comment since commit 6b2fb799 ("fuse: optimize writepages search") has optimize the situation by replacing list with rb-tree. Signed-off-by:
yangyun <yangyun50@huawei.com> Signed-off-by:
-
Miklos Szeredi authored
Virtiofs has its own queuing mechanism, but still requests are first queued on fiq->pending to be immediately dequeued and queued onto the virtio queue. The queuing on fiq->pending is unnecessary and might even have some performance impact due to being a contention point. Forget requests are handled similarly. Move the queuing of requests and forgets into the fiq->ops->*. fuse_iqueue_ops are renamed to reflect the new semantics. Reviewed-by:
Peter-Jan Gootzen <pgootzen@nvidia.com> Reviewed-by:
-
Bernd Schubert authored
Current design and handling of passthrough is without fuse caching and with that FUSE_WRITEBACK_CACHE is conflicting. Fixes: 7dc4e97a ("fuse: introduce FUSE_PASSTHROUGH capability") Cc: stable@kernel.org # v6.9 Signed-off-by:
-
- 28 Aug, 2024 5 commits
-
-
Joanne Koong authored
In the case where the aux writeback list is dropped (e.g. the pages have been truncated or the connection is broken), the stats for its pages and backing device info need to be updated as well. Fixes: e2653bd5 ("fuse: fix leaked aux requests") Signed-off-by:
-
Miklos Szeredi authored
Originally when a stolen page was inserted into fuse's page cache by fuse_try_move_page(), it would be marked uptodate. Then fuse_readpages_end() would call SetPageUptodate() again on the already uptodate page. Commit 413e8f01 ("fuse: Convert fuse_readpages_end() to use folio_end_read()") changed that by replacing the SetPageUptodate() + unlock_page() combination with folio_end_read(), which does mostly the same, except it sets the uptodate flag with an xor operation, which in the above scenario resulted in the uptodate flag being cleared, which in turn resulted in EIO being returned on the read. Fix by clearing PG_uptodate instead of setting it in fuse_try_move_page(), conforming to the expectation of folio_end_read(). Reported-by:
Jürg Billeter <j@bitron.ch> Debugged-by:
Matthew Wilcox <willy@infradead.org> Fixes: 413e8f01 ("fuse: Convert fuse_readpages_end() to use folio_end_read()") Cc: <stable@vger.kernel.org> # v6.10 Signed-off-by:
-
yangyun authored
The memory of struct fuse_file is allocated but not freed when get_create_ext return error. Fixes: 3e2b6fdb ("fuse: send security context of inode on file") Cc: stable@vger.kernel.org # v5.17 Signed-off-by:
-
Joanne Koong authored
There is a race condition where inflight requests will not be aborted if they are in the middle of being re-sent when the connection is aborted. If fuse_resend has already moved all the requests in the fpq->processing lists to its private queue ("to_queue") and then the connection starts and finishes aborting, these requests will be added to the pending queue and remain on it indefinitely. Fixes: 760eac73 ("fuse: Introduce a new notification type for resend pending requests") Signed-off-by: -
Jann Horn authored
The existing code uses min_t(ssize_t, outarg.size, XATTR_LIST_MAX) when parsing the FUSE daemon's response to a zero-length getxattr/listxattr request. On 32-bit kernels, where ssize_t and outarg.size are the same size, this is wrong: The min_t() will pass through any size values that are negative when interpreted as signed. fuse_listxattr() will then return this userspace-supplied negative value, which callers will treat as an error value. This kind of bug pattern can lead to fairly bad security bugs because of how error codes are used in the Linux kernel. If a caller were to convert the numeric error into an error pointer, like so: struct foo *func(...) { int len = fuse_getxattr(..., NULL, 0); if (len < 0) return ERR_PTR(len); ... } then it would end up returning this userspace-supplied negative value cast to a pointer - but the caller of this function wouldn't recognize it as an error pointer (IS_ERR_VALUE() only detects values in the narrow range in which legitimate errno values are), and so it would just be treated as a kernel pointer. I think there is at least one theoretical codepath where this could happen, but that path would involve virtio-fs with submounts plus some weird SELinux configuration, so I think it's probably not a concern in practice. Cc: stable@vger.kernel.org # v4.9 Fixes: 63401ccd ("fuse: limit xattr returned size") Signed-off-by:Jann Horn <jannh@google.com> Signed-off-by:
-
- 28 Jul, 2024 3 commits
-
-
Linus Torvalds authored
-
Linus Torvalds authored
Merge tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild Pull Kbuild fixes from Masahiro Yamada: - Fix RPM package build error caused by an incorrect locale setup - Mark modules.weakdep as ghost in RPM package - Fix the odd combination of -S and -c in stack protector scripts, which is an error with the latest Clang * tag 'kbuild-fixes-v6.11' of git://git.kernel.org/pub/scm/linux/kernel/git/masahiroy/linux-kbuild: kbuild: Fix '-S -c' in x86 stack protector scripts kbuild: rpm-pkg: ghost modules.weakdep file kbuild: rpm-pkg: Fix C locale setup
-
Linus Torvalds authored
This simplifies the min_t() and max_t() macros by no longer making them work in the context of a C constant expression. That means that you can no longer use them for static initializers or for array sizes in type definitions, but there were only a couple of such uses, and all of them were converted (famous last words) to use MIN_T/MAX_T instead. Cc: David Laight <David.Laight@aculab.com> Cc: Lorenzo Stoakes <lorenzo.stoakes@oracle.com> Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org>
-
