| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
bnxt_en: Fix double invocation of bnxt_ulp_stop()/bnxt_ulp_start()
Before the commit under the Fixes tag below, bnxt_ulp_stop() and
bnxt_ulp_start() were always invoked in pairs. After that commit,
the new bnxt_ulp_restart() can be invoked after bnxt_ulp_stop()
has been called. This may result in the RoCE driver's aux driver
.suspend() method being invoked twice. The 2nd bnxt_re_suspend()
call will crash when it dereferences a NULL pointer:
(NULL ib_device): Handle device suspend call
BUG: kernel NULL pointer dereference, address: 0000000000000b78
PGD 0 P4D 0
Oops: Oops: 0000 [#1] SMP PTI
CPU: 20 UID: 0 PID: 181 Comm: kworker/u96:5 Tainted: G S 6.15.0-rc1 #4 PREEMPT(voluntary)
Tainted: [S]=CPU_OUT_OF_SPEC
Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
Workqueue: bnxt_pf_wq bnxt_sp_task [bnxt_en]
RIP: 0010:bnxt_re_suspend+0x45/0x1f0 [bnxt_re]
Code: 8b 05 a7 3c 5b f5 48 89 44 24 18 31 c0 49 8b 5c 24 08 4d 8b 2c 24 e8 ea 06 0a f4 48 c7 c6 04 60 52 c0 48 89 df e8 1b ce f9 ff <48> 8b 83 78 0b 00 00 48 8b 80 38 03 00 00 a8 40 0f 85 b5 00 00 00
RSP: 0018:ffffa2e84084fd88 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000001
RDX: 0000000000000000 RSI: ffffffffb4b6b934 RDI: 00000000ffffffff
RBP: ffffa1760954c9c0 R08: 0000000000000000 R09: c0000000ffffdfff
R10: 0000000000000001 R11: ffffa2e84084fb50 R12: ffffa176031ef070
R13: ffffa17609775000 R14: ffffa17603adc180 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa17daa397000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000b78 CR3: 00000004aaa30003 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
<TASK>
bnxt_ulp_stop+0x69/0x90 [bnxt_en]
bnxt_sp_task+0x678/0x920 [bnxt_en]
? __schedule+0x514/0xf50
process_scheduled_works+0x9d/0x400
worker_thread+0x11c/0x260
? __pfx_worker_thread+0x10/0x10
kthread+0xfe/0x1e0
? __pfx_kthread+0x10/0x10
ret_from_fork+0x2b/0x40
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
Check the BNXT_EN_FLAG_ULP_STOPPED flag and do not proceed if the flag
is already set. This will preserve the original symmetrical
bnxt_ulp_stop() and bnxt_ulp_start().
Also, inside bnxt_ulp_start(), clear the BNXT_EN_FLAG_ULP_STOPPED
flag after taking the mutex to avoid any race condition. And for
symmetry, only proceed in bnxt_ulp_start() if the
BNXT_EN_FLAG_ULP_STOPPED is set. |
| In the Linux kernel, the following vulnerability has been resolved:
mm/damon/sysfs-schemes: free old damon_sysfs_scheme_filter->memcg_path on write
memcg_path_store() assigns a newly allocated memory buffer to
filter->memcg_path, without deallocating the previously allocated and
assigned memory buffer. As a result, users can leak kernel memory by
continuously writing a data to memcg_path DAMOS sysfs file. Fix the leak
by deallocating the previously set memory buffer. |
| In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix a use-after-free in r535_gsp_rpc_push()
The RPC container is released after being passed to r535_gsp_rpc_send().
When sending the initial fragment of a large RPC and passing the
caller's RPC container, the container will be freed prematurely. Subsequent
attempts to send remaining fragments will therefore result in a
use-after-free.
Allocate a temporary RPC container for holding the initial fragment of a
large RPC when sending. Free the caller's container when all fragments
are successfully sent.
[ Rebase onto Blackwell changes. - Danilo ] |
| In the Linux kernel, the following vulnerability has been resolved:
drm/msm/a7xx: Call CP_RESET_CONTEXT_STATE
Calling this packet is necessary when we switch contexts because there
are various pieces of state used by userspace to synchronize between BR
and BV that are persistent across submits and we need to make sure that
they are in a "safe" state when switching contexts. Otherwise a
userspace submission in one context could cause another context to
function incorrectly and hang, effectively a denial of service (although
without leaking data). This was missed during initial a7xx bringup.
Patchwork: https://patchwork.freedesktop.org/patch/654924/ |
| In the Linux kernel, the following vulnerability has been resolved:
net: clear the dst when changing skb protocol
A not-so-careful NAT46 BPF program can crash the kernel
if it indiscriminately flips ingress packets from v4 to v6:
BUG: kernel NULL pointer dereference, address: 0000000000000000
ip6_rcv_core (net/ipv6/ip6_input.c:190:20)
ipv6_rcv (net/ipv6/ip6_input.c:306:8)
process_backlog (net/core/dev.c:6186:4)
napi_poll (net/core/dev.c:6906:9)
net_rx_action (net/core/dev.c:7028:13)
do_softirq (kernel/softirq.c:462:3)
netif_rx (net/core/dev.c:5326:3)
dev_loopback_xmit (net/core/dev.c:4015:2)
ip_mc_finish_output (net/ipv4/ip_output.c:363:8)
NF_HOOK (./include/linux/netfilter.h:314:9)
ip_mc_output (net/ipv4/ip_output.c:400:5)
dst_output (./include/net/dst.h:459:9)
ip_local_out (net/ipv4/ip_output.c:130:9)
ip_send_skb (net/ipv4/ip_output.c:1496:8)
udp_send_skb (net/ipv4/udp.c:1040:8)
udp_sendmsg (net/ipv4/udp.c:1328:10)
The output interface has a 4->6 program attached at ingress.
We try to loop the multicast skb back to the sending socket.
Ingress BPF runs as part of netif_rx(), pushes a valid v6 hdr
and changes skb->protocol to v6. We enter ip6_rcv_core which
tries to use skb_dst(). But the dst is still an IPv4 one left
after IPv4 mcast output.
Clear the dst in all BPF helpers which change the protocol.
Try to preserve metadata dsts, those may carry non-routing
metadata. |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Fix panic caused by NULL-PMD in huge_pte_offset()
ERROR INFO:
CPU 25 Unable to handle kernel paging request at virtual address 0x0
...
Call Trace:
[<900000000023c30c>] huge_pte_offset+0x3c/0x58
[<900000000057fd4c>] hugetlb_follow_page_mask+0x74/0x438
[<900000000051fee8>] __get_user_pages+0xe0/0x4c8
[<9000000000522414>] faultin_page_range+0x84/0x380
[<9000000000564e8c>] madvise_vma_behavior+0x534/0xa48
[<900000000056689c>] do_madvise+0x1bc/0x3e8
[<9000000000566df4>] sys_madvise+0x24/0x38
[<90000000015b9e88>] do_syscall+0x78/0x98
[<9000000000221f18>] handle_syscall+0xb8/0x158
In some cases, pmd may be NULL and rely on NULL as the return value for
processing, so it is necessary to determine this situation here. |
| In the Linux kernel, the following vulnerability has been resolved:
ACPI: platform_profile: Avoid initializing on non-ACPI platforms
The platform profile driver is loaded even on platforms that do not have
ACPI enabled. The initialization of the sysfs entries was recently moved
from platform_profile_register() to the module init call, and those
entries need acpi_kobj to be initialized which is not the case when ACPI
is disabled.
This results in the following warning:
WARNING: CPU: 5 PID: 1 at fs/sysfs/group.c:131 internal_create_group+0xa22/0xdd8
Modules linked in:
CPU: 5 UID: 0 PID: 1 Comm: swapper/0 Tainted: G W 6.15.0-rc7-dirty #6 PREEMPT
Tainted: [W]=WARN
Hardware name: riscv-virtio,qemu (DT)
epc : internal_create_group+0xa22/0xdd8
ra : internal_create_group+0xa22/0xdd8
Call Trace:
internal_create_group+0xa22/0xdd8
sysfs_create_group+0x22/0x2e
platform_profile_init+0x74/0xb2
do_one_initcall+0x198/0xa9e
kernel_init_freeable+0x6d8/0x780
kernel_init+0x28/0x24c
ret_from_fork+0xe/0x18
Fix this by checking if ACPI is enabled before trying to create sysfs
entries.
[ rjw: Subject and changelog edits ] |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix NULL access in assign channel context handler
Currently, when ath12k_mac_assign_vif_to_vdev() fails, the radio handle
(ar) gets accessed from the link VIF handle (arvif) for debug logging, This
is incorrect. In the fail scenario, radio handle is NULL. Fix the NULL
access, avoid radio handle access by moving to the hardware debug logging
helper function (ath12k_hw_warn).
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix invalid access to memory
In ath12k_dp_rx_msdu_coalesce(), rxcb is fetched from skb and boolean
is_continuation is part of rxcb.
Currently, after freeing the skb, the rxcb->is_continuation accessed
again which is wrong since the memory is already freed.
This might lead use-after-free error.
Hence, fix by locally defining bool is_continuation from rxcb,
so that after freeing skb, is_continuation can be used.
Compile tested only. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: Prevent sending WMI commands to firmware during firmware crash
Currently, we encounter the following kernel call trace when a firmware
crash occurs. This happens because the host sends WMI commands to the
firmware while it is in recovery, causing the commands to fail and
resulting in the kernel call trace.
Set the ATH12K_FLAG_CRASH_FLUSH and ATH12K_FLAG_RECOVERY flags when the
host driver receives the firmware crash notification from MHI. This
prevents sending WMI commands to the firmware during recovery.
Call Trace:
<TASK>
dump_stack_lvl+0x75/0xc0
register_lock_class+0x6be/0x7a0
? __lock_acquire+0x644/0x19a0
__lock_acquire+0x95/0x19a0
lock_acquire+0x265/0x310
? ath12k_ce_send+0xa2/0x210 [ath12k]
? find_held_lock+0x34/0xa0
? ath12k_ce_send+0x56/0x210 [ath12k]
_raw_spin_lock_bh+0x33/0x70
? ath12k_ce_send+0xa2/0x210 [ath12k]
ath12k_ce_send+0xa2/0x210 [ath12k]
ath12k_htc_send+0x178/0x390 [ath12k]
ath12k_wmi_cmd_send_nowait+0x76/0xa0 [ath12k]
ath12k_wmi_cmd_send+0x62/0x190 [ath12k]
ath12k_wmi_pdev_bss_chan_info_request+0x62/0xc0 [ath1
ath12k_mac_op_get_survey+0x2be/0x310 [ath12k]
ieee80211_dump_survey+0x99/0x240 [mac80211]
nl80211_dump_survey+0xe7/0x470 [cfg80211]
? kmalloc_reserve+0x59/0xf0
genl_dumpit+0x24/0x70
netlink_dump+0x177/0x360
__netlink_dump_start+0x206/0x280
genl_family_rcv_msg_dumpit.isra.22+0x8a/0xe0
? genl_family_rcv_msg_attrs_parse.isra.23+0xe0/0xe0
? genl_op_lock.part.12+0x10/0x10
? genl_dumpit+0x70/0x70
genl_rcv_msg+0x1d0/0x290
? nl80211_del_station+0x330/0x330 [cfg80211]
? genl_get_cmd_both+0x50/0x50
netlink_rcv_skb+0x4f/0x100
genl_rcv+0x1f/0x30
netlink_unicast+0x1b6/0x260
netlink_sendmsg+0x31a/0x450
__sock_sendmsg+0xa8/0xb0
____sys_sendmsg+0x1e4/0x260
___sys_sendmsg+0x89/0xe0
? local_clock_noinstr+0xb/0xc0
? rcu_is_watching+0xd/0x40
? kfree+0x1de/0x370
? __sys_sendmsg+0x7a/0xc0
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix node corruption in ar->arvifs list
In current WLAN recovery code flow, ath12k_core_halt() only reinitializes
the "arvifs" list head. This will cause the list node immediately following
the list head to become an invalid list node. Because the prev of that node
still points to the list head "arvifs", but the next of the list head
"arvifs" no longer points to that list node.
When a WLAN recovery occurs during the execution of a vif removal, and it
happens before the spin_lock_bh(&ar->data_lock) in
ath12k_mac_vdev_delete(), list_del() will detect the previously mentioned
situation, thereby triggering a kernel panic.
The fix is to remove and reinitialize all vif list nodes from the list head
"arvifs" during WLAN halt. The reinitialization is to make the list nodes
valid, ensuring that the list_del() in ath12k_mac_vdev_delete() can execute
normally.
Call trace:
__list_del_entry_valid_or_report+0xd4/0x100 (P)
ath12k_mac_remove_link_interface.isra.0+0xf8/0x2e4 [ath12k]
ath12k_scan_vdev_clean_work+0x40/0x164 [ath12k]
cfg80211_wiphy_work+0xfc/0x100
process_one_work+0x164/0x2d0
worker_thread+0x254/0x380
kthread+0xfc/0x100
ret_from_fork+0x10/0x20
The change is mostly copied from the ath11k patch:
https://lore.kernel.org/all/20250320053145.3445187-1-quic_stonez@quicinc.com/
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.4.1-00199-QCAHKSWPL_SILICONZ-1 |
| In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Avoid potential ndlp use-after-free in dev_loss_tmo_callbk
Smatch detected a potential use-after-free of an ndlp oject in
dev_loss_tmo_callbk during driver unload or fatal error handling.
Fix by reordering code to avoid potential use-after-free if initial
nodelist reference has been previously removed. |
| In the Linux kernel, the following vulnerability has been resolved:
IB/cm: Drop lockdep assert and WARN when freeing old msg
The send completion handler can run after cm_id has advanced to another
message. The cm_id lock is not needed in this case, but a recent change
re-used cm_free_priv_msg(), which asserts that the lock is held and
WARNs if the cm_id's currently outstanding msg is different than the one
being freed. |
| In the Linux kernel, the following vulnerability has been resolved:
wifi: rtw89: pci: configure manual DAC mode via PCI config API only
To support 36-bit DMA, configure chip proprietary bit via PCI config API
or chip DBI interface. However, the PCI device mmap isn't set yet and
the DBI is also inaccessible via mmap, so only if the bit can be accessible
via PCI config API, chip can support 36-bit DMA. Otherwise, fallback to
32-bit DMA.
With NULL mmap address, kernel throws trace:
BUG: unable to handle page fault for address: 0000000000001090
#PF: supervisor write access in kernel mode
#PF: error_code(0x0002) - not-present page
PGD 0 P4D 0
Oops: Oops: 0002 [#1] PREEMPT SMP PTI
CPU: 1 UID: 0 PID: 71 Comm: irq/26-pciehp Tainted: G OE 6.14.2-061402-generic #202504101348
Tainted: [O]=OOT_MODULE, [E]=UNSIGNED_MODULE
RIP: 0010:rtw89_pci_ops_write16+0x12/0x30 [rtw89_pci]
RSP: 0018:ffffb0ffc0acf9d8 EFLAGS: 00010206
RAX: ffffffffc158f9c0 RBX: ffff94865e702020 RCX: 0000000000000000
RDX: 0000000000000718 RSI: 0000000000001090 RDI: ffff94865e702020
RBP: ffffb0ffc0acf9d8 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000015
R13: 0000000000000719 R14: ffffb0ffc0acfa1f R15: ffffffffc1813060
FS: 0000000000000000(0000) GS:ffff9486f3480000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000001090 CR3: 0000000090440001 CR4: 00000000000626f0
Call Trace:
<TASK>
rtw89_pci_read_config_byte+0x6d/0x120 [rtw89_pci]
rtw89_pci_cfg_dac+0x5b/0xb0 [rtw89_pci]
rtw89_pci_probe+0xa96/0xbd0 [rtw89_pci]
? __pfx___device_attach_driver+0x10/0x10
? __pfx___device_attach_driver+0x10/0x10
local_pci_probe+0x47/0xa0
pci_call_probe+0x5d/0x190
pci_device_probe+0xa7/0x160
really_probe+0xf9/0x370
? pm_runtime_barrier+0x55/0xa0
__driver_probe_device+0x8c/0x140
driver_probe_device+0x24/0xd0
__device_attach_driver+0xcd/0x170
bus_for_each_drv+0x99/0x100
__device_attach+0xb4/0x1d0
device_attach+0x10/0x20
pci_bus_add_device+0x59/0x90
pci_bus_add_devices+0x31/0x80
pciehp_configure_device+0xaa/0x170
pciehp_enable_slot+0xd6/0x240
pciehp_handle_presence_or_link_change+0xf1/0x180
pciehp_ist+0x162/0x1c0
irq_thread_fn+0x24/0x70
irq_thread+0xef/0x1c0
? __pfx_irq_thread_fn+0x10/0x10
? __pfx_irq_thread_dtor+0x10/0x10
? __pfx_irq_thread+0x10/0x10
kthread+0xfc/0x230
? __pfx_kthread+0x10/0x10
ret_from_fork+0x47/0x70
? __pfx_kthread+0x10/0x10
ret_from_fork_asm+0x1a/0x30
</TASK> |
| In the Linux kernel, the following vulnerability has been resolved:
misc: tps6594-pfsm: Add NULL pointer check in tps6594_pfsm_probe()
The returned value, pfsm->miscdev.name, from devm_kasprintf()
could be NULL.
A pointer check is added to prevent potential NULL pointer dereference.
This is similar to the fix in commit 3027e7b15b02
("ice: Fix some null pointer dereference issues in ice_ptp.c").
This issue is found by our static analysis tool. |
| In the Linux kernel, the following vulnerability has been resolved:
LoongArch: KVM: Avoid overflow with array index
The variable index is modified and reused as array index when modify
register EIOINTC_ENABLE. There will be array index overflow problem. |
| In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: eir: Fix possible crashes on eir_create_adv_data
eir_create_adv_data may attempt to add EIR_FLAGS and EIR_TX_POWER
without checking if that would fit. |
| In the Linux kernel, the following vulnerability has been resolved:
block: don't use submit_bio_noacct_nocheck in blk_zone_wplug_bio_work
Bios queued up in the zone write plug have already gone through all all
preparation in the submit_bio path, including the freeze protection.
Submitting them through submit_bio_noacct_nocheck duplicates the work
and can can cause deadlocks when freezing a queue with pending bio
write plugs.
Go straight to ->submit_bio or blk_mq_submit_bio to bypass the
superfluous extra freeze protection and checks. |
| In the Linux kernel, the following vulnerability has been resolved:
nvmem: zynqmp_nvmem: unbreak driver after cleanup
Commit 29be47fcd6a0 ("nvmem: zynqmp_nvmem: zynqmp_nvmem_probe cleanup")
changed the driver to expect the device pointer to be passed as the
"context", but in nvmem the context parameter comes from nvmem_config.priv
which is never set - Leading to null pointer exceptions when the device is
accessed. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: mt8195: Set ETDM1/2 IN/OUT to COMP_DUMMY()
ETDM2_IN_BE and ETDM1_OUT_BE are defined as COMP_EMPTY(),
in the case the codec dai_name will be null.
Avoid a crash if the device tree is not assigning a codec
to these links.
[ 1.179936] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[ 1.181065] Mem abort info:
[ 1.181420] ESR = 0x0000000096000004
[ 1.181892] EC = 0x25: DABT (current EL), IL = 32 bits
[ 1.182576] SET = 0, FnV = 0
[ 1.182964] EA = 0, S1PTW = 0
[ 1.183367] FSC = 0x04: level 0 translation fault
[ 1.183983] Data abort info:
[ 1.184406] ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
[ 1.185097] CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[ 1.185766] GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[ 1.186439] [0000000000000000] user address but active_mm is swapper
[ 1.187239] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
[ 1.188029] Modules linked in:
[ 1.188420] CPU: 7 UID: 0 PID: 70 Comm: kworker/u32:1 Not tainted 6.14.0-rc4-next-20250226+ #85
[ 1.189515] Hardware name: Radxa NIO 12L (DT)
[ 1.190065] Workqueue: events_unbound deferred_probe_work_func
[ 1.190808] pstate: 40400009 (nZcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 1.191683] pc : __pi_strcmp+0x24/0x140
[ 1.192170] lr : mt8195_mt6359_soc_card_probe+0x224/0x7b0
[ 1.192854] sp : ffff800083473970
[ 1.193271] x29: ffff800083473a10 x28: 0000000000001008 x27: 0000000000000002
[ 1.194168] x26: ffff800082408960 x25: ffff800082417db0 x24: ffff800082417d88
[ 1.195065] x23: 000000000000001e x22: ffff800082dbf480 x21: ffff800082dc07b8
[ 1.195961] x20: 0000000000000000 x19: 0000000000000013 x18: 00000000ffffffff
[ 1.196858] x17: 000000040044ffff x16: 005000f2b5503510 x15: 0000000000000006
[ 1.197755] x14: ffff800082407af0 x13: 6e6f69737265766e x12: 692d6b636f6c6374
[ 1.198651] x11: 0000000000000002 x10: ffff80008240b920 x9 : 0000000000000018
[ 1.199547] x8 : 0101010101010101 x7 : 0000000000000000 x6 : 0000000000000000
[ 1.200443] x5 : 0000000000000000 x4 : 8080808080000000 x3 : 303933383978616d
[ 1.201339] x2 : 0000000000000000 x1 : ffff80008240b920 x0 : 0000000000000000
[ 1.202236] Call trace:
[ 1.202545] __pi_strcmp+0x24/0x140 (P)
[ 1.203029] mtk_soundcard_common_probe+0x3bc/0x5b8
[ 1.203644] platform_probe+0x70/0xe8
[ 1.204106] really_probe+0xc8/0x3a0
[ 1.204556] __driver_probe_device+0x84/0x160
[ 1.205104] driver_probe_device+0x44/0x130
[ 1.205630] __device_attach_driver+0xc4/0x170
[ 1.206189] bus_for_each_drv+0x8c/0xf8
[ 1.206672] __device_attach+0xa8/0x1c8
[ 1.207155] device_initial_probe+0x1c/0x30
[ 1.207681] bus_probe_device+0xb0/0xc0
[ 1.208165] deferred_probe_work_func+0xa4/0x100
[ 1.208747] process_one_work+0x158/0x3e0
[ 1.209254] worker_thread+0x2c4/0x3e8
[ 1.209727] kthread+0x134/0x1f0
[ 1.210136] ret_from_fork+0x10/0x20
[ 1.210589] Code: 54000401 b50002c6 d503201f f86a6803 (f8408402)
[ 1.211355] ---[ end trace 0000000000000000 ]--- |
