Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> KVM: arm64: Don&amp;#39;t retire aborted MMIO instruction<br /> <br /> Returning an abort to the guest for an unsupported MMIO access is a<br /> documented feature of the KVM UAPI. Nevertheless, it&amp;#39;s clear that this<br /> plumbing has seen limited testing, since userspace can trivially cause a<br /> WARN in the MMIO return:<br /> <br /> WARNING: CPU: 0 PID: 30558 at arch/arm64/include/asm/kvm_emulate.h:536 kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536<br /> Call trace:<br /> kvm_handle_mmio_return+0x46c/0x5c4 arch/arm64/include/asm/kvm_emulate.h:536<br /> kvm_arch_vcpu_ioctl_run+0x98/0x15b4 arch/arm64/kvm/arm.c:1133<br /> kvm_vcpu_ioctl+0x75c/0xa78 virt/kvm/kvm_main.c:4487<br /> __do_sys_ioctl fs/ioctl.c:51 [inline]<br /> __se_sys_ioctl fs/ioctl.c:893 [inline]<br /> __arm64_sys_ioctl+0x14c/0x1c8 fs/ioctl.c:893<br /> __invoke_syscall arch/arm64/kernel/syscall.c:35 [inline]<br /> invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:49<br /> el0_svc_common+0x1e0/0x23c arch/arm64/kernel/syscall.c:132<br /> do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:151<br /> el0_svc+0x38/0x68 arch/arm64/kernel/entry-common.c:712<br /> el0t_64_sync_handler+0x90/0xfc arch/arm64/kernel/entry-common.c:730<br /> el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598<br /> <br /> The splat is complaining that KVM is advancing PC while an exception is<br /> pending, i.e. that KVM is retiring the MMIO instruction despite a<br /> pending synchronous external abort. Womp womp.<br /> <br /> Fix the glaring UAPI bug by skipping over all the MMIO emulation in<br /> case there is a pending synchronous exception. Note that while userspace<br /> is capable of pending an asynchronous exception (SError, IRQ, or FIQ),<br /> it is still safe to retire the MMIO instruction in this case as (1) they<br /> are by definition asynchronous, and (2) KVM relies on hardware support<br /> for pending/delivering these exceptions instead of the software state<br /> machine for advancing PC.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> xen: Fix the issue of resource not being properly released in xenbus_dev_probe()<br /> <br /> This patch fixes an issue in the function xenbus_dev_probe(). In the<br /> xenbus_dev_probe() function, within the if (err) branch at line 313, the<br /> program incorrectly returns err directly without releasing the resources<br /> allocated by err = drv-&gt;probe(dev, id). As the return value is non-zero,<br /> the upper layers assume the processing logic has failed. However, the probe<br /> operation was performed earlier without a corresponding remove operation.<br /> Since the probe actually allocates resources, failing to perform the remove<br /> operation could lead to problems.<br /> <br /> To fix this issue, we followed the resource release logic of the<br /> xenbus_dev_remove() function by adding a new block fail_remove before the<br /> fail_put block. After entering the branch if (err) at line 313, the<br /> function will use a goto statement to jump to the fail_remove block,<br /> ensuring that the previously acquired resources are correctly released,<br /> thus preventing the reference count leak.<br /> <br /> This bug was identified by an experimental static analysis tool developed<br /> by our team. The tool specializes in analyzing reference count operations<br /> and detecting potential issues where resources are not properly managed.<br /> In this case, the tool flagged the missing release operation as a<br /> potential problem, which led to the development of this patch.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ksmbd: fix use-after-free in SMB request handling<br /> <br /> A race condition exists between SMB request handling in<br /> `ksmbd_conn_handler_loop()` and the freeing of `ksmbd_conn` in the<br /> workqueue handler `handle_ksmbd_work()`. This leads to a UAF.<br /> - KASAN: slab-use-after-free Read in handle_ksmbd_work<br /> - KASAN: slab-use-after-free in rtlock_slowlock_locked<br /> <br /> This race condition arises as follows:<br /> - `ksmbd_conn_handler_loop()` waits for `conn-&gt;r_count` to reach zero:<br /> `wait_event(conn-&gt;r_count_q, atomic_read(&amp;conn-&gt;r_count) == 0);`<br /> - Meanwhile, `handle_ksmbd_work()` decrements `conn-&gt;r_count` using<br /> `atomic_dec_return(&amp;conn-&gt;r_count)`, and if it reaches zero, calls<br /> `ksmbd_conn_free()`, which frees `conn`.<br /> - However, after `handle_ksmbd_work()` decrements `conn-&gt;r_count`,<br /> it may still access `conn-&gt;r_count_q` in the following line:<br /> `waitqueue_active(&amp;conn-&gt;r_count_q)` or `wake_up(&amp;conn-&gt;r_count_q)`<br /> This results in a UAF, as `conn` has already been freed.<br /> <br /> The discovery of this UAF can be referenced in the following PR for<br /> syzkaller&amp;#39;s support for SMB requests.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> io_uring: check for overflows in io_pin_pages<br /> <br /> WARNING: CPU: 0 PID: 5834 at io_uring/memmap.c:144 io_pin_pages+0x149/0x180 io_uring/memmap.c:144<br /> CPU: 0 UID: 0 PID: 5834 Comm: syz-executor825 Not tainted 6.12.0-next-20241118-syzkaller #0<br /> Call Trace:<br /> <br /> __io_uaddr_map+0xfb/0x2d0 io_uring/memmap.c:183<br /> io_rings_map io_uring/io_uring.c:2611 [inline]<br /> io_allocate_scq_urings+0x1c0/0x650 io_uring/io_uring.c:3470<br /> io_uring_create+0x5b5/0xc00 io_uring/io_uring.c:3692<br /> io_uring_setup io_uring/io_uring.c:3781 [inline]<br /> ...<br /> <br /> <br /> io_pin_pages()&amp;#39;s uaddr parameter came directly from the user and can be<br /> garbage. Don&amp;#39;t just add size to it as it can overflow.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix crash when unbinding<br /> <br /> If there is an error during some initialization related to firmware,<br /> the function ath12k_dp_cc_cleanup is called to release resources.<br /> However this is released again when the device is unbinded (ath12k_pci),<br /> and we get:<br /> BUG: kernel NULL pointer dereference, address: 0000000000000020<br /> at RIP: 0010:ath12k_dp_cc_cleanup.part.0+0xb6/0x500 [ath12k]<br /> Call Trace:<br /> ath12k_dp_cc_cleanup<br /> ath12k_dp_free<br /> ath12k_core_deinit<br /> ath12k_pci_remove<br /> ...<br /> <br /> The issue is always reproducible from a VM because the MSI addressing<br /> initialization is failing.<br /> <br /> In order to fix the issue, just set to NULL the released structure in<br /> ath12k_dp_cc_cleanup at the end.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: nl80211: fix bounds checker error in nl80211_parse_sched_scan<br /> <br /> The channels array in the cfg80211_scan_request has a __counted_by<br /> attribute attached to it, which points to the n_channels variable. This<br /> attribute is used in bounds checking, and if it is not set before the<br /> array is filled, then the bounds sanitizer will issue a warning or a<br /> kernel panic if CONFIG_UBSAN_TRAP is set.<br /> <br /> This patch sets the size of allocated memory as the initial value for<br /> n_channels. It is updated with the actual number of added elements after<br /> the array is filled.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: ath12k: fix warning when unbinding<br /> <br /> If there is an error during some initialization related to firmware,<br /> the buffers dp-&gt;tx_ring[i].tx_status are released.<br /> However this is released again when the device is unbinded (ath12k_pci),<br /> and we get:<br /> WARNING: CPU: 0 PID: 2098 at mm/slub.c:4689 free_large_kmalloc+0x4d/0x80<br /> Call Trace:<br /> free_large_kmalloc<br /> ath12k_dp_free<br /> ath12k_core_deinit<br /> ath12k_pci_remove<br /> ...<br /> <br /> The issue is always reproducible from a VM because the MSI addressing<br /> initialization is failing.<br /> <br /> In order to fix the issue, just set the buffers to NULL after releasing in<br /> order to avoid the double free.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: clk-loongson2: Fix potential buffer overflow in flexible-array member access<br /> <br /> Flexible-array member `hws` in `struct clk_hw_onecell_data` is annotated<br /> with the `counted_by()` attribute. This means that when memory is<br /> allocated for this array, the _counter_, which in this case is member<br /> `num` in the flexible structure, should be set to the maximum number of<br /> elements the flexible array can contain, or fewer.<br /> <br /> In this case, the total number of elements for the flexible array is<br /> determined by variable `clks_num` when allocating heap space via<br /> `devm_kzalloc()`, as shown below:<br /> <br /> 289 struct loongson2_clk_provider *clp;<br /> ...<br /> 296 for (p = data; p-&gt;name; p++)<br /> 297 clks_num++;<br /> 298<br /> 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num),<br /> 300 GFP_KERNEL);<br /> <br /> So, `clp-&gt;clk_data.num` should be set to `clks_num` or less, and not<br /> exceed `clks_num`, as is currently the case. Otherwise, if data is<br /> written into `clp-&gt;clk_data.hws[clks_num]`, the instrumentation<br /> provided by the compiler won&amp;#39;t detect the overflow, leading to a<br /> memory corruption bug at runtime.<br /> <br /> Fix this issue by setting `clp-&gt;clk_data.num` to `clks_num`.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: clk-loongson2: Fix memory corruption bug in struct loongson2_clk_provider<br /> <br /> Some heap space is allocated for the flexible structure `struct<br /> clk_hw_onecell_data` and its flexible-array member `hws` through<br /> the composite structure `struct loongson2_clk_provider` in function<br /> `loongson2_clk_probe()`, as shown below:<br /> <br /> 289 struct loongson2_clk_provider *clp;<br /> ...<br /> 296 for (p = data; p-&gt;name; p++)<br /> 297 clks_num++;<br /> 298<br /> 299 clp = devm_kzalloc(dev, struct_size(clp, clk_data.hws, clks_num),<br /> 300 GFP_KERNEL);<br /> <br /> Then some data is written into the flexible array:<br /> <br /> 350 clp-&gt;clk_data.hws[p-&gt;id] = hw;<br /> <br /> This corrupts `clk_lock`, which is the spinlock variable immediately<br /> following the `clk_data` member in `struct loongson2_clk_provider`:<br /> <br /> struct loongson2_clk_provider {<br /> void __iomem *base;<br /> struct device *dev;<br /> struct clk_hw_onecell_data clk_data;<br /> spinlock_t clk_lock; /* protect access to DIV registers */<br /> };<br /> <br /> The problem is that the flexible structure is currently placed in the<br /> middle of `struct loongson2_clk_provider` instead of at the end.<br /> <br /> Fix this by moving `struct clk_hw_onecell_data clk_data;` to the end of<br /> `struct loongson2_clk_provider`. Also, add a code comment to help<br /> prevent this from happening again in case new members are added to the<br /> structure in the future.<br /> <br /> This change also fixes the following -Wflex-array-member-not-at-end<br /> warning:<br /> <br /> drivers/clk/clk-loongson2.c:32:36: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtlwifi: Drastically reduce the attempts to read efuse in case of failures<br /> <br /> Syzkaller reported a hung task with uevent_show() on stack trace. That<br /> specific issue was addressed by another commit [0], but even with that<br /> fix applied (for example, running v6.12-rc5) we face another type of hung<br /> task that comes from the same reproducer [1]. By investigating that, we<br /> could narrow it to the following path:<br /> <br /> (a) Syzkaller emulates a Realtek USB WiFi adapter using raw-gadget and<br /> dummy_hcd infrastructure.<br /> <br /> (b) During the probe of rtl8192cu, the driver ends-up performing an efuse<br /> read procedure (which is related to EEPROM load IIUC), and here lies the<br /> issue: the function read_efuse() calls read_efuse_byte() many times, as<br /> loop iterations depending on the efuse size (in our example, 512 in total).<br /> <br /> This procedure for reading efuse bytes relies in a loop that performs an<br /> I/O read up to *10k* times in case of failures. We measured the time of<br /> the loop inside read_efuse_byte() alone, and in this reproducer (which<br /> involves the dummy_hcd emulation layer), it takes 15 seconds each. As a<br /> consequence, we have the driver stuck in its probe routine for big time,<br /> exposing a stack trace like below if we attempt to reboot the system, for<br /> example:<br /> <br /> task:kworker/0:3 state:D stack:0 pid:662 tgid:662 ppid:2 flags:0x00004000<br /> Workqueue: usb_hub_wq hub_event<br /> Call Trace:<br /> __schedule+0xe22/0xeb6<br /> schedule_timeout+0xe7/0x132<br /> __wait_for_common+0xb5/0x12e<br /> usb_start_wait_urb+0xc5/0x1ef<br /> ? usb_alloc_urb+0x95/0xa4<br /> usb_control_msg+0xff/0x184<br /> _usbctrl_vendorreq_sync+0xa0/0x161<br /> _usb_read_sync+0xb3/0xc5<br /> read_efuse_byte+0x13c/0x146<br /> read_efuse+0x351/0x5f0<br /> efuse_read_all_map+0x42/0x52<br /> rtl_efuse_shadow_map_update+0x60/0xef<br /> rtl_get_hwinfo+0x5d/0x1c2<br /> rtl92cu_read_eeprom_info+0x10a/0x8d5<br /> ? rtl92c_read_chip_version+0x14f/0x17e<br /> rtl_usb_probe+0x323/0x851<br /> usb_probe_interface+0x278/0x34b<br /> really_probe+0x202/0x4a4<br /> __driver_probe_device+0x166/0x1b2<br /> driver_probe_device+0x2f/0xd8<br /> [...]<br /> <br /> We propose hereby to drastically reduce the attempts of doing the I/O<br /> reads in case of failures, restricted to USB devices (given that<br /> they&amp;#39;re inherently slower than PCIe ones). By retrying up to 10 times<br /> (instead of 10000), we got reponsiveness in the reproducer, while seems<br /> reasonable to believe that there&amp;#39;s no sane USB device implementation in<br /> the field requiring this amount of retries at every I/O read in order<br /> to properly work. Based on that assumption, it&amp;#39;d be good to have it<br /> backported to stable but maybe not since driver implementation (the 10k<br /> number comes from day 0), perhaps up to 6.x series makes sense.<br /> <br /> [0] Commit 15fffc6a5624 ("driver core: Fix uevent_show() vs driver detach race")<br /> <br /> [1] A note about that: this syzkaller report presents multiple reproducers<br /> that differs by the type of emulated USB device. For this specific case,<br /> check the entry from 2024/08/08 06:23 in the list of crashes; the C repro<br /> is available at https://syzkaller.appspot.com/text?tag=ReproC&amp;x=1521fc83980000.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: prevent use-after-free due to open_cached_dir error paths<br /> <br /> If open_cached_dir() encounters an error parsing the lease from the<br /> server, the error handling may race with receiving a lease break,<br /> resulting in open_cached_dir() freeing the cfid while the queued work is<br /> pending.<br /> <br /> Update open_cached_dir() to drop refs rather than directly freeing the<br /> cfid.<br /> <br /> Have cached_dir_lease_break(), cfids_laundromat_worker(), and<br /> invalidate_all_cached_dirs() clear has_lease immediately while still<br /> holding cfids-&gt;cfid_list_lock, and then use this to also simplify the<br /> reference counting in cfids_laundromat_worker() and<br /> invalidate_all_cached_dirs().<br /> <br /> Fixes this KASAN splat (which manually injects an error and lease break<br /> in open_cached_dir()):<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in smb2_cached_lease_break+0x27/0xb0<br /> Read of size 8 at addr ffff88811cc24c10 by task kworker/3:1/65<br /> <br /> CPU: 3 UID: 0 PID: 65 Comm: kworker/3:1 Not tainted 6.12.0-rc6-g255cf264e6e5-dirty #87<br /> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020<br /> Workqueue: cifsiod smb2_cached_lease_break<br /> Call Trace:<br /> <br /> dump_stack_lvl+0x77/0xb0<br /> print_report+0xce/0x660<br /> kasan_report+0xd3/0x110<br /> smb2_cached_lease_break+0x27/0xb0<br /> process_one_work+0x50a/0xc50<br /> worker_thread+0x2ba/0x530<br /> kthread+0x17c/0x1c0<br /> ret_from_fork+0x34/0x60<br /> ret_from_fork_asm+0x1a/0x30<br /> <br /> <br /> Allocated by task 2464:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> __kasan_kmalloc+0xaa/0xb0<br /> open_cached_dir+0xa7d/0x1fb0<br /> smb2_query_path_info+0x43c/0x6e0<br /> cifs_get_fattr+0x346/0xf10<br /> cifs_get_inode_info+0x157/0x210<br /> cifs_revalidate_dentry_attr+0x2d1/0x460<br /> cifs_getattr+0x173/0x470<br /> vfs_statx_path+0x10f/0x160<br /> vfs_statx+0xe9/0x150<br /> vfs_fstatat+0x5e/0xc0<br /> __do_sys_newfstatat+0x91/0xf0<br /> do_syscall_64+0x95/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Freed by task 2464:<br /> kasan_save_stack+0x33/0x60<br /> kasan_save_track+0x14/0x30<br /> kasan_save_free_info+0x3b/0x60<br /> __kasan_slab_free+0x51/0x70<br /> kfree+0x174/0x520<br /> open_cached_dir+0x97f/0x1fb0<br /> smb2_query_path_info+0x43c/0x6e0<br /> cifs_get_fattr+0x346/0xf10<br /> cifs_get_inode_info+0x157/0x210<br /> cifs_revalidate_dentry_attr+0x2d1/0x460<br /> cifs_getattr+0x173/0x470<br /> vfs_statx_path+0x10f/0x160<br /> vfs_statx+0xe9/0x150<br /> vfs_fstatat+0x5e/0xc0<br /> __do_sys_newfstatat+0x91/0xf0<br /> do_syscall_64+0x95/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Last potentially related work creation:<br /> kasan_save_stack+0x33/0x60<br /> __kasan_record_aux_stack+0xad/0xc0<br /> insert_work+0x32/0x100<br /> __queue_work+0x5c9/0x870<br /> queue_work_on+0x82/0x90<br /> open_cached_dir+0x1369/0x1fb0<br /> smb2_query_path_info+0x43c/0x6e0<br /> cifs_get_fattr+0x346/0xf10<br /> cifs_get_inode_info+0x157/0x210<br /> cifs_revalidate_dentry_attr+0x2d1/0x460<br /> cifs_getattr+0x173/0x470<br /> vfs_statx_path+0x10f/0x160<br /> vfs_statx+0xe9/0x150<br /> vfs_fstatat+0x5e/0xc0<br /> __do_sys_newfstatat+0x91/0xf0<br /> do_syscall_64+0x95/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> The buggy address belongs to the object at ffff88811cc24c00<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 16 bytes inside of<br /> freed 1024-byte region [ffff88811cc24c00, ffff88811cc25000)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> smb: Don&amp;#39;t leak cfid when reconnect races with open_cached_dir<br /> <br /> open_cached_dir() may either race with the tcon reconnection even before<br /> compound_send_recv() or directly trigger a reconnection via<br /> SMB2_open_init() or SMB_query_info_init().<br /> <br /> The reconnection process invokes invalidate_all_cached_dirs() via<br /> cifs_mark_open_files_invalid(), which removes all cfids from the<br /> cfids-&gt;entries list but doesn&amp;#39;t drop a ref if has_lease isn&amp;#39;t true. This<br /> results in the currently-being-constructed cfid not being on the list,<br /> but still having a refcount of 2. It leaks if returned from<br /> open_cached_dir().<br /> <br /> Fix this by setting cfid-&gt;has_lease when the ref is actually taken; the<br /> cfid will not be used by other threads until it has a valid time.<br /> <br /> Addresses these kmemleaks:<br /> <br /> unreferenced object 0xffff8881090c4000 (size 1024):<br /> comm "bash", pid 1860, jiffies 4295126592<br /> hex dump (first 32 bytes):<br /> 00 01 00 00 00 00 ad de 22 01 00 00 00 00 ad de ........".......<br /> 00 ca 45 22 81 88 ff ff f8 dc 4f 04 81 88 ff ff ..E"......O.....<br /> backtrace (crc 6f58c20f):<br /> [] __kmalloc_cache_noprof+0x2be/0x350<br /> [] open_cached_dir+0x993/0x1fb0<br /> [] cifs_readdir+0x15a0/0x1d50<br /> [] iterate_dir+0x28f/0x4b0<br /> [] __x64_sys_getdents64+0xfd/0x200<br /> [] do_syscall_64+0x95/0x1a0<br /> [] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> unreferenced object 0xffff8881044fdcf8 (size 8):<br /> comm "bash", pid 1860, jiffies 4295126592<br /> hex dump (first 8 bytes):<br /> 00 cc cc cc cc cc cc cc ........<br /> backtrace (crc 10c106a9):<br /> [] __kmalloc_node_track_caller_noprof+0x363/0x480<br /> [] kstrdup+0x36/0x60<br /> [] open_cached_dir+0x9b0/0x1fb0<br /> [] cifs_readdir+0x15a0/0x1d50<br /> [] iterate_dir+0x28f/0x4b0<br /> [] __x64_sys_getdents64+0xfd/0x200<br /> [] do_syscall_64+0x95/0x1a0<br /> [] entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> And addresses these BUG splats when unmounting the SMB filesystem:<br /> <br /> BUG: Dentry ffff888140590ba0{i=1000000000080,n=/} still in use (2) [unmount of cifs cifs]<br /> WARNING: CPU: 3 PID: 3433 at fs/dcache.c:1536 umount_check+0xd0/0x100<br /> Modules linked in:<br /> CPU: 3 UID: 0 PID: 3433 Comm: bash Not tainted 6.12.0-rc4-g850925a8133c-dirty #49<br /> Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020<br /> RIP: 0010:umount_check+0xd0/0x100<br /> Code: 8d 7c 24 40 e8 31 5a f4 ff 49 8b 54 24 40 41 56 49 89 e9 45 89 e8 48 89 d9 41 57 48 89 de 48 c7 c7 80 e7 db ac e8 f0 72 9a ff 0b 58 31 c0 5a 5b 5d 41 5c 41 5d 41 5e 41 5f e9 2b e5 5d 01 41<br /> RSP: 0018:ffff88811cc27978 EFLAGS: 00010286<br /> RAX: 0000000000000000 RBX: ffff888140590ba0 RCX: ffffffffaaf20bae<br /> RDX: dffffc0000000000 RSI: 0000000000000008 RDI: ffff8881f6fb6f40<br /> RBP: ffff8881462ec000 R08: 0000000000000001 R09: ffffed1023984ee3<br /> R10: ffff88811cc2771f R11: 00000000016cfcc0 R12: ffff888134383e08<br /> R13: 0000000000000002 R14: ffff8881462ec668 R15: ffffffffaceab4c0<br /> FS: 00007f23bfa98740(0000) GS:ffff8881f6f80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000556de4a6f808 CR3: 0000000123c80000 CR4: 0000000000350ef0<br /> Call Trace:<br /> <br /> d_walk+0x6a/0x530<br /> shrink_dcache_for_umount+0x6a/0x200<br /> generic_shutdown_super+0x52/0x2a0<br /> kill_anon_super+0x22/0x40<br /> cifs_kill_sb+0x159/0x1e0<br /> deactivate_locked_super+0x66/0xe0<br /> cleanup_mnt+0x140/0x210<br /> task_work_run+0xfb/0x170<br /> syscall_exit_to_user_mode+0x29f/0x2b0<br /> do_syscall_64+0xa1/0x1a0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f23bfb93ae7<br /> Code: ff ff ff ff c3 66 0f 1f 44 00 00 48 8b 0d 11 93 0d 00 f7 d8 64 89 01 b8 ff ff ff ff eb bf 0f 1f 44 00 00 b8 50 00 00 00 0f 05 3d 01 f0 ff ff 73 01 c3 48 8b 0d e9 92 0d 00 f7 d8 64 89 <br /> ---truncated---