Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: visconti: prevent array overflow in visconti_clk_register_gates()<br /> <br /> This code was using -1 to represent that there was no reset function.<br /> Unfortunately, the -1 was stored in u8 so the if (clks[i].rs_id &gt;= 0)<br /> condition was always true. This lead to an out of bounds access in<br /> visconti_clk_register_gates().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: Fix clk_hw_get_clk() when dev is NULL<br /> <br /> Any registered clk_core structure can have a NULL pointer in its dev<br /> field. While never actually documented, this is evidenced by the wide<br /> usage of clk_register and clk_hw_register with a NULL device pointer,<br /> and the fact that the core of_clk_hw_register() function also passes a<br /> NULL device pointer.<br /> <br /> A call to clk_hw_get_clk() on a clk_hw struct whose clk_core is in that<br /> case will result in a NULL pointer derefence when it calls dev_name() on<br /> that NULL device pointer.<br /> <br /> Add a test for this case and use NULL as the dev_id if the device<br /> pointer is NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> remoteproc: qcom_q6v5_mss: Fix some leaks in q6v5_alloc_memory_region<br /> <br /> The device_node pointer is returned by of_parse_phandle() or<br /> of_get_child_by_name() with refcount incremented.<br /> We should use of_node_put() on it when done.<br /> <br /> This function only call of_node_put(node) when of_address_to_resource<br /> succeeds, missing error cases.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> clk: qcom: clk-rcg2: Update logic to calculate D value for RCG<br /> <br /> The display pixel clock has a requirement on certain newer platforms to<br /> support M/N as (2/3) and the final D value calculated results in<br /> underflow errors.<br /> As the current implementation does not check for D value is within<br /> the accepted range for a given M &amp; N value. Update the logic to<br /> calculate the final D value based on the range.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: use spin_lock to avoid hang<br /> <br /> [14696.634553] task:cat state:D stack: 0 pid:1613738 ppid:1613735 flags:0x00000004<br /> [14696.638285] Call Trace:<br /> [14696.639038] <br /> [14696.640032] __schedule+0x302/0x930<br /> [14696.640969] schedule+0x58/0xd0<br /> [14696.641799] schedule_preempt_disabled+0x18/0x30<br /> [14696.642890] __mutex_lock.constprop.0+0x2fb/0x4f0<br /> [14696.644035] ? mod_objcg_state+0x10c/0x310<br /> [14696.645040] ? obj_cgroup_charge+0xe1/0x170<br /> [14696.646067] __mutex_lock_slowpath+0x13/0x20<br /> [14696.647126] mutex_lock+0x34/0x40<br /> [14696.648070] stat_show+0x25/0x17c0 [f2fs]<br /> [14696.649218] seq_read_iter+0x120/0x4b0<br /> [14696.650289] ? aa_file_perm+0x12a/0x500<br /> [14696.651357] ? lru_cache_add+0x1c/0x20<br /> [14696.652470] seq_read+0xfd/0x140<br /> [14696.653445] full_proxy_read+0x5c/0x80<br /> [14696.654535] vfs_read+0xa0/0x1a0<br /> [14696.655497] ksys_read+0x67/0xe0<br /> [14696.656502] __x64_sys_read+0x1a/0x20<br /> [14696.657580] do_syscall_64+0x3b/0xc0<br /> [14696.658671] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> [14696.660068] RIP: 0033:0x7efe39df1cb2<br /> [14696.661133] RSP: 002b:00007ffc8badd948 EFLAGS: 00000246 ORIG_RAX: 0000000000000000<br /> [14696.662958] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007efe39df1cb2<br /> [14696.664757] RDX: 0000000000020000 RSI: 00007efe399df000 RDI: 0000000000000003<br /> [14696.666542] RBP: 00007efe399df000 R08: 00007efe399de010 R09: 00007efe399de010<br /> [14696.668363] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000000000<br /> [14696.670155] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000<br /> [14696.671965] <br /> [14696.672826] task:umount state:D stack: 0 pid:1614985 ppid:1614984 flags:0x00004000<br /> [14696.674930] Call Trace:<br /> [14696.675903] <br /> [14696.676780] __schedule+0x302/0x930<br /> [14696.677927] schedule+0x58/0xd0<br /> [14696.679019] schedule_preempt_disabled+0x18/0x30<br /> [14696.680412] __mutex_lock.constprop.0+0x2fb/0x4f0<br /> [14696.681783] ? destroy_inode+0x65/0x80<br /> [14696.683006] __mutex_lock_slowpath+0x13/0x20<br /> [14696.684305] mutex_lock+0x34/0x40<br /> [14696.685442] f2fs_destroy_stats+0x1e/0x60 [f2fs]<br /> [14696.686803] f2fs_put_super+0x158/0x390 [f2fs]<br /> [14696.688238] generic_shutdown_super+0x7a/0x120<br /> [14696.689621] kill_block_super+0x27/0x50<br /> [14696.690894] kill_f2fs_super+0x7f/0x100 [f2fs]<br /> [14696.692311] deactivate_locked_super+0x35/0xa0<br /> [14696.693698] deactivate_super+0x40/0x50<br /> [14696.694985] cleanup_mnt+0x139/0x190<br /> [14696.696209] __cleanup_mnt+0x12/0x20<br /> [14696.697390] task_work_run+0x64/0xa0<br /> [14696.698587] exit_to_user_mode_prepare+0x1b7/0x1c0<br /> [14696.700053] syscall_exit_to_user_mode+0x27/0x50<br /> [14696.701418] do_syscall_64+0x48/0xc0<br /> [14696.702630] entry_SYSCALL_64_after_hwframe+0x44/0xae

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on curseg-&gt;alloc_type<br /> <br /> As Wenqing Liu reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=215657<br /> <br /> - Overview<br /> UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2 when mount and operate a corrupted image<br /> <br /> - Reproduce<br /> tested on kernel 5.17-rc4, 5.17-rc6<br /> <br /> 1. mkdir test_crash<br /> 2. cd test_crash<br /> 3. unzip tmp2.zip<br /> 4. mkdir mnt<br /> 5. ./single_test.sh f2fs 2<br /> <br /> - Kernel dump<br /> [ 46.434454] loop0: detected capacity change from 0 to 131072<br /> [ 46.529839] F2FS-fs (loop0): Mounted with checkpoint version = 7548c2d9<br /> [ 46.738319] ================================================================================<br /> [ 46.738412] UBSAN: array-index-out-of-bounds in fs/f2fs/segment.c:3460:2<br /> [ 46.738475] index 231 is out of range for type &amp;#39;unsigned int [2]&amp;#39;<br /> [ 46.738539] CPU: 2 PID: 939 Comm: umount Not tainted 5.17.0-rc6 #1<br /> [ 46.738547] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> [ 46.738551] Call Trace:<br /> [ 46.738556] <br /> [ 46.738563] dump_stack_lvl+0x47/0x5c<br /> [ 46.738581] ubsan_epilogue+0x5/0x50<br /> [ 46.738592] __ubsan_handle_out_of_bounds+0x68/0x80<br /> [ 46.738604] f2fs_allocate_data_block+0xdff/0xe60 [f2fs]<br /> [ 46.738819] do_write_page+0xef/0x210 [f2fs]<br /> [ 46.738934] f2fs_do_write_node_page+0x3f/0x80 [f2fs]<br /> [ 46.739038] __write_node_page+0x2b7/0x920 [f2fs]<br /> [ 46.739162] f2fs_sync_node_pages+0x943/0xb00 [f2fs]<br /> [ 46.739293] f2fs_write_checkpoint+0x7bb/0x1030 [f2fs]<br /> [ 46.739405] kill_f2fs_super+0x125/0x150 [f2fs]<br /> [ 46.739507] deactivate_locked_super+0x60/0xc0<br /> [ 46.739517] deactivate_super+0x70/0xb0<br /> [ 46.739524] cleanup_mnt+0x11a/0x200<br /> [ 46.739532] __cleanup_mnt+0x16/0x20<br /> [ 46.739538] task_work_run+0x67/0xa0<br /> [ 46.739547] exit_to_user_mode_prepare+0x18c/0x1a0<br /> [ 46.739559] syscall_exit_to_user_mode+0x26/0x40<br /> [ 46.739568] do_syscall_64+0x46/0xb0<br /> [ 46.739584] entry_SYSCALL_64_after_hwframe+0x44/0xae<br /> <br /> The root cause is we missed to do sanity check on curseg-&gt;alloc_type,<br /> result in out-of-bound accessing on sbi-&gt;block_count[] array, fix it.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: don&amp;#39;t BUG if someone dirty pages without asking ext4 first<br /> <br /> [un]pin_user_pages_remote is dirtying pages without properly warning<br /> the file system in advance. A related race was noted by Jan Kara in<br /> 2018[1]; however, more recently instead of it being a very hard-to-hit<br /> race, it could be reliably triggered by process_vm_writev(2) which was<br /> discovered by Syzbot[2].<br /> <br /> This is technically a bug in mm/gup.c, but arguably ext4 is fragile in<br /> that if some other kernel subsystem dirty pages without properly<br /> notifying the file system using page_mkwrite(), ext4 will BUG, while<br /> other file systems will not BUG (although data will still be lost).<br /> <br /> So instead of crashing with a BUG, issue a warning (since there may be<br /> potential data loss) and just mark the page as clean to avoid<br /> unprivileged denial of service attacks until the problem can be<br /> properly fixed. More discussion and background can be found in the<br /> thread starting at [2].<br /> <br /> [1] https://lore.kernel.org/linux-mm/20180103100430.GE4911@quack2.suse.cz<br /> [2] https://lore.kernel.org/r/Yg0m6IjcNmfaSokM@google.com

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> parisc: Fix non-access data TLB cache flush faults<br /> <br /> When a page is not present, we get non-access data TLB faults from<br /> the fdc and fic instructions in flush_user_dcache_range_asm and<br /> flush_user_icache_range_asm. When these occur, the cache line is<br /> not invalidated and potentially we get memory corruption. The<br /> problem was hidden by the nullification of the flush instructions.<br /> <br /> These faults also affect performance. With pa8800/pa8900 processors,<br /> there will be 32 faults per 4 KB page since the cache line is 128<br /> bytes. There will be more faults with earlier processors.<br /> <br /> The problem is fixed by using flush_cache_pages(). It does the flush<br /> using a tmp alias mapping.<br /> <br /> The flush_cache_pages() call in flush_cache_range() flushed too<br /> large a range.<br /> <br /> V2: Remove unnecessary preempt_disable() and preempt_enable() calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> spi: fsi: Implement a timeout for polling status<br /> <br /> The data transfer routines must poll the status register to<br /> determine when more data can be shifted in or out. If the hardware<br /> gets into a bad state, these polling loops may never exit. Prevent<br /> this by returning an error if a timeout is exceeded.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix ext4_mb_mark_bb() with flex_bg with fast_commit<br /> <br /> In case of flex_bg feature (which is by default enabled), extents for<br /> any given inode might span across blocks from two different block group.<br /> ext4_mb_mark_bb() only reads the buffer_head of block bitmap once for the<br /> starting block group, but it fails to read it again when the extent length<br /> boundary overflows to another block group. Then in this below loop it<br /> accesses memory beyond the block group bitmap buffer_head and results<br /> into a data abort.<br /> <br /> for (i = 0; i b_data) == !state)<br /> already++;<br /> <br /> This patch adds this functionality for checking block group boundary in<br /> ext4_mb_mark_bb() and update the buffer_head(bitmap_bh) for every different<br /> block group.<br /> <br /> w/o this patch, I was easily able to hit a data access abort using Power platform.<br /> <br /> <br /> [ 74.327662] EXT4-fs error (device loop3): ext4_mb_generate_buddy:1141: group 11, block bitmap and bg descriptor inconsistent: 21248 vs 23294 free clusters<br /> [ 74.533214] EXT4-fs (loop3): shut down requested (2)<br /> [ 74.536705] Aborting journal on device loop3-8.<br /> [ 74.702705] BUG: Unable to handle kernel data access on read at 0xc00000005e980000<br /> [ 74.703727] Faulting instruction address: 0xc0000000007bffb8<br /> cpu 0xd: Vector: 300 (Data Access) at [c000000015db7060]<br /> pc: c0000000007bffb8: ext4_mb_mark_bb+0x198/0x5a0<br /> lr: c0000000007bfeec: ext4_mb_mark_bb+0xcc/0x5a0<br /> sp: c000000015db7300<br /> msr: 800000000280b033<br /> dar: c00000005e980000<br /> dsisr: 40000000<br /> current = 0xc000000027af6880<br /> paca = 0xc00000003ffd5200 irqmask: 0x03 irq_happened: 0x01<br /> pid = 5167, comm = mount<br /> <br /> enter ? for help<br /> [c000000015db7380] c000000000782708 ext4_ext_clear_bb+0x378/0x410<br /> [c000000015db7400] c000000000813f14 ext4_fc_replay+0x1794/0x2000<br /> [c000000015db7580] c000000000833f7c do_one_pass+0xe9c/0x12a0<br /> [c000000015db7710] c000000000834504 jbd2_journal_recover+0x184/0x2d0<br /> [c000000015db77c0] c000000000841398 jbd2_journal_load+0x188/0x4a0<br /> [c000000015db7880] c000000000804de8 ext4_fill_super+0x2638/0x3e10<br /> [c000000015db7a40] c0000000005f8404 get_tree_bdev+0x2b4/0x350<br /> [c000000015db7ae0] c0000000007ef058 ext4_get_tree+0x28/0x40<br /> [c000000015db7b00] c0000000005f6344 vfs_get_tree+0x44/0x100<br /> [c000000015db7b70] c00000000063c408 path_mount+0xdd8/0xe70<br /> [c000000015db7c40] c00000000063c8f0 sys_mount+0x450/0x550<br /> [c000000015db7d50] c000000000035770 system_call_exception+0x4a0/0x4e0<br /> [c000000015db7e10] c00000000000c74c system_call_common+0xec/0x250

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> PM: core: keep irq flags in device_pm_check_callbacks()<br /> <br /> The function device_pm_check_callbacks() can be called under the spin<br /> lock (in the reported case it happens from genpd_add_device() -&gt;<br /> dev_pm_domain_set(), when the genpd uses spinlocks rather than mutexes.<br /> <br /> However this function uncoditionally uses spin_lock_irq() /<br /> spin_unlock_irq(), thus not preserving the CPU flags. Use the<br /> irqsave/irqrestore instead.<br /> <br /> The backtrace for the reference:<br /> [ 2.752010] ------------[ cut here ]------------<br /> [ 2.756769] raw_local_irq_restore() called with IRQs enabled<br /> [ 2.762596] WARNING: CPU: 4 PID: 1 at kernel/locking/irqflag-debug.c:10 warn_bogus_irq_restore+0x34/0x50<br /> [ 2.772338] Modules linked in:<br /> [ 2.775487] CPU: 4 PID: 1 Comm: swapper/0 Tainted: G S 5.17.0-rc6-00384-ge330d0d82eff-dirty #684<br /> [ 2.781384] Freeing initrd memory: 46024K<br /> [ 2.785839] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 2.785841] pc : warn_bogus_irq_restore+0x34/0x50<br /> [ 2.785844] lr : warn_bogus_irq_restore+0x34/0x50<br /> [ 2.785846] sp : ffff80000805b7d0<br /> [ 2.785847] x29: ffff80000805b7d0 x28: 0000000000000000 x27: 0000000000000002<br /> [ 2.785850] x26: ffffd40e80930b18 x25: ffff7ee2329192b8 x24: ffff7edfc9f60800<br /> [ 2.785853] x23: ffffd40e80930b18 x22: ffffd40e80930d30 x21: ffff7edfc0dffa00<br /> [ 2.785856] x20: ffff7edfc09e3768 x19: 0000000000000000 x18: ffffffffffffffff<br /> [ 2.845775] x17: 6572206f74206465 x16: 6c696166203a3030 x15: ffff80008805b4f7<br /> [ 2.853108] x14: 0000000000000000 x13: ffffd40e809550b0 x12: 00000000000003d8<br /> [ 2.860441] x11: 0000000000000148 x10: ffffd40e809550b0 x9 : ffffd40e809550b0<br /> [ 2.867774] x8 : 00000000ffffefff x7 : ffffd40e809ad0b0 x6 : ffffd40e809ad0b0<br /> [ 2.875107] x5 : 000000000000bff4 x4 : 0000000000000000 x3 : 0000000000000000<br /> [ 2.882440] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff7edfc03a8000<br /> [ 2.889774] Call trace:<br /> [ 2.892290] warn_bogus_irq_restore+0x34/0x50<br /> [ 2.896770] _raw_spin_unlock_irqrestore+0x94/0xa0<br /> [ 2.901690] genpd_unlock_spin+0x20/0x30<br /> [ 2.905724] genpd_add_device+0x100/0x2d0<br /> [ 2.909850] __genpd_dev_pm_attach+0xa8/0x23c<br /> [ 2.914329] genpd_dev_pm_attach_by_id+0xc4/0x190<br /> [ 2.919167] genpd_dev_pm_attach_by_name+0x3c/0xd0<br /> [ 2.924086] dev_pm_domain_attach_by_name+0x24/0x30<br /> [ 2.929102] psci_dt_attach_cpu+0x24/0x90<br /> [ 2.933230] psci_cpuidle_probe+0x2d4/0x46c<br /> [ 2.937534] platform_probe+0x68/0xe0<br /> [ 2.941304] really_probe.part.0+0x9c/0x2fc<br /> [ 2.945605] __driver_probe_device+0x98/0x144<br /> [ 2.950085] driver_probe_device+0x44/0x15c<br /> [ 2.954385] __device_attach_driver+0xb8/0x120<br /> [ 2.958950] bus_for_each_drv+0x78/0xd0<br /> [ 2.962896] __device_attach+0xd8/0x180<br /> [ 2.966843] device_initial_probe+0x14/0x20<br /> [ 2.971144] bus_probe_device+0x9c/0xa4<br /> [ 2.975092] device_add+0x380/0x88c<br /> [ 2.978679] platform_device_add+0x114/0x234<br /> [ 2.983067] platform_device_register_full+0x100/0x190<br /> [ 2.988344] psci_idle_init+0x6c/0xb0<br /> [ 2.992113] do_one_initcall+0x74/0x3a0<br /> [ 2.996060] kernel_init_freeable+0x2fc/0x384<br /> [ 3.000543] kernel_init+0x28/0x130<br /> [ 3.004132] ret_from_fork+0x10/0x20<br /> [ 3.007817] irq event stamp: 319826<br /> [ 3.011404] hardirqs last enabled at (319825): [] __up_console_sem+0x78/0x84<br /> [ 3.020332] hardirqs last disabled at (319826): [] el1_dbg+0x24/0x8c<br /> [ 3.028458] softirqs last enabled at (318312): [] _stext+0x410/0x588<br /> [ 3.036678] softirqs last disabled at (318299): [] __irq_exit_rcu+0x158/0x174<br /> [ 3.045607] ---[ end trace 0000000000000000 ]---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bfq: fix use-after-free in bfq_dispatch_request<br /> <br /> KASAN reports a use-after-free report when doing normal scsi-mq test<br /> <br /> [69832.239032] ==================================================================<br /> [69832.241810] BUG: KASAN: use-after-free in bfq_dispatch_request+0x1045/0x44b0<br /> [69832.243267] Read of size 8 at addr ffff88802622ba88 by task kworker/3:1H/155<br /> [69832.244656]<br /> [69832.245007] CPU: 3 PID: 155 Comm: kworker/3:1H Not tainted 5.10.0-10295-g576c6382529e #8<br /> [69832.246626] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> [69832.249069] Workqueue: kblockd blk_mq_run_work_fn<br /> [69832.250022] Call Trace:<br /> [69832.250541] dump_stack+0x9b/0xce<br /> [69832.251232] ? bfq_dispatch_request+0x1045/0x44b0<br /> [69832.252243] print_address_description.constprop.6+0x3e/0x60<br /> [69832.253381] ? __cpuidle_text_end+0x5/0x5<br /> [69832.254211] ? vprintk_func+0x6b/0x120<br /> [69832.254994] ? bfq_dispatch_request+0x1045/0x44b0<br /> [69832.255952] ? bfq_dispatch_request+0x1045/0x44b0<br /> [69832.256914] kasan_report.cold.9+0x22/0x3a<br /> [69832.257753] ? bfq_dispatch_request+0x1045/0x44b0<br /> [69832.258755] check_memory_region+0x1c1/0x1e0<br /> [69832.260248] bfq_dispatch_request+0x1045/0x44b0<br /> [69832.261181] ? bfq_bfqq_expire+0x2440/0x2440<br /> [69832.262032] ? blk_mq_delay_run_hw_queues+0xf9/0x170<br /> [69832.263022] __blk_mq_do_dispatch_sched+0x52f/0x830<br /> [69832.264011] ? blk_mq_sched_request_inserted+0x100/0x100<br /> [69832.265101] __blk_mq_sched_dispatch_requests+0x398/0x4f0<br /> [69832.266206] ? blk_mq_do_dispatch_ctx+0x570/0x570<br /> [69832.267147] ? __switch_to+0x5f4/0xee0<br /> [69832.267898] blk_mq_sched_dispatch_requests+0xdf/0x140<br /> [69832.268946] __blk_mq_run_hw_queue+0xc0/0x270<br /> [69832.269840] blk_mq_run_work_fn+0x51/0x60<br /> [69832.278170] process_one_work+0x6d4/0xfe0<br /> [69832.278984] worker_thread+0x91/0xc80<br /> [69832.279726] ? __kthread_parkme+0xb0/0x110<br /> [69832.280554] ? process_one_work+0xfe0/0xfe0<br /> [69832.281414] kthread+0x32d/0x3f0<br /> [69832.282082] ? kthread_park+0x170/0x170<br /> [69832.282849] ret_from_fork+0x1f/0x30<br /> [69832.283573]<br /> [69832.283886] Allocated by task 7725:<br /> [69832.284599] kasan_save_stack+0x19/0x40<br /> [69832.285385] __kasan_kmalloc.constprop.2+0xc1/0xd0<br /> [69832.286350] kmem_cache_alloc_node+0x13f/0x460<br /> [69832.287237] bfq_get_queue+0x3d4/0x1140<br /> [69832.287993] bfq_get_bfqq_handle_split+0x103/0x510<br /> [69832.289015] bfq_init_rq+0x337/0x2d50<br /> [69832.289749] bfq_insert_requests+0x304/0x4e10<br /> [69832.290634] blk_mq_sched_insert_requests+0x13e/0x390<br /> [69832.291629] blk_mq_flush_plug_list+0x4b4/0x760<br /> [69832.292538] blk_flush_plug_list+0x2c5/0x480<br /> [69832.293392] io_schedule_prepare+0xb2/0xd0<br /> [69832.294209] io_schedule_timeout+0x13/0x80<br /> [69832.295014] wait_for_common_io.constprop.1+0x13c/0x270<br /> [69832.296137] submit_bio_wait+0x103/0x1a0<br /> [69832.296932] blkdev_issue_discard+0xe6/0x160<br /> [69832.297794] blk_ioctl_discard+0x219/0x290<br /> [69832.298614] blkdev_common_ioctl+0x50a/0x1750<br /> [69832.304715] blkdev_ioctl+0x470/0x600<br /> [69832.305474] block_ioctl+0xde/0x120<br /> [69832.306232] vfs_ioctl+0x6c/0xc0<br /> [69832.306877] __se_sys_ioctl+0x90/0xa0<br /> [69832.307629] do_syscall_64+0x2d/0x40<br /> [69832.308362] entry_SYSCALL_64_after_hwframe+0x44/0xa9<br /> [69832.309382]<br /> [69832.309701] Freed by task 155:<br /> [69832.310328] kasan_save_stack+0x19/0x40<br /> [69832.311121] kasan_set_track+0x1c/0x30<br /> [69832.311868] kasan_set_free_info+0x1b/0x30<br /> [69832.312699] __kasan_slab_free+0x111/0x160<br /> [69832.313524] kmem_cache_free+0x94/0x460<br /> [69832.314367] bfq_put_queue+0x582/0x940<br /> [69832.315112] __bfq_bfqd_reset_in_service+0x166/0x1d0<br /> [69832.317275] bfq_bfqq_expire+0xb27/0x2440<br /> [69832.318084] bfq_dispatch_request+0x697/0x44b0<br /> [69832.318991] __blk_mq_do_dispatch_sched+0x52f/0x830<br /> [69832.319984] __blk_mq_sched_dispatch_requests+0x398/0x4f0<br /> [69832.321087] blk_mq_sched_dispatch_requests+0xdf/0x140<br /> [69832.322225] __blk_mq_run_hw_queue+0xc0/0x270<br /> [69832.323114] blk_mq_run_work_fn+0x51/0x6<br /> ---truncated---