Vulnerabilities

Missing Authorization vulnerability in Metagauss ProfileGrid profilegrid-user-profiles-groups-and-communities.This issue affects ProfileGrid : from n/a through

Missing Authorization vulnerability in RexTheme WP VR wpvr allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects WP VR: from n/a through

Missing Authorization vulnerability in colorlibplugins Simple Custom Post Order simple-custom-post-order allows Exploiting Incorrectly Configured Access Control Security Levels.This issue affects Simple Custom Post Order: from n/a through

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: always wait for both firmware loading attempts<br /> <br /> In &amp;#39;rtw_wait_firmware_completion()&amp;#39;, always wait for both (regular and<br /> wowlan) firmware loading attempts. Otherwise if &amp;#39;rtw_usb_intf_init()&amp;#39;<br /> has failed in &amp;#39;rtw_usb_probe()&amp;#39;, &amp;#39;rtw_usb_disconnect()&amp;#39; may issue<br /> &amp;#39;ieee80211_free_hw()&amp;#39; when one of &amp;#39;rtw_load_firmware_cb()&amp;#39; (usually<br /> the wowlan one) is still in progress, causing UAF detected by KASAN.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> netkit: Assign missing bpf_net_context<br /> <br /> During the introduction of struct bpf_net_context handling for<br /> XDP-redirect, the netkit driver has been missed, which also requires it<br /> because NETKIT_REDIRECT invokes skb_do_redirect() which is accessing the<br /> per-CPU variables. Otherwise we see the following crash:<br /> <br /> BUG: kernel NULL pointer dereference, address: 0000000000000038<br /> bpf_redirect()<br /> netkit_xmit()<br /> dev_hard_start_xmit()<br /> <br /> Set the bpf_net_context before invoking netkit_xmit() program within the<br /> netkit driver.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> af_unix: Don&amp;#39;t return OOB skb in manage_oob().<br /> <br /> syzbot reported use-after-free in unix_stream_recv_urg(). [0]<br /> <br /> The scenario is<br /> <br /> 1. send(MSG_OOB)<br /> 2. recv(MSG_OOB)<br /> -&gt; The consumed OOB remains in recv queue<br /> 3. send(MSG_OOB)<br /> 4. recv()<br /> -&gt; manage_oob() returns the next skb of the consumed OOB<br /> -&gt; This is also OOB, but unix_sk(sk)-&gt;oob_skb is not cleared<br /> 5. recv(MSG_OOB)<br /> -&gt; unix_sk(sk)-&gt;oob_skb is used but already freed<br /> <br /> The recent commit 8594d9b85c07 ("af_unix: Don&amp;#39;t call skb_get() for OOB<br /> skb.") uncovered the issue.<br /> <br /> If the OOB skb is consumed and the next skb is peeked in manage_oob(),<br /> we still need to check if the skb is OOB.<br /> <br /> Let&amp;#39;s do so by falling back to the following checks in manage_oob()<br /> and add the test case in selftest.<br /> <br /> Note that we need to add a similar check for SIOCATMARK.<br /> <br /> [0]:<br /> BUG: KASAN: slab-use-after-free in unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959<br /> Read of size 4 at addr ffff8880326abcc4 by task syz-executor178/5235<br /> <br /> CPU: 0 UID: 0 PID: 5235 Comm: syz-executor178 Not tainted 6.11.0-rc5-syzkaller-00742-gfbdaffe41adc #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:93 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119<br /> print_address_description mm/kasan/report.c:377 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:488<br /> kasan_report+0x143/0x180 mm/kasan/report.c:601<br /> unix_stream_read_actor+0xa6/0xb0 net/unix/af_unix.c:2959<br /> unix_stream_recv_urg+0x1df/0x320 net/unix/af_unix.c:2640<br /> unix_stream_read_generic+0x2456/0x2520 net/unix/af_unix.c:2778<br /> unix_stream_recvmsg+0x22b/0x2c0 net/unix/af_unix.c:2996<br /> sock_recvmsg_nosec net/socket.c:1046 [inline]<br /> sock_recvmsg+0x22f/0x280 net/socket.c:1068<br /> ____sys_recvmsg+0x1db/0x470 net/socket.c:2816<br /> ___sys_recvmsg net/socket.c:2858 [inline]<br /> __sys_recvmsg+0x2f0/0x3e0 net/socket.c:2888<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> RIP: 0033:0x7f5360d6b4e9<br /> Code: 48 83 c4 28 c3 e8 37 17 00 00 0f 1f 80 00 00 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48<br /> RSP: 002b:00007fff29b3a458 EFLAGS: 00000246 ORIG_RAX: 000000000000002f<br /> RAX: ffffffffffffffda RBX: 00007fff29b3a638 RCX: 00007f5360d6b4e9<br /> RDX: 0000000000002001 RSI: 0000000020000640 RDI: 0000000000000003<br /> RBP: 00007f5360dde610 R08: 0000000000000000 R09: 0000000000000000<br /> R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001<br /> R13: 00007fff29b3a628 R14: 0000000000000001 R15: 0000000000000001<br /> <br /> <br /> Allocated by task 5235:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> unpoison_slab_object mm/kasan/common.c:312 [inline]<br /> __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338<br /> kasan_slab_alloc include/linux/kasan.h:201 [inline]<br /> slab_post_alloc_hook mm/slub.c:3988 [inline]<br /> slab_alloc_node mm/slub.c:4037 [inline]<br /> kmem_cache_alloc_node_noprof+0x16b/0x320 mm/slub.c:4080<br /> __alloc_skb+0x1c3/0x440 net/core/skbuff.c:667<br /> alloc_skb include/linux/skbuff.h:1320 [inline]<br /> alloc_skb_with_frags+0xc3/0x770 net/core/skbuff.c:6528<br /> sock_alloc_send_pskb+0x91a/0xa60 net/core/sock.c:2815<br /> sock_alloc_send_skb include/net/sock.h:1778 [inline]<br /> queue_oob+0x108/0x680 net/unix/af_unix.c:2198<br /> unix_stream_sendmsg+0xd24/0xf80 net/unix/af_unix.c:2351<br /> sock_sendmsg_nosec net/socket.c:730 [inline]<br /> __sock_sendmsg+0x221/0x270 net/socket.c:745<br /> ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597<br /> ___sys_sendmsg net/socket.c:2651 [inline]<br /> __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 5235:<br /> kasan_save_stack mm/kasan/common.c:47<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7996: use hweight16 to get correct tx antenna<br /> <br /> The chainmask is u16 so using hweight8 cannot get correct tx_ant.<br /> Without this patch, the tx_ant of band 2 would be -1 and lead to the<br /> following issue:<br /> BUG: KASAN: stack-out-of-bounds in mt7996_mcu_add_sta+0x12e0/0x16e0 [mt7996e]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mt76: mt7915: fix oops on non-dbdc mt7986<br /> <br /> mt7915_band_config() sets band_idx = 1 on the main phy for mt7986<br /> with MT7975_ONE_ADIE or MT7976_ONE_ADIE.<br /> <br /> Commit 0335c034e726 ("wifi: mt76: fix race condition related to<br /> checking tx queue fill status") introduced a dereference of the<br /> phys array indirectly indexed by band_idx via wcid-&gt;phy_idx in<br /> mt76_wcid_cleanup(). This caused the following Oops on affected<br /> mt7986 devices:<br /> <br /> Unable to handle kernel read from unreadable memory at virtual address 0000000000000024<br /> Mem abort info:<br /> ESR = 0x0000000096000005<br /> EC = 0x25: DABT (current EL), IL = 32 bits<br /> SET = 0, FnV = 0<br /> EA = 0, S1PTW = 0<br /> FSC = 0x05: level 1 translation fault<br /> Data abort info:<br /> ISV = 0, ISS = 0x00000005<br /> CM = 0, WnR = 0<br /> user pgtable: 4k pages, 39-bit VAs, pgdp=0000000042545000<br /> [0000000000000024] pgd=0000000000000000, p4d=0000000000000000, pud=0000000000000000<br /> Internal error: Oops: 0000000096000005 [#1] SMP<br /> Modules linked in: ... mt7915e mt76_connac_lib mt76 mac80211 cfg80211 ...<br /> CPU: 2 PID: 1631 Comm: hostapd Not tainted 5.15.150 #0<br /> Hardware name: ZyXEL EX5700 (Telenor) (DT)<br /> pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : mt76_wcid_cleanup+0x84/0x22c [mt76]<br /> lr : mt76_wcid_cleanup+0x64/0x22c [mt76]<br /> sp : ffffffc00a803700<br /> x29: ffffffc00a803700 x28: ffffff80008f7300 x27: ffffff80003f3c00<br /> x26: ffffff80000a7880 x25: ffffffc008c26e00 x24: 0000000000000001<br /> x23: ffffffc000a68114 x22: 0000000000000000 x21: ffffff8004172cc8<br /> x20: ffffffc00a803748 x19: ffffff8004152020 x18: 0000000000000000<br /> x17: 00000000000017c0 x16: ffffffc008ef5000 x15: 0000000000000be0<br /> x14: ffffff8004172e28 x13: ffffff8004172e28 x12: 0000000000000000<br /> x11: 0000000000000000 x10: ffffff8004172e30 x9 : ffffff8004172e28<br /> x8 : 0000000000000000 x7 : ffffff8004156020 x6 : 0000000000000000<br /> x5 : 0000000000000031 x4 : 0000000000000000 x3 : 0000000000000001<br /> x2 : 0000000000000000 x1 : ffffff80008f7300 x0 : 0000000000000024<br /> Call trace:<br /> mt76_wcid_cleanup+0x84/0x22c [mt76]<br /> __mt76_sta_remove+0x70/0xbc [mt76]<br /> mt76_sta_state+0x8c/0x1a4 [mt76]<br /> mt7915_eeprom_get_power_delta+0x11e4/0x23a0 [mt7915e]<br /> drv_sta_state+0x144/0x274 [mac80211]<br /> sta_info_move_state+0x1cc/0x2a4 [mac80211]<br /> sta_set_sinfo+0xaf8/0xc24 [mac80211]<br /> sta_info_destroy_addr_bss+0x4c/0x6c [mac80211]<br /> <br /> ieee80211_color_change_finish+0x1c08/0x1e70 [mac80211]<br /> cfg80211_check_station_change+0x1360/0x4710 [cfg80211]<br /> genl_family_rcv_msg_doit+0xb4/0x110<br /> genl_rcv_msg+0xd0/0x1bc<br /> netlink_rcv_skb+0x58/0x120<br /> genl_rcv+0x34/0x50<br /> netlink_unicast+0x1f0/0x2ec<br /> netlink_sendmsg+0x198/0x3d0<br /> ____sys_sendmsg+0x1b0/0x210<br /> ___sys_sendmsg+0x80/0xf0<br /> __sys_sendmsg+0x44/0xa0<br /> __arm64_sys_sendmsg+0x20/0x30<br /> invoke_syscall.constprop.0+0x4c/0xe0<br /> do_el0_svc+0x40/0xd0<br /> el0_svc+0x14/0x4c<br /> el0t_64_sync_handler+0x100/0x110<br /> el0t_64_sync+0x15c/0x160<br /> Code: d2800002 910092c0 52800023 f9800011 (885f7c01)<br /> ---[ end trace 7e42dd9a39ed2281 ]---<br /> <br /> Fix by using mt76_dev_phy() which will map band_idx to the correct phy<br /> for all hardware combinations.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ARM: 9410/1: vfp: Use asm volatile in fmrx/fmxr macros<br /> <br /> Floating point instructions in userspace can crash some arm kernels<br /> built with clang/LLD 17.0.6:<br /> <br /> BUG: unsupported FP instruction in kernel mode<br /> FPEXC == 0xc0000780<br /> Internal error: Oops - undefined instruction: 0 [#1] ARM<br /> CPU: 0 PID: 196 Comm: vfp-reproducer Not tainted 6.10.0 #1<br /> Hardware name: BCM2835<br /> PC is at vfp_support_entry+0xc8/0x2cc<br /> LR is at do_undefinstr+0xa8/0x250<br /> pc : [] lr : [] psr: a0000013<br /> sp : dc8d1f68 ip : 60000013 fp : bedea19c<br /> r10: ec532b17 r9 : 00000010 r8 : 0044766c<br /> r7 : c0000780 r6 : ec532b17 r5 : c1c13800 r4 : dc8d1fb0<br /> r3 : c10072c4 r2 : c0101c88 r1 : ec532b17 r0 : 0044766c<br /> Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none<br /> Control: 00c5387d Table: 0251c008 DAC: 00000051<br /> Register r0 information: non-paged memory<br /> Register r1 information: vmalloc memory<br /> Register r2 information: non-slab/vmalloc memory<br /> Register r3 information: non-slab/vmalloc memory<br /> Register r4 information: 2-page vmalloc region<br /> Register r5 information: slab kmalloc-cg-2k<br /> Register r6 information: vmalloc memory<br /> Register r7 information: non-slab/vmalloc memory<br /> Register r8 information: non-paged memory<br /> Register r9 information: zero-size pointer<br /> Register r10 information: vmalloc memory<br /> Register r11 information: non-paged memory<br /> Register r12 information: non-paged memory<br /> Process vfp-reproducer (pid: 196, stack limit = 0x61aaaf8b)<br /> Stack: (0xdc8d1f68 to 0xdc8d2000)<br /> 1f60: 0000081f b6f69300 0000000f c10073f4 c10072c4 dc8d1fb0<br /> 1f80: ec532b17 0c532b17 0044766c b6f9ccd8 00000000 c010a80c 00447670 60000010<br /> 1fa0: ffffffff c1c13800 00c5387d c0100f10 b6f68af8 00448fc0 00000000 bedea188<br /> 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c<br /> 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff 00000000 00000000<br /> Call trace:<br /> [] (vfp_support_entry) from [] (do_undefinstr+0xa8/0x250)<br /> [] (do_undefinstr) from [] (__und_usr+0x70/0x80)<br /> Exception stack(0xdc8d1fb0 to 0xdc8d1ff8)<br /> 1fa0: b6f68af8 00448fc0 00000000 bedea188<br /> 1fc0: bedea314 00000001 00448ebc b6f9d000 00447608 b6f9ccd8 00000000 bedea19c<br /> 1fe0: bede9198 bedea188 b6e1061c 0044766c 60000010 ffffffff<br /> Code: 0a000061 e3877202 e594003c e3a09010 (eef16a10)<br /> ---[ end trace 0000000000000000 ]---<br /> Kernel panic - not syncing: Fatal exception in interrupt<br /> ---[ end Kernel panic - not syncing: Fatal exception in interrupt ]---<br /> <br /> This is a minimal userspace reproducer on a Raspberry Pi Zero W:<br /> <br /> #include <br /> #include <br /> <br /> int main(void)<br /> {<br /> double v = 1.0;<br /> printf("%fn", NAN + *(volatile double *)&amp;v);<br /> return 0;<br /> }<br /> <br /> Another way to consistently trigger the oops is:<br /> <br /> calvin@raspberry-pi-zero-w ~$ python -c "import json"<br /> <br /> The bug reproduces only when the kernel is built with DYNAMIC_DEBUG=n,<br /> because the pr_debug() calls act as barriers even when not activated.<br /> <br /> This is the output from the same kernel source built with the same<br /> compiler and DYNAMIC_DEBUG=y, where the userspace reproducer works as<br /> expected:<br /> <br /> VFP: bounce: trigger ec532b17 fpexc c0000780<br /> VFP: emulate: INST=0xee377b06 SCR=0x00000000<br /> VFP: bounce: trigger eef1fa10 fpexc c0000780<br /> VFP: emulate: INST=0xeeb40b40 SCR=0x00000000<br /> VFP: raising exceptions 30000000<br /> <br /> calvin@raspberry-pi-zero-w ~$ ./vfp-reproducer<br /> nan<br /> <br /> Crudely grepping for vmsr/vmrs instructions in the otherwise nearly<br /> idential text for vfp_support_entry() makes the problem obvious:<br /> <br /> vmlinux.llvm.good [0xc0101cb8] : vmrs r7, fpexc<br /> vmlinux.llvm.good [0xc0101cd8] : vmsr fpexc, r0<br /> vmlinux.llvm.good [0xc0101d20<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: wilc1000: fix potential RCU dereference issue in wilc_parse_join_bss_param<br /> <br /> In the `wilc_parse_join_bss_param` function, the TSF field of the `ies`<br /> structure is accessed after the RCU read-side critical section is<br /> unlocked. According to RCU usage rules, this is illegal. Reusing this<br /> pointer can lead to unpredictable behavior, including accessing memory<br /> that has been updated or causing use-after-free issues.<br /> <br /> This possible bug was identified using a static analysis tool developed<br /> by myself, specifically designed to detect RCU-related issues.<br /> <br /> To address this, the TSF value is now stored in a local variable<br /> `ies_tsf` before the RCU lock is released. The `param-&gt;tsf_lo` field is<br /> then assigned using this local variable, ensuring that the TSF value is<br /> safely accessed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block: fix potential invalid pointer dereference in blk_add_partition<br /> <br /> The blk_add_partition() function initially used a single if-condition<br /> (IS_ERR(part)) to check for errors when adding a partition. This was<br /> modified to handle the specific case of -ENXIO separately, allowing the<br /> function to proceed without logging the error in this case. However,<br /> this change unintentionally left a path where md_autodetect_dev()<br /> could be called without confirming that part is a valid pointer.<br /> <br /> This commit separates the error handling logic by splitting the<br /> initial if-condition, improving code readability and handling specific<br /> error scenarios explicitly. The function now distinguishes the general<br /> error case from -ENXIO without altering the existing behavior of<br /> md_autodetect_dev() calls.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> block, bfq: fix possible UAF for bfqq-&gt;bic with merge chain<br /> <br /> 1) initial state, three tasks:<br /> <br /> Process 1 Process 2 Process 3<br /> (BIC1) (BIC2) (BIC3)<br /> | Λ | Λ | Λ<br /> | | | | | |<br /> V | V | V |<br /> bfqq1 bfqq2 bfqq3<br /> process ref: 1 1 1<br /> <br /> 2) bfqq1 merged to bfqq2:<br /> <br /> Process 1 Process 2 Process 3<br /> (BIC1) (BIC2) (BIC3)<br /> | | | Λ<br /> \--------------\| | |<br /> V V |<br /> bfqq1---------&gt;bfqq2 bfqq3<br /> process ref: 0 2 1<br /> <br /> 3) bfqq2 merged to bfqq3:<br /> <br /> Process 1 Process 2 Process 3<br /> (BIC1) (BIC2) (BIC3)<br /> here -&gt; Λ | |<br /> \--------------\ \-------------\|<br /> V V<br /> bfqq1---------&gt;bfqq2----------&gt;bfqq3<br /> process ref: 0 1 3<br /> <br /> In this case, IO from Process 1 will get bfqq2 from BIC1 first, and then<br /> get bfqq3 through merge chain, and finially handle IO by bfqq3.<br /> Howerver, current code will think bfqq2 is owned by BIC1, like initial<br /> state, and set bfqq2-&gt;bic to BIC1.<br /> <br /> bfq_insert_request<br /> -&gt; by Process 1<br /> bfqq = bfq_init_rq(rq)<br /> bfqq = bfq_get_bfqq_handle_split<br /> bfqq = bic_to_bfqq<br /> -&gt; get bfqq2 from BIC1<br /> bfqq-&gt;ref++<br /> rq-&gt;elv.priv[0] = bic<br /> rq-&gt;elv.priv[1] = bfqq<br /> if (bfqq_process_refs(bfqq) == 1)<br /> bfqq-&gt;bic = bic<br /> -&gt; record BIC1 to bfqq2<br /> <br /> __bfq_insert_request<br /> new_bfqq = bfq_setup_cooperator<br /> -&gt; get bfqq3 from bfqq2-&gt;new_bfqq<br /> bfqq_request_freed(bfqq)<br /> new_bfqq-&gt;ref++<br /> rq-&gt;elv.priv[1] = new_bfqq<br /> -&gt; handle IO by bfqq3<br /> <br /> Fix the problem by checking bfqq is from merge chain fist. And this<br /> might fix a following problem reported by our syzkaller(unreproducible):<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]<br /> BUG: KASAN: slab-use-after-free in bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]<br /> BUG: KASAN: slab-use-after-free in bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889<br /> Write of size 1 at addr ffff888123839eb8 by task kworker/0:1H/18595<br /> <br /> CPU: 0 PID: 18595 Comm: kworker/0:1H Tainted: G L 6.6.0-07439-gba2303cacfda #6<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> Workqueue: kblockd blk_mq_requeue_work<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:88 [inline]<br /> dump_stack_lvl+0x91/0xf0 lib/dump_stack.c:106<br /> print_address_description mm/kasan/report.c:364 [inline]<br /> print_report+0x10d/0x610 mm/kasan/report.c:475<br /> kasan_report+0x8e/0xc0 mm/kasan/report.c:588<br /> bfq_do_early_stable_merge block/bfq-iosched.c:5692 [inline]<br /> bfq_do_or_sched_stable_merge block/bfq-iosched.c:5805 [inline]<br /> bfq_get_queue+0x25b0/0x2610 block/bfq-iosched.c:5889<br /> bfq_get_bfqq_handle_split+0x169/0x5d0 block/bfq-iosched.c:6757<br /> bfq_init_rq block/bfq-iosched.c:6876 [inline]<br /> bfq_insert_request block/bfq-iosched.c:6254 [inline]<br /> bfq_insert_requests+0x1112/0x5cf0 block/bfq-iosched.c:6304<br /> blk_mq_insert_request+0x290/0x8d0 block/blk-mq.c:2593<br /> blk_mq_requeue_work+0x6bc/0xa70 block/blk-mq.c:1502<br /> process_one_work kernel/workqueue.c:2627 [inline]<br /> process_scheduled_works+0x432/0x13f0 kernel/workqueue.c:2700<br /> worker_thread+0x6f2/0x1160 kernel/workqueue.c:2781<br /> kthread+0x33c/0x440 kernel/kthread.c:388<br /> ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1b/0x30 arch/x86/entry/entry_64.S:305<br /> <br /> <br /> Allocated by task 20776:<br /> kasan_save_stack+0x20/0x40 mm/kasan/common.c:45<br /> kasan_set_track+0x25/0x30 mm/kasan/common.c:52<br /> __kasan_slab_alloc+0x87/0x90 mm/kasan/common.c:328<br /> kasan_slab_alloc include/linux/kasan.h:188 [inline]<br /> slab_post_alloc_hook mm/slab.h:763 [inline]<br /> slab_alloc_node mm/slub.c:3458 [inline]<br /> kmem_cache_alloc_node+0x1a4/0x6f0 mm/slub.c:3503<br /> ioc_create_icq block/blk-ioc.c:370 [inline]<br /> ---truncated---