Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Fix deadlock in tc route query code<br /> <br /> Cited commit causes ABBA deadlock[0] when peer flows are created while<br /> holding the devcom rw semaphore. Due to peer flows offload implementation<br /> the lock is taken much higher up the call chain and there is no obvious way<br /> to easily fix the deadlock. Instead, since tc route query code needs the<br /> peer eswitch structure only to perform a lookup in xarray and doesn&amp;#39;t<br /> perform any sleeping operations with it, refactor the code for lockless<br /> execution in following ways:<br /> <br /> - RCUify the devcom &amp;#39;data&amp;#39; pointer. When resetting the pointer<br /> synchronously wait for RCU grace period before returning. This is fine<br /> since devcom is currently only used for synchronization of<br /> pairing/unpairing of eswitches which is rare and already expensive as-is.<br /> <br /> - Wrap all usages of &amp;#39;paired&amp;#39; boolean in {READ|WRITE}_ONCE(). The flag has<br /> already been used in some unlocked contexts without proper<br /> annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn&amp;#39;t<br /> an issue since all relevant code paths checked it again after obtaining the<br /> devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as<br /> "best effort" check to return NULL when devcom is being unpaired. Note that<br /> while RCU read lock doesn&amp;#39;t prevent the unpaired flag from being changed<br /> concurrently it still guarantees that reader can continue to use &amp;#39;data&amp;#39;.<br /> <br /> - Refactor mlx5e_tc_query_route_vport() function to use new<br /> mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock.<br /> <br /> [0]:<br /> <br /> [ 164.599612] ======================================================<br /> [ 164.600142] WARNING: possible circular locking dependency detected<br /> [ 164.600667] 6.3.0-rc3+ #1 Not tainted<br /> [ 164.601021] ------------------------------------------------------<br /> [ 164.601557] handler1/3456 is trying to acquire lock:<br /> [ 164.601998] ffff88811f1714b0 (&amp;esw-&gt;offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]<br /> [ 164.603078]<br /> but task is already holding lock:<br /> [ 164.603617] ffff88810137fc98 (&amp;comp-&gt;sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]<br /> [ 164.604459]<br /> which lock already depends on the new lock.<br /> <br /> [ 164.605190]<br /> the existing dependency chain (in reverse order) is:<br /> [ 164.605848]<br /> -&gt; #1 (&amp;comp-&gt;sem){++++}-{3:3}:<br /> [ 164.606380] down_read+0x39/0x50<br /> [ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core]<br /> [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core]<br /> [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core]<br /> [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core]<br /> [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core]<br /> [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core]<br /> [ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core]<br /> [ 164.610741] tc_setup_cb_add+0xd4/0x200<br /> [ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower]<br /> [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower]<br /> [ 164.612116] tc_new_tfilter+0x3fc/0xd20<br /> [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0<br /> [ 164.612936] netlink_rcv_skb+0x54/0x100<br /> [ 164.613339] netlink_unicast+0x190/0x250<br /> [ 164.613746] netlink_sendmsg+0x245/0x4a0<br /> [ 164.614150] sock_sendmsg+0x38/0x60<br /> [ 164.614522] ____sys_sendmsg+0x1d0/0x1e0<br /> [ 164.614934] ___sys_sendmsg+0x80/0xc0<br /> [ 164.615320] __sys_sendmsg+0x51/0x90<br /> [ 164.615701] do_syscall_64+0x3d/0x90<br /> [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> [ 164.616568]<br /> -&gt; #0 (&amp;esw-&gt;offloads.encap_tbl_lock){+.+.}-{3:3}:<br /> [ 164.617210] __lock_acquire+0x159e/0x26e0<br /> [ 164.617638] lock_acquire+0xc2/0x2a0<br /> [ 164.618018] __mutex_lock+0x92/0xcd0<br /> [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core]<br /> [ 164.618943] post_process_attr+0x153/0x2d0 [<br /> ---truncated---

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop<br /> <br /> With this refcnt added in sctp_stream_priorities, we don&amp;#39;t need to<br /> traverse all streams to check if the prio is used by other streams<br /> when freeing one stream&amp;#39;s prio in sctp_sched_prio_free_sid(). This<br /> can avoid a nested loop (up to 65535 * 65535), which may cause a<br /> stuck as Ying reported:<br /> <br /> watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136]<br /> Call Trace:<br /> <br /> sctp_sched_prio_free_sid+0xab/0x100 [sctp]<br /> sctp_stream_free_ext+0x64/0xa0 [sctp]<br /> sctp_stream_free+0x31/0x50 [sctp]<br /> sctp_association_free+0xa5/0x200 [sctp]<br /> <br /> Note that it doesn&amp;#39;t need to use refcount_t type for this counter,<br /> as its accessing is always protected under the sock lock.<br /> <br /> v1-&gt;v2:<br /> - add a check in sctp_sched_prio_set to avoid the possible prio_head<br /> refcnt overflow.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: don&amp;#39;t trust firmware n_channels<br /> <br /> If the firmware sends us a corrupted MCC response with<br /> n_channels much larger than the command response can be,<br /> we might copy far too much (uninitialized) memory and<br /> even crash if the n_channels is large enough to make it<br /> run out of the one page allocated for the FW response.<br /> <br /> Fix that by checking the lengths. Doing a

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: mac80211: check for station first in client probe<br /> <br /> When probing a client, first check if we have it, and then<br /> check for the channel context, otherwise you can trigger<br /> the warning there easily by probing when the AP isn&amp;#39;t even<br /> started yet. Since a client existing means the AP is also<br /> operating, we can then keep the warning.<br /> <br /> Also simplify the moved code a bit.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ring-buffer: Sync IRQ works before buffer destruction<br /> <br /> If something was written to the buffer just before destruction,<br /> it may be possible (maybe not in a real system, but it did<br /> happen in ARCH=um with time-travel) to destroy the ringbuffer<br /> before the IRQ work ran, leading this KASAN report (or a crash<br /> without KASAN):<br /> <br /> BUG: KASAN: slab-use-after-free in irq_work_run_list+0x11a/0x13a<br /> Read of size 8 at addr 000000006d640a48 by task swapper/0<br /> <br /> CPU: 0 PID: 0 Comm: swapper Tainted: G W O 6.3.0-rc1 #7<br /> Stack:<br /> 60c4f20f 0c203d48 41b58ab3 60f224fc<br /> 600477fa 60f35687 60c4f20f 601273dd<br /> 00000008 6101eb00 6101eab0 615be548<br /> Call Trace:<br /> [] show_stack+0x25e/0x282<br /> [] dump_stack_lvl+0x96/0xfd<br /> [] print_report+0x1a7/0x5a8<br /> [] kasan_report+0xc1/0xe9<br /> [] __asan_report_load8_noabort+0x1b/0x1d<br /> [] irq_work_run_list+0x11a/0x13a<br /> [] irq_work_tick+0x24/0x34<br /> [] update_process_times+0x162/0x196<br /> [] tick_sched_handle+0x1a4/0x1c3<br /> [] tick_sched_timer+0x79/0x10c<br /> [] __hrtimer_run_queues.constprop.0+0x425/0x695<br /> [] hrtimer_interrupt+0x16c/0x2c4<br /> [] um_timer+0x164/0x183<br /> [...]<br /> <br /> Allocated by task 411:<br /> save_stack_trace+0x99/0xb5<br /> stack_trace_save+0x81/0x9b<br /> kasan_save_stack+0x2d/0x54<br /> kasan_set_track+0x34/0x3e<br /> kasan_save_alloc_info+0x25/0x28<br /> ____kasan_kmalloc+0x8b/0x97<br /> __kasan_kmalloc+0x10/0x12<br /> __kmalloc+0xb2/0xe8<br /> load_elf_phdrs+0xee/0x182<br /> [...]<br /> <br /> The buggy address belongs to the object at 000000006d640800<br /> which belongs to the cache kmalloc-1k of size 1024<br /> The buggy address is located 584 bytes inside of<br /> freed 1024-byte region [000000006d640800, 000000006d640c00)<br /> <br /> Add the appropriate irq_work_sync() so the work finishes before<br /> the buffers are destroyed.<br /> <br /> Prior to the commit in the Fixes tag below, there was only a<br /> single global IRQ work, so this issue didn&amp;#39;t exist.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bpf: reject unhashed sockets in bpf_sk_assign<br /> <br /> The semantics for bpf_sk_assign are as follows:<br /> <br /> sk = some_lookup_func()<br /> bpf_sk_assign(skb, sk)<br /> bpf_sk_release(sk)<br /> <br /> That is, the sk is not consumed by bpf_sk_assign. The function<br /> therefore needs to make sure that sk lives long enough to be<br /> consumed from __inet_lookup_skb. The path through the stack for a<br /> TCPv4 packet is roughly:<br /> <br /> netif_receive_skb_core: takes RCU read lock<br /> __netif_receive_skb_core:<br /> sch_handle_ingress:<br /> tcf_classify:<br /> bpf_sk_assign()<br /> deliver_ptype_list_skb:<br /> deliver_skb:<br /> ip_packet_type-&gt;func == ip_rcv:<br /> ip_rcv_core:<br /> ip_rcv_finish_core:<br /> dst_input:<br /> ip_local_deliver:<br /> ip_local_deliver_finish:<br /> ip_protocol_deliver_rcu:<br /> tcp_v4_rcv:<br /> __inet_lookup_skb:<br /> skb_steal_sock<br /> <br /> The existing helper takes advantage of the fact that everything<br /> happens in the same RCU critical section: for sockets with<br /> SOCK_RCU_FREE set bpf_sk_assign never takes a reference.<br /> skb_steal_sock then checks SOCK_RCU_FREE again and does sock_put<br /> if necessary.<br /> <br /> This approach assumes that SOCK_RCU_FREE is never set on a sk<br /> between bpf_sk_assign and skb_steal_sock, but this invariant is<br /> violated by unhashed UDP sockets. A new UDP socket is created<br /> in TCP_CLOSE state but without SOCK_RCU_FREE set. That flag is only<br /> added in udp_lib_get_port() which happens when a socket is bound.<br /> <br /> When bpf_sk_assign was added it wasn&amp;#39;t possible to access unhashed<br /> UDP sockets from BPF, so this wasn&amp;#39;t a problem. This changed<br /> in commit 0c48eefae712 ("sock_map: Lift socket state restriction<br /> for datagram sockets"), but the helper wasn&amp;#39;t adjusted accordingly.<br /> The following sequence of events will therefore lead to a refcount<br /> leak:<br /> <br /> 1. Add socket(AF_INET, SOCK_DGRAM) to a sockmap.<br /> 2. Pull socket out of sockmap and bpf_sk_assign it. Since<br /> SOCK_RCU_FREE is not set we increment the refcount.<br /> 3. bind() or connect() the socket, setting SOCK_RCU_FREE.<br /> 4. skb_steal_sock will now set refcounted = false due to<br /> SOCK_RCU_FREE.<br /> 5. tcp_v4_rcv() skips sock_put().<br /> <br /> Fix the problem by rejecting unhashed sockets in bpf_sk_assign().<br /> This matches the behaviour of __inet_lookup_skb which is ultimately<br /> the goal of bpf_sk_assign().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: ubifs_releasepage: Remove ubifs_assert(0) to valid this process<br /> <br /> There are two states for ubifs writing pages:<br /> 1. Dirty, Private<br /> 2. Not Dirty, Not Private<br /> <br /> The normal process cannot go to ubifs_releasepage() which means there<br /> exists pages being private but not dirty. Reproducer[1] shows that it<br /> could occur (which maybe related to [2]) with following process:<br /> <br /> PA PB PC<br /> lock(page)[PA]<br /> ubifs_write_end<br /> attach_page_private // set Private<br /> __set_page_dirty_nobuffers // set Dirty<br /> unlock(page)<br /> <br /> write_cache_pages[PA]<br /> lock(page)<br /> clear_page_dirty_for_io(page) // clear Dirty<br /> ubifs_writepage<br /> <br /> do_truncation[PB]<br /> truncate_setsize<br /> i_size_write(inode, newsize) // newsize = 0<br /> <br /> i_size = i_size_read(inode) // i_size = 0<br /> end_index = i_size &gt;&gt; PAGE_SHIFT<br /> if (page-&gt;index &gt; end_index)<br /> goto out // jump<br /> out:<br /> unlock(page) // Private, Not Dirty<br /> <br /> generic_fadvise[PC]<br /> lock(page)<br /> invalidate_inode_page<br /> try_to_release_page<br /> ubifs_releasepage<br /> ubifs_assert(c, 0)<br /> // bad assertion!<br /> unlock(page)<br /> truncate_pagecache[PB]<br /> <br /> Then we may get following assertion failed:<br /> UBIFS error (ubi0:0 pid 1683): ubifs_assert_failed [ubifs]:<br /> UBIFS assert failed: 0, in fs/ubifs/file.c:1513<br /> UBIFS warning (ubi0:0 pid 1683): ubifs_ro_mode [ubifs]:<br /> switched to read-only mode, error -22<br /> CPU: 2 PID: 1683 Comm: aa Not tainted 5.16.0-rc5-00184-g0bca5994cacc-dirty #308<br /> Call Trace:<br /> dump_stack+0x13/0x1b<br /> ubifs_ro_mode+0x54/0x60 [ubifs]<br /> ubifs_assert_failed+0x4b/0x80 [ubifs]<br /> ubifs_releasepage+0x67/0x1d0 [ubifs]<br /> try_to_release_page+0x57/0xe0<br /> invalidate_inode_page+0xfb/0x130<br /> __invalidate_mapping_pages+0xb9/0x280<br /> invalidate_mapping_pagevec+0x12/0x20<br /> generic_fadvise+0x303/0x3c0<br /> ksys_fadvise64_64+0x4c/0xb0<br /> <br /> [1] https://bugzilla.kernel.org/show_bug.cgi?id=215373<br /> [2] https://linux-mtd.infradead.narkive.com/NQoBeT1u/patch-rfc-ubifs-fix-assert-failed-in-ubifs-set-page-dirty

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf: RISC-V: Remove PERF_HES_STOPPED flag checking in riscv_pmu_start()<br /> <br /> Since commit 096b52fd2bb4 ("perf: RISC-V: throttle perf events") the<br /> perf_sample_event_took() function was added to report time spent in<br /> overflow interrupts. If the interrupt takes too long, the perf framework<br /> will lower the sysctl_perf_event_sample_rate and max_samples_per_tick.<br /> When hwc-&gt;interrupts is larger than max_samples_per_tick, the<br /> hwc-&gt;interrupts will be set to MAX_INTERRUPTS, and events will be<br /> throttled within the __perf_event_account_interrupt() function.<br /> <br /> However, the RISC-V PMU driver doesn&amp;#39;t call riscv_pmu_stop() to update the<br /> PERF_HES_STOPPED flag after perf_event_overflow() in pmu_sbi_ovf_handler()<br /> function to avoid throttling. When the perf framework unthrottled the event<br /> in the timer interrupt handler, it triggers riscv_pmu_start() function<br /> and causes a WARN_ON_ONCE() warning, as shown below:<br /> <br /> ------------[ cut here ]------------<br /> WARNING: CPU: 0 PID: 240 at drivers/perf/riscv_pmu.c:184 riscv_pmu_start+0x7c/0x8e<br /> Modules linked in:<br /> CPU: 0 PID: 240 Comm: ls Not tainted 6.4-rc4-g19d0788e9ef2 #1<br /> Hardware name: SiFive (DT)<br /> epc : riscv_pmu_start+0x7c/0x8e<br /> ra : riscv_pmu_start+0x28/0x8e<br /> epc : ffffffff80aef864 ra : ffffffff80aef810 sp : ffff8f80004db6f0<br /> gp : ffffffff81c83750 tp : ffffaf80069f9bc0 t0 : ffff8f80004db6c0<br /> t1 : 0000000000000000 t2 : 000000000000001f s0 : ffff8f80004db720<br /> s1 : ffffaf8008ca1068 a0 : 0000ffffffffffff a1 : 0000000000000000<br /> a2 : 0000000000000001 a3 : 0000000000000870 a4 : 0000000000000000<br /> a5 : 0000000000000000 a6 : 0000000000000840 a7 : 0000000000000030<br /> s2 : 0000000000000000 s3 : ffffaf8005165800 s4 : ffffaf800424da00<br /> s5 : ffffffffffffffff s6 : ffffffff81cc7590 s7 : 0000000000000000<br /> s8 : 0000000000000006 s9 : 0000000000000001 s10: ffffaf807efbc340<br /> s11: ffffaf807efbbf00 t3 : ffffaf8006a16028 t4 : 00000000dbfbb796<br /> t5 : 0000000700000000 t6 : ffffaf8005269870<br /> status: 0000000200000100 badaddr: 0000000000000000 cause: 0000000000000003<br /> [] riscv_pmu_start+0x7c/0x8e<br /> [] perf_adjust_freq_unthr_context+0x15e/0x174<br /> [] perf_event_task_tick+0x88/0x9c<br /> [] scheduler_tick+0xfe/0x27c<br /> [] update_process_times+0x9a/0xba<br /> [] tick_sched_handle+0x32/0x66<br /> [] tick_sched_timer+0x64/0xb0<br /> [] __hrtimer_run_queues+0x156/0x2f4<br /> [] hrtimer_interrupt+0xe2/0x1fe<br /> [] riscv_timer_interrupt+0x38/0x42<br /> [] handle_percpu_devid_irq+0x90/0x1d2<br /> [] generic_handle_domain_irq+0x28/0x36<br /> <br /> After referring other PMU drivers like Arm, Loongarch, Csky, and Mips,<br /> they don&amp;#39;t call *_pmu_stop() to update with PERF_HES_STOPPED flag<br /> after perf_event_overflow() function nor do they add PERF_HES_STOPPED<br /> flag checking in *_pmu_start() which don&amp;#39;t cause this warning.<br /> <br /> Thus, it&amp;#39;s recommended to remove this unnecessary check in<br /> riscv_pmu_start() function to prevent this warning.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: target: Fix multiple LUN_RESET handling<br /> <br /> This fixes a bug where an initiator thinks a LUN_RESET has cleaned up<br /> running commands when it hasn&amp;#39;t. The bug was added in commit 51ec502a3266<br /> ("target: Delete tmr from list before processing").<br /> <br /> The problem occurs when:<br /> <br /> 1. We have N I/O cmds running in the target layer spread over 2 sessions.<br /> <br /> 2. The initiator sends a LUN_RESET for each session.<br /> <br /> 3. session1&amp;#39;s LUN_RESET loops over all the running commands from both<br /> sessions and moves them to its local drain_task_list.<br /> <br /> 4. session2&amp;#39;s LUN_RESET does not see the LUN_RESET from session1 because<br /> the commit above has it remove itself. session2 also does not see any<br /> commands since the other reset moved them off the state lists.<br /> <br /> 5. sessions2&amp;#39;s LUN_RESET will then complete with a successful response.<br /> <br /> 6. sessions2&amp;#39;s inititor believes the running commands on its session are<br /> now cleaned up due to the successful response and cleans up the running<br /> commands from its side. It then restarts them.<br /> <br /> 7. The commands do eventually complete on the backend and the target<br /> starts to return aborted task statuses for them. The initiator will<br /> either throw a invalid ITT error or might accidentally lookup a new<br /> task if the ITT has been reallocated already.<br /> <br /> Fix the bug by reverting the patch, and serialize the execution of<br /> LUN_RESETs and Preempt and Aborts.<br /> <br /> Also prevent us from waiting on LUN_RESETs in core_tmr_drain_tmr_list,<br /> because it turns out the original patch fixed a bug that was not<br /> mentioned. For LUN_RESET1 core_tmr_drain_tmr_list can see a second<br /> LUN_RESET and wait on it. Then the second reset will run<br /> core_tmr_drain_tmr_list and see the first reset and wait on it resulting in<br /> a deadlock.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw88: delete timer and free skb queue when unloading<br /> <br /> Fix possible crash and memory leak on driver unload by deleting<br /> TX purge timer and freeing C2H queue in &amp;#39;rtw_core_deinit()&amp;#39;,<br /> shrink critical section in the latter by freeing COEX queue<br /> out of TX report lock scope.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: iwlwifi: mvm: fix potential array out of bounds access<br /> <br /> Account for IWL_SEC_WEP_KEY_OFFSET when needed while verifying<br /> key_len size in iwl_mvm_sec_key_add().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> null_blk: Always check queue mode setting from configfs<br /> <br /> Make sure to check device queue mode in the null_validate_conf() and<br /> return error for NULL_Q_RQ as we don&amp;#39;t allow legacy I/O path, without<br /> this patch we get OOPs when queue mode is set to 1 from configfs,<br /> following are repro steps :-<br /> <br /> modprobe null_blk nr_devices=0<br /> mkdir config/nullb/nullb0<br /> echo 1 &gt; config/nullb/nullb0/memory_backed<br /> echo 4096 &gt; config/nullb/nullb0/blocksize<br /> echo 20480 &gt; config/nullb/nullb0/size<br /> echo 1 &gt; config/nullb/nullb0/queue_mode<br /> echo 1 &gt; config/nullb/nullb0/power<br /> <br /> Entering kdb (current=0xffff88810acdd080, pid 2372) on processor 42 Oops: (null)<br /> due to oops @ 0xffffffffc041c329<br /> CPU: 42 PID: 2372 Comm: sh Tainted: G O N 6.3.0-rc5lblk+ #5<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014<br /> RIP: 0010:null_add_dev.part.0+0xd9/0x720 [null_blk]<br /> Code: 01 00 00 85 d2 0f 85 a1 03 00 00 48 83 bb 08 01 00 00 00 0f 85 f7 03 00 00 80 bb 62 01 00 00 00 48 8b 75 20 0f 85 6d 02 00 00 89 6e 60 48 8b 75 20 bf 06 00 00 00 e8 f5 37 2c c1 48 8b 75 20<br /> RSP: 0018:ffffc900052cbde0 EFLAGS: 00010246<br /> RAX: 0000000000000001 RBX: ffff88811084d800 RCX: 0000000000000001<br /> RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888100042e00<br /> RBP: ffff8881053d8200 R08: ffffc900052cbd68 R09: ffff888105db2000<br /> R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000002<br /> R13: ffff888104765200 R14: ffff88810eec1748 R15: ffff88810eec1740<br /> FS: 00007fd445fd1740(0000) GS:ffff8897dfc80000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 0000000000000060 CR3: 0000000166a00000 CR4: 0000000000350ee0<br /> DR0: ffffffff8437a488 DR1: ffffffff8437a489 DR2: ffffffff8437a48a<br /> DR3: ffffffff8437a48b DR6: 00000000ffff0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> nullb_device_power_store+0xd1/0x120 [null_blk]<br /> configfs_write_iter+0xb4/0x120<br /> vfs_write+0x2ba/0x3c0<br /> ksys_write+0x5f/0xe0<br /> do_syscall_64+0x3b/0x90<br /> entry_SYSCALL_64_after_hwframe+0x72/0xdc<br /> RIP: 0033:0x7fd4460c57a7<br /> Code: 0d 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 3d 00 f0 ff ff 77 51 c3 48 83 ec 28 48 89 54 24 18 48 89 74 24<br /> RSP: 002b:00007ffd3792a4a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001<br /> RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007fd4460c57a7<br /> RDX: 0000000000000002 RSI: 000055b43c02e4c0 RDI: 0000000000000001<br /> RBP: 000055b43c02e4c0 R08: 000000000000000a R09: 00007fd44615b4e0<br /> R10: 00007fd44615b3e0 R11: 0000000000000246 R12: 0000000000000002<br /> R13: 00007fd446198520 R14: 0000000000000002 R15: 00007fd446198700<br />