Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ptp_qoriq: fix memory leak in probe()<br /> <br /> Smatch complains that:<br /> drivers/ptp/ptp_qoriq.c ptp_qoriq_probe()<br /> warn: &amp;#39;base&amp;#39; from ioremap() not released.<br /> <br /> Fix this by revising the parameter from &amp;#39;ptp_qoriq-&gt;base&amp;#39; to &amp;#39;base&amp;#39;.<br /> This is only a bug if ptp_qoriq_init() returns on the<br /> first -ENODEV error path.<br /> For other error paths ptp_qoriq-&gt;base and base are the same.<br /> And this change makes the code more readable.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: ymfpci: Create card with device-managed snd_devm_card_new()<br /> <br /> snd_card_ymfpci_remove() was removed in commit c6e6bb5eab74 ("ALSA:<br /> ymfpci: Allocate resources with device-managed APIs"), but the call to<br /> snd_card_new() was not replaced with snd_devm_card_new().<br /> <br /> Since there was no longer a call to snd_card_free, unloading the module<br /> would eventually result in Oops:<br /> <br /> [697561.532887] BUG: unable to handle page fault for address: ffffffffc0924480<br /> [697561.532893] #PF: supervisor read access in kernel mode<br /> [697561.532896] #PF: error_code(0x0000) - not-present page<br /> [697561.532899] PGD ae1e15067 P4D ae1e15067 PUD ae1e17067 PMD 11a8f5067 PTE 0<br /> [697561.532905] Oops: 0000 [#1] PREEMPT SMP NOPTI<br /> [697561.532909] CPU: 21 PID: 5080 Comm: wireplumber Tainted: G W OE 6.2.7 #1<br /> [697561.532914] Hardware name: System manufacturer System Product Name/TUF GAMING X570-PLUS, BIOS 4408 10/28/2022<br /> [697561.532916] RIP: 0010:try_module_get.part.0+0x1a/0xe0<br /> [697561.532924] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 55 48 89 e5 41 55 41 54 49 89 fc bf 01 00 00 00 e8 56 3c f8 ff 83 3c 24 02 0f 84 96 00 00 00 41 8b 84 24 30 03 00 00 85 c0 0f<br /> [697561.532927] RSP: 0018:ffffbe9b858c3bd8 EFLAGS: 00010246<br /> [697561.532930] RAX: ffff9815d14f1900 RBX: ffff9815c14e6000 RCX: 0000000000000000<br /> [697561.532933] RDX: 0000000000000000 RSI: ffffffffc055092c RDI: ffffffffb3778c1a<br /> [697561.532935] RBP: ffffbe9b858c3be8 R08: 0000000000000040 R09: ffff981a1a741380<br /> [697561.532937] R10: ffffbe9b858c3c80 R11: 00000009d56533a6 R12: ffffffffc0924480<br /> [697561.532939] R13: ffff9823439d8500 R14: 0000000000000025 R15: ffff9815cd109f80<br /> [697561.532942] FS: 00007f13084f1f80(0000) GS:ffff9824aef40000(0000) knlGS:0000000000000000<br /> [697561.532945] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [697561.532947] CR2: ffffffffc0924480 CR3: 0000000145344000 CR4: 0000000000350ee0<br /> [697561.532949] Call Trace:<br /> [697561.532951] <br /> [697561.532955] try_module_get+0x13/0x30<br /> [697561.532960] snd_ctl_open+0x61/0x1c0 [snd]<br /> [697561.532976] snd_open+0xb4/0x1e0 [snd]<br /> [697561.532989] chrdev_open+0xc7/0x240<br /> [697561.532995] ? fsnotify_perm.part.0+0x6e/0x160<br /> [697561.533000] ? __pfx_chrdev_open+0x10/0x10<br /> [697561.533005] do_dentry_open+0x169/0x440<br /> [697561.533009] vfs_open+0x2d/0x40<br /> [697561.533012] path_openat+0xa9d/0x10d0<br /> [697561.533017] ? debug_smp_processor_id+0x17/0x20<br /> [697561.533022] ? trigger_load_balance+0x65/0x370<br /> [697561.533026] do_filp_open+0xb2/0x160<br /> [697561.533032] ? _raw_spin_unlock+0x19/0x40<br /> [697561.533036] ? alloc_fd+0xa9/0x190<br /> [697561.533040] do_sys_openat2+0x9f/0x160<br /> [697561.533044] __x64_sys_openat+0x55/0x90<br /> [697561.533048] do_syscall_64+0x3b/0x90<br /> [697561.533052] entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> [697561.533056] RIP: 0033:0x7f1308a40db4<br /> [697561.533059] Code: 24 20 eb 8f 66 90 44 89 54 24 0c e8 46 68 f8 ff 44 8b 54 24 0c 44 89 e2 48 89 ee 41 89 c0 bf 9c ff ff ff b8 01 01 00 00 0f 05 3d 00 f0 ff ff 77 32 44 89 c7 89 44 24 0c e8 78 68 f8 ff 8b 44<br /> [697561.533062] RSP: 002b:00007ffcce664450 EFLAGS: 00000293 ORIG_RAX: 0000000000000101<br /> [697561.533066] RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1308a40db4<br /> [697561.533068] RDX: 0000000000080000 RSI: 00007ffcce664690 RDI: 00000000ffffff9c<br /> [697561.533070] RBP: 00007ffcce664690 R08: 0000000000000000 R09: 0000000000000012<br /> [697561.533072] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000080000<br /> [697561.533074] R13: 00007f13054b069b R14: 0000565209f83200 R15: 0000000000000000<br /> [697561.533078]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> vduse: fix NULL pointer dereference<br /> <br /> vduse_vdpa_set_vq_affinity callback can be called<br /> with NULL value as cpu_mask when deleting the vduse<br /> device.<br /> <br /> This patch resets virtqueue&amp;#39;s IRQ affinity mask value<br /> to set all CPUs instead of dereferencing NULL cpu_mask.<br /> <br /> [ 4760.952149] BUG: kernel NULL pointer dereference, address: 0000000000000000<br /> [ 4760.959110] #PF: supervisor read access in kernel mode<br /> [ 4760.964247] #PF: error_code(0x0000) - not-present page<br /> [ 4760.969385] PGD 0 P4D 0<br /> [ 4760.971927] Oops: 0000 [#1] PREEMPT SMP PTI<br /> [ 4760.976112] CPU: 13 PID: 2346 Comm: vdpa Not tainted 6.4.0-rc6+ #4<br /> [ 4760.982291] Hardware name: Dell Inc. PowerEdge R640/0W23H8, BIOS 2.8.1 06/26/2020<br /> [ 4760.989769] RIP: 0010:memcpy_orig+0xc5/0x130<br /> [ 4760.994049] Code: 16 f8 4c 89 07 4c 89 4f 08 4c 89 54 17 f0 4c 89 5c 17 f8 c3 cc cc cc cc 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 83 fa 08 72 1b 8b 06 4c 8b 4c 16 f8 4c 89 07 4c 89 4c 17 f8 c3 cc cc cc cc 66<br /> [ 4761.012793] RSP: 0018:ffffb1d565abb830 EFLAGS: 00010246<br /> [ 4761.018020] RAX: ffff9f4bf6b27898 RBX: ffff9f4be23969c0 RCX: ffff9f4bcadf6400<br /> [ 4761.025152] RDX: 0000000000000008 RSI: 0000000000000000 RDI: ffff9f4bf6b27898<br /> [ 4761.032286] RBP: 0000000000000000 R08: 0000000000000008 R09: 0000000000000000<br /> [ 4761.039416] R10: 0000000000000000 R11: 0000000000000600 R12: 0000000000000000<br /> [ 4761.046549] R13: 0000000000000000 R14: 0000000000000080 R15: ffffb1d565abbb10<br /> [ 4761.053680] FS: 00007f64c2ec2740(0000) GS:ffff9f635f980000(0000) knlGS:0000000000000000<br /> [ 4761.061765] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4761.067513] CR2: 0000000000000000 CR3: 0000001875270006 CR4: 00000000007706e0<br /> [ 4761.074645] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> [ 4761.081775] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> [ 4761.088909] PKRU: 55555554<br /> [ 4761.091620] Call Trace:<br /> [ 4761.094074] <br /> [ 4761.096180] ? __die+0x1f/0x70<br /> [ 4761.099238] ? page_fault_oops+0x171/0x4f0<br /> [ 4761.103340] ? exc_page_fault+0x7b/0x180<br /> [ 4761.107265] ? asm_exc_page_fault+0x22/0x30<br /> [ 4761.111460] ? memcpy_orig+0xc5/0x130<br /> [ 4761.115126] vduse_vdpa_set_vq_affinity+0x3e/0x50 [vduse]<br /> [ 4761.120533] virtnet_clean_affinity.part.0+0x3d/0x90 [virtio_net]<br /> [ 4761.126635] remove_vq_common+0x1a4/0x250 [virtio_net]<br /> [ 4761.131781] virtnet_remove+0x5d/0x70 [virtio_net]<br /> [ 4761.136580] virtio_dev_remove+0x3a/0x90<br /> [ 4761.140509] device_release_driver_internal+0x19b/0x200<br /> [ 4761.145742] bus_remove_device+0xc2/0x130<br /> [ 4761.149755] device_del+0x158/0x3e0<br /> [ 4761.153245] ? kernfs_find_ns+0x35/0xc0<br /> [ 4761.157086] device_unregister+0x13/0x60<br /> [ 4761.161010] unregister_virtio_device+0x11/0x20<br /> [ 4761.165543] device_release_driver_internal+0x19b/0x200<br /> [ 4761.170770] bus_remove_device+0xc2/0x130<br /> [ 4761.174782] device_del+0x158/0x3e0<br /> [ 4761.178276] ? __pfx_vdpa_name_match+0x10/0x10 [vdpa]<br /> [ 4761.183336] device_unregister+0x13/0x60<br /> [ 4761.187260] vdpa_nl_cmd_dev_del_set_doit+0x63/0xe0 [vdpa]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> RDMA/irdma: Fix data race on CQP request done<br /> <br /> KCSAN detects a data race on cqp_request-&gt;request_done memory location<br /> which is accessed locklessly in irdma_handle_cqp_op while being<br /> updated in irdma_cqp_ce_handler.<br /> <br /> Annotate lockless intent with READ_ONCE/WRITE_ONCE to avoid any<br /> compiler optimizations like load fusing and/or KCSAN warning.<br /> <br /> [222808.417128] BUG: KCSAN: data-race in irdma_cqp_ce_handler [irdma] / irdma_wait_event [irdma]<br /> <br /> [222808.417532] write to 0xffff8e44107019dc of 1 bytes by task 29658 on cpu 5:<br /> [222808.417610] irdma_cqp_ce_handler+0x21e/0x270 [irdma]<br /> [222808.417725] cqp_compl_worker+0x1b/0x20 [irdma]<br /> [222808.417827] process_one_work+0x4d1/0xa40<br /> [222808.417835] worker_thread+0x319/0x700<br /> [222808.417842] kthread+0x180/0x1b0<br /> [222808.417852] ret_from_fork+0x22/0x30<br /> <br /> [222808.417918] read to 0xffff8e44107019dc of 1 bytes by task 29688 on cpu 1:<br /> [222808.417995] irdma_wait_event+0x1e2/0x2c0 [irdma]<br /> [222808.418099] irdma_handle_cqp_op+0xae/0x170 [irdma]<br /> [222808.418202] irdma_cqp_cq_destroy_cmd+0x70/0x90 [irdma]<br /> [222808.418308] irdma_puda_dele_rsrc+0x46d/0x4d0 [irdma]<br /> [222808.418411] irdma_rt_deinit_hw+0x179/0x1d0 [irdma]<br /> [222808.418514] irdma_ib_dealloc_device+0x11/0x40 [irdma]<br /> [222808.418618] ib_dealloc_device+0x2a/0x120 [ib_core]<br /> [222808.418823] __ib_unregister_device+0xde/0x100 [ib_core]<br /> [222808.418981] ib_unregister_device+0x22/0x40 [ib_core]<br /> [222808.419142] irdma_ib_unregister_device+0x70/0x90 [irdma]<br /> [222808.419248] i40iw_close+0x6f/0xc0 [irdma]<br /> [222808.419352] i40e_client_device_unregister+0x14a/0x180 [i40e]<br /> [222808.419450] i40iw_remove+0x21/0x30 [irdma]<br /> [222808.419554] auxiliary_bus_remove+0x31/0x50<br /> [222808.419563] device_remove+0x69/0xb0<br /> [222808.419572] device_release_driver_internal+0x293/0x360<br /> [222808.419582] driver_detach+0x7c/0xf0<br /> [222808.419592] bus_remove_driver+0x8c/0x150<br /> [222808.419600] driver_unregister+0x45/0x70<br /> [222808.419610] auxiliary_driver_unregister+0x16/0x30<br /> [222808.419618] irdma_exit_module+0x18/0x1e [irdma]<br /> [222808.419733] __do_sys_delete_module.constprop.0+0x1e2/0x310<br /> [222808.419745] __x64_sys_delete_module+0x1b/0x30<br /> [222808.419755] do_syscall_64+0x39/0x90<br /> [222808.419763] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> [222808.419829] value changed: 0x01 -&gt; 0x03

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bcache: fixup btree_cache_wait list damage<br /> <br /> We get a kernel crash about "list_add corruption. next-&gt;prev should be<br /> prev (ffff9c801bc01210), but was ffff9c77b688237c.<br /> (next=ffffae586d8afe68)."<br /> <br /> crash&gt; struct list_head 0xffff9c801bc01210<br /> struct list_head {<br /> next = 0xffffae586d8afe68,<br /> prev = 0xffffae586d8afe68<br /> }<br /> crash&gt; struct list_head 0xffff9c77b688237c<br /> struct list_head {<br /> next = 0x0,<br /> prev = 0x0<br /> }<br /> crash&gt; struct list_head 0xffffae586d8afe68<br /> struct list_head struct: invalid kernel virtual address: ffffae586d8afe68 type: "gdb_readmem_callback"<br /> Cannot access memory at address 0xffffae586d8afe68<br /> <br /> [230469.019492] Call Trace:<br /> [230469.032041] prepare_to_wait+0x8a/0xb0<br /> [230469.044363] ? bch_btree_keys_free+0x6c/0xc0 [escache]<br /> [230469.056533] mca_cannibalize_lock+0x72/0x90 [escache]<br /> [230469.068788] mca_alloc+0x2ae/0x450 [escache]<br /> [230469.080790] bch_btree_node_get+0x136/0x2d0 [escache]<br /> [230469.092681] bch_btree_check_thread+0x1e1/0x260 [escache]<br /> [230469.104382] ? finish_wait+0x80/0x80<br /> [230469.115884] ? bch_btree_check_recurse+0x1a0/0x1a0 [escache]<br /> [230469.127259] kthread+0x112/0x130<br /> [230469.138448] ? kthread_flush_work_fn+0x10/0x10<br /> [230469.149477] ret_from_fork+0x35/0x40<br /> <br /> bch_btree_check_thread() and bch_dirty_init_thread() may call<br /> mca_cannibalize() to cannibalize other cached btree nodes. Only one thread<br /> can do it at a time, so the op of other threads will be added to the<br /> btree_cache_wait list.<br /> <br /> We must call finish_wait() to remove op from btree_cache_wait before free<br /> it&amp;#39;s memory address. Otherwise, the list will be damaged. Also should call<br /> bch_cannibalize_unlock() to release the btree_cache_alloc_lock and wake_up<br /> other waiters.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid10: fix memleak of md thread<br /> <br /> In raid10_run(), if setup_conf() succeed and raid10_run() failed before<br /> setting &amp;#39;mddev-&gt;thread&amp;#39;, then in the error path &amp;#39;conf-&gt;thread&amp;#39; is not<br /> freed.<br /> <br /> Fix the problem by setting &amp;#39;mddev-&gt;thread&amp;#39; right after setup_conf().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: spi-nor: Fix shift-out-of-bounds in spi_nor_set_erase_type<br /> <br /> spi_nor_set_erase_type() was used either to set or to mask out an erase<br /> type. When we used it to mask out an erase type a shift-out-of-bounds<br /> was hit:<br /> UBSAN: shift-out-of-bounds in drivers/mtd/spi-nor/core.c:2237:24<br /> shift exponent 4294967295 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> <br /> The setting of the size_{shift, mask} and of the opcode are unnecessary<br /> when the erase size is zero, as throughout the code just the erase size<br /> is considered to determine whether an erase type is supported or not.<br /> Setting the opcode to 0xFF was wrong too as nobody guarantees that 0xFF<br /> is an unused opcode. Thus when masking out an erase type, just set the<br /> erase size to zero. This will fix the shift-out-of-bounds.<br /> <br /> [ta: refine changes, new commit message, fix compilation error]

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: SVM: Get source vCPUs from source VM for SEV-ES intrahost migration<br /> <br /> Fix a goof where KVM tries to grab source vCPUs from the destination VM<br /> when doing intrahost migration. Grabbing the wrong vCPU not only hoses<br /> the guest, it also crashes the host due to the VMSA pointer being left<br /> NULL.<br /> <br /> BUG: unable to handle page fault for address: ffffe38687000000<br /> #PF: supervisor read access in kernel mode<br /> #PF: error_code(0x0000) - not-present page<br /> PGD 0 P4D 0<br /> Oops: 0000 [#1] SMP NOPTI<br /> CPU: 39 PID: 17143 Comm: sev_migrate_tes Tainted: GO 6.5.0-smp--fff2e47e6c3b-next #151<br /> Hardware name: Google, Inc. Arcadia_IT_80/Arcadia_IT_80, BIOS 34.28.0 07/10/2023<br /> RIP: 0010:__free_pages+0x15/0xd0<br /> RSP: 0018:ffff923fcf6e3c78 EFLAGS: 00010246<br /> RAX: 0000000000000000 RBX: ffffe38687000000 RCX: 0000000000000100<br /> RDX: 0000000000000100 RSI: 0000000000000000 RDI: ffffe38687000000<br /> RBP: ffff923fcf6e3c88 R08: ffff923fcafb0000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: ffffffff83619b90 R12: ffff923fa9540000<br /> R13: 0000000000080007 R14: ffff923f6d35d000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff929d0d7c0000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: ffffe38687000000 CR3: 0000005224c34005 CR4: 0000000000770ee0<br /> PKRU: 55555554<br /> Call Trace:<br /> <br /> sev_free_vcpu+0xcb/0x110 [kvm_amd]<br /> svm_vcpu_free+0x75/0xf0 [kvm_amd]<br /> kvm_arch_vcpu_destroy+0x36/0x140 [kvm]<br /> kvm_destroy_vcpus+0x67/0x100 [kvm]<br /> kvm_arch_destroy_vm+0x161/0x1d0 [kvm]<br /> kvm_put_kvm+0x276/0x560 [kvm]<br /> kvm_vm_release+0x25/0x30 [kvm]<br /> __fput+0x106/0x280<br /> ____fput+0x12/0x20<br /> task_work_run+0x86/0xb0<br /> do_exit+0x2e3/0x9c0<br /> do_group_exit+0xb1/0xc0<br /> __x64_sys_exit_group+0x1b/0x20<br /> do_syscall_64+0x41/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> CR2: ffffe38687000000

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: zoned: fix memory leak after finding block group with super blocks<br /> <br /> At exclude_super_stripes(), if we happen to find a block group that has<br /> super blocks mapped to it and we are on a zoned filesystem, we error out<br /> as this is not supposed to happen, indicating either a bug or maybe some<br /> memory corruption for example. However we are exiting the function without<br /> freeing the memory allocated for the logical address of the super blocks.<br /> Fix this by freeing the logical address.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> thermal: intel: quark_dts: fix error pointer dereference<br /> <br /> If alloc_soc_dts() fails, then we can just return. Trying to free<br /> "soc_dts" will lead to an Oops.

*** Pendiente de traducción *** Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: release path before inode lookup during the ino lookup ioctl<br /> <br /> During the ino lookup ioctl we can end up calling btrfs_iget() to get an<br /> inode reference while we are holding on a root&amp;#39;s btree. If btrfs_iget()<br /> needs to lookup the inode from the root&amp;#39;s btree, because it&amp;#39;s not<br /> currently loaded in memory, then it will need to lock another or the<br /> same path in the same root btree. This may result in a deadlock and<br /> trigger the following lockdep splat:<br /> <br /> WARNING: possible circular locking dependency detected<br /> 6.5.0-rc7-syzkaller-00004-gf7757129e3de #0 Not tainted<br /> ------------------------------------------------------<br /> syz-executor277/5012 is trying to acquire lock:<br /> ffff88802df41710 (btrfs-tree-01){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> <br /> but task is already holding lock:<br /> ffff88802df418e8 (btrfs-tree-00){++++}-{3:3}, at: __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> <br /> which lock already depends on the new lock.<br /> <br /> the existing dependency chain (in reverse order) is:<br /> <br /> -&gt; #1 (btrfs-tree-00){++++}-{3:3}:<br /> down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645<br /> __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> btrfs_search_slot+0x13a4/0x2f80 fs/btrfs/ctree.c:2302<br /> btrfs_init_root_free_objectid+0x148/0x320 fs/btrfs/disk-io.c:4955<br /> btrfs_init_fs_root fs/btrfs/disk-io.c:1128 [inline]<br /> btrfs_get_root_ref+0x5ae/0xae0 fs/btrfs/disk-io.c:1338<br /> btrfs_get_fs_root fs/btrfs/disk-io.c:1390 [inline]<br /> open_ctree+0x29c8/0x3030 fs/btrfs/disk-io.c:3494<br /> btrfs_fill_super+0x1c7/0x2f0 fs/btrfs/super.c:1154<br /> btrfs_mount_root+0x7e0/0x910 fs/btrfs/super.c:1519<br /> legacy_get_tree+0xef/0x190 fs/fs_context.c:611<br /> vfs_get_tree+0x8c/0x270 fs/super.c:1519<br /> fc_mount fs/namespace.c:1112 [inline]<br /> vfs_kern_mount+0xbc/0x150 fs/namespace.c:1142<br /> btrfs_mount+0x39f/0xb50 fs/btrfs/super.c:1579<br /> legacy_get_tree+0xef/0x190 fs/fs_context.c:611<br /> vfs_get_tree+0x8c/0x270 fs/super.c:1519<br /> do_new_mount+0x28f/0xae0 fs/namespace.c:3335<br /> do_mount fs/namespace.c:3675 [inline]<br /> __do_sys_mount fs/namespace.c:3884 [inline]<br /> __se_sys_mount+0x2d9/0x3c0 fs/namespace.c:3861<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> -&gt; #0 (btrfs-tree-01){++++}-{3:3}:<br /> check_prev_add kernel/locking/lockdep.c:3142 [inline]<br /> check_prevs_add kernel/locking/lockdep.c:3261 [inline]<br /> validate_chain kernel/locking/lockdep.c:3876 [inline]<br /> __lock_acquire+0x39ff/0x7f70 kernel/locking/lockdep.c:5144<br /> lock_acquire+0x1e3/0x520 kernel/locking/lockdep.c:5761<br /> down_read_nested+0x49/0x2f0 kernel/locking/rwsem.c:1645<br /> __btrfs_tree_read_lock+0x2f/0x220 fs/btrfs/locking.c:136<br /> btrfs_tree_read_lock fs/btrfs/locking.c:142 [inline]<br /> btrfs_read_lock_root_node+0x292/0x3c0 fs/btrfs/locking.c:281<br /> btrfs_search_slot_get_root fs/btrfs/ctree.c:1832 [inline]<br /> btrfs_search_slot+0x4ff/0x2f80 fs/btrfs/ctree.c:2154<br /> btrfs_lookup_inode+0xdc/0x480 fs/btrfs/inode-item.c:412<br /> btrfs_read_locked_inode fs/btrfs/inode.c:3892 [inline]<br /> btrfs_iget_path+0x2d9/0x1520 fs/btrfs/inode.c:5716<br /> btrfs_search_path_in_tree_user fs/btrfs/ioctl.c:1961 [inline]<br /> btrfs_ioctl_ino_lookup_user+0x77a/0xf50 fs/btrfs/ioctl.c:2105<br /> btrfs_ioctl+0xb0b/0xd40 fs/btrfs/ioctl.c:4683<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl+0xf8/0x170 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> other info <br /> ---truncated---