Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2024-40968 State: PUBLISHED Published: 2024-07-12T12:32:07.476Z Last Updated: 2025-11-03T21:58:33.237Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: MIPS: Octeon: Add PCIe link status check The standard PCIe configuration read-write interface is used to access the configuration space of the peripheral PCIe devices of the mips processor after the PCIe link surprise down, it can generate kernel panic caused by "Data bus error". So it is necessary to add PCIe link status check for system protection. When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write be
When the PCIe link is down or in training, assigning a value of 0 to the configuration address can prevent read-write behavior to the configuration space of peripheral PCIe devices, thereby preventing kernel panic. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/6bff05aaa32c2f7e1f6e68e890876642159db419 - https://git.kernel.org/stable/c/64845ac64819683ad5e51b668b2ed56ee3386aee - https://git.kernel.org/stable/c/6c1b9fe148a4e03bbfa234267ebb89f35285814a - https://git.kernel.org/stable/c/25998f5613159fe35920dbd484fcac7ea3ad0799 - https://git.kernel.org/stable/c/d996deb80398a90dd3c03590e68dad543da87d62 - https://git.kernel.o
20dbd484fcac7ea3ad0799 - https://git.kernel.org/stable/c/d996deb80398a90dd3c03590e68dad543da87d62 - https://git.kernel.org/stable/c/1c33fd17383f48f679186c54df78542106deeaa0 - https://git.kernel.org/stable/c/38d647d509543e9434b3cc470b914348be271fe9 - https://git.kernel.org/stable/c/29b83a64df3b42c88c0338696feb6fdcd7f1f3b7
CVE ID: CVE-2024-40969 State: PUBLISHED Published: 2024-07-12T12:32:08.139Z Last Updated: 2025-07-11T17:19:51.498Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: don't set RO when shutting down f2fs Shutdown does not check the error of thaw_super due to readonly, which causes a deadlock like below. f2fs_ioc_shutdown(F2FS_GOING_DOWN_FULLSYNC) issue_discard_thread - bdev_freeze - freeze_super - f2fs_stop_checkpoint() - f2fs_handle_critical_error - sb_start_write - set RO - waiting - bdev_thaw - thaw_super_locked - return -EINVAL, if sb_rdonly() - f2fs_stop_discard_thread -> wait for kthread_stop(discard_thread); Additional
locked - return -EINVAL, if sb_rdonly() - f2fs_stop_discard_thread -> wait for kthread_stop(discard_thread); Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/1036d3ea7a32cb7cee00885c73a1f2ba7fbc499a - https://git.kernel.org/stable/c/f47ed3b284b38f235355e281f57dfa8fffcc6563 - https://git.kernel.org/stable/c/3bdb7f161697e2d5123b89fe1778ef17a44858e7
CVE ID: CVE-2024-40970 State: PUBLISHED Published: 2024-07-12T12:32:08.788Z Last Updated: 2025-11-03T21:58:34.724Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: Avoid hw_desc array overrun in dw-axi-dmac I have a use case where nr_buffers = 3 and in which each descriptor is composed by 3 segments, resulting in the DMA channel descs_allocated to be 9. Since axi_desc_put() handles the hw_desc considering the descs_allocated, this scenario would result in a kernel panic (hw_desc array will be overrun). To fix this, the proposal is to add a new member to the axi_dma_desc structure, where we keep the number of allocated hw_descs (a
is, the proposal is to add a new member to the axi_dma_desc structure, where we keep the number of allocated hw_descs (axi_desc_alloc()) and use it in axi_desc_put() to handle the hw_desc array correctly. Additionally I propose to remove the axi_chan_start_first_queued() call after completing the transfer, since it was identified that unbalance can occur (started descriptors can be interrupted and transfer ignored due to DMA channel not being enabled). Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/7c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5 - https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e - htt
c3bb96a20cd8db3b8824b2ff08b6cde4505c7e5 - https://git.kernel.org/stable/c/dd42570018f5962c10f215ad9c21274ed5d3541e - https://git.kernel.org/stable/c/e151ae1ee065cf4b8ce4394ddb9d9c8df6370c66 - https://git.kernel.org/stable/c/9004784e8d68bcd1ac1376407ba296fa28f04dbe - https://git.kernel.org/stable/c/333e11bf47fa8d477db90e2900b1ed3c9ae9b697
CVE ID: CVE-2024-40971 State: PUBLISHED Published: 2024-07-12T12:32:09.440Z Last Updated: 2025-11-03T21:58:36.200Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: f2fs: remove clear SB_INLINECRYPT flag in default_options In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set. If create new file or open file during this gap, these files will not use inlinecrypt. Worse case, it may lead to data corruption if wrappedkey_v0 is enable. Thread A: Thread B: -f2fs_remount -f2fs_file_open or f2fs_new_inode -default_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again Addit
lt_options <- clear SB_INLINECRYPT flag -fscrypt_select_encryption_impl -parse_options <- set SB_INLINECRYPT again Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/38a82c8d00638bb642bef787eb1d5e0e4d3b7d71 - https://git.kernel.org/stable/c/724429db09e21ee153fef35e34342279d33df6ae - https://git.kernel.org/stable/c/a9cea0489c562c97cd56bb345e78939f9909e7f4 - https://git.kernel.org/stable/c/eddeb8d941d5be11a9da5637dbe81ac37e8449a2 - https://git.kernel.org/stable/c/ae39c8ec4250d2a35ddaab1c40faacfec306ff66 - https://git.kernel.org/stable/c/ac5eecf481c29942eb9a862e758c0c8b68090c33
CVE ID: CVE-2024-40972 State: PUBLISHED Published: 2024-07-12T12:32:10.102Z Last Updated: 2025-11-03T21:58:37.671Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ext4: do not create EA inode under buffer lock ext4_xattr_set_entry() creates new EA inodes while holding buffer lock on the external xattr block. This is problematic as it nests all the allocation locking (which acquires locks on other buffers) under the buffer lock. This can even deadlock when the filesystem is corrupted and e.g. quota file is setup to contain xattr block as data block. Move the allocation of EA inode out of ext4_xattr_set_entry() into the callers. A
to contain xattr block as data block. Move the allocation of EA inode out of ext4_xattr_set_entry() into the callers. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0752e7fb549d90c33b4d4186f11cfd25a556d1dd - https://git.kernel.org/stable/c/737fb7853acd5bc8984f6f42e4bfba3334be8ae1 - https://git.kernel.org/stable/c/111103907234bffd0a34fba070ad9367de058752 - https://git.kernel.org/stable/c/0a46ef234756dca04623b7591e8ebb3440622f0b
CVE ID: CVE-2024-40973 State: PUBLISHED Published: 2024-07-12T12:32:10.763Z Last Updated: 2025-11-03T19:30:26.626Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: media: mtk-vcodec: potential null pointer deference in SCP The return value of devm_kzalloc() needs to be checked to avoid NULL pointer deference. This is similar to CVE-2022-3113. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/eeb62bb4ca22db17f7dfe8fb8472e0442df3d92f - https://git.kernel.org/stable/c/f066882293b5ad359e44c4ed24ab1811ffb0b354 - https://git.kernel.org/stable/c/3a693c7e243b932faee5
/git.kernel.org/stable/c/f066882293b5ad359e44c4ed24ab1811ffb0b354 - https://git.kernel.org/stable/c/3a693c7e243b932faee5c1fb728efa73f0abc39b - https://git.kernel.org/stable/c/53dbe08504442dc7ba4865c09b3bbf5fe849681b
CVE ID: CVE-2024-40974 State: PUBLISHED Published: 2024-07-12T12:32:11.417Z Last Updated: 2025-11-03T21:58:39.132Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnosti
ZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array argument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS
ument is too small; is of size 32, callee requires at least 72 [-Werror,-Warray-bounds] 60 | plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, | ^ ~~~~~~ [1] Enabled for LLVM builds but not GCC for now. See commit 0da6e5fd6c37 ("gcc: disable '-Warray-bounds' for gcc-13 too") and related changes. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/acf2b80c31c37acab040baa3cf5f19fbd5140b18 - https://git.kernel.org/stable/c/19c166ee42cf16d8b156a6cb4544122d9a65d3ca - https://git.kernel.org/stable/c/a8c988d752b3d98d5cc1e3929c519a55ef55426c - https://git.kernel.org/stable/c/262e942ff5a839b9e4f3302a8987928b0c8b8a2d - https://git.kernel.
cc1e3929c519a55ef55426c - https://git.kernel.org/stable/c/262e942ff5a839b9e4f3302a8987928b0c8b8a2d - https://git.kernel.org/stable/c/8aa11aa001576bf3b00dcb8559564ad7a3113588 - https://git.kernel.org/stable/c/3ad0034910a57aa88ed9976b1431b7b8c84e0048 - https://git.kernel.org/stable/c/aa6107dcc4ce9a3451f2d729204713783b657257 - https://git.kernel.org/stable/c/ff2e185cf73df480ec69675936c4ee75a445c3e4
CVE ID: CVE-2024-40975 State: PUBLISHED Published: 2024-07-12T12:32:12.099Z Last Updated: 2025-05-04T09:19:10.560Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: platform/x86: x86-android-tablets: Unregister devices in reverse order Not all subsystems support a device getting removed while there are still consumers of the device with a reference to the device. One example of this is the regulator subsystem. If a regulator gets unregistered while there are still drivers holding a reference a WARN() at drivers/regulator/core.c:5829 triggers, e.g.: WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister Har
egulator/core.c:5829 triggers, e.g.: WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister Hardware name: Intel Corp. VALLEYVIEW C0 PLATFORM/BYT-T FFD8, BIOS BLADE_21.X64.0005.R00.1504101516 FFD8_X64_R_2015_04_10_1516 04/10/2015 RIP: 0010:regulator_unregister Call Trace: <TASK> regulator_unregister devres_release_group i2c_device_remove device_release_driver_internal bus_remove_device device_del device_unregister x86_android_tablet_remove On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides a 5V boost converter output for powering USB devices connected to the micro USB port, the bq24190-charger driver exports this as a Vbus regulator. On the 830
ing USB devices connected to the micro USB port, the bq24190-charger driver exports this as a Vbus regulator. On the 830 (8") and 1050 ("10") models this regulator is controlled by a platform_device and x86_android_tablet_remove() removes platform_device-s before i2c_clients so the consumer gets removed first. But on the 1380 (13") model there is a lc824206xa micro-USB switch connected over I2C and the extcon driver for that controls the regulator. The bq24190 i2c-client *must* be registered first, because that creates the regulator with the lc824206xa listed as its consumer. If the regulator has not been registered yet the lc824206xa driver will end up getting a dummy regulator. Since in th
r. If the regulator has not been registered yet the lc824206xa driver will end up getting a dummy regulator. Since in this case both the regulator provider and consumer are I2C devices, the only way to ensure that the consumer is unregistered first is to unregister the I2C devices in reverse order of in which they were created. For consistency and to avoid similar problems in the future change x86_android_tablet_remove() to unregister all device types in reverse order. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/36ff963c133a25ed1166a25c3ba8b357ea010fda - https://git.kernel.org/stable/c/f0c982853d665597d17e4995ff479
el.org/stable/c/36ff963c133a25ed1166a25c3ba8b357ea010fda - https://git.kernel.org/stable/c/f0c982853d665597d17e4995ff479fbbf79a9cf6 - https://git.kernel.org/stable/c/3de0f2627ef849735f155c1818247f58404dddfe
CVE ID: CVE-2024-40976 State: PUBLISHED Published: 2024-07-12T12:32:12.782Z Last Updated: 2025-11-03T21:58:40.600Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drm/lima: mask irqs in timeout path before hard reset There is a race condition in which a rendering job might take just long enough to trigger the drm sched job timeout handler but also still complete before the hard reset is done by the timeout handler. This runs into race conditions not expected by the timeout handler. In some very specific cases it currently may result in a refcount imbalance on lima_pm_idle, with a stack dump such as: [10136.669170] WARNING: CPU:
t currently may result in a refcount imbalance on lima_pm_idle, with a stack dump such as: [10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0 ... [10136.669628] Call trace: [10136.669634] lima_devfreq_record_idle+0xa0/0xb0 [10136.669646] lima_sched_pipe_task_done+0x5c/0xb0 [10136.669656] lima_gp_irq_handler+0xa8/0x120 [10136.669666] __handle_irq_event_percpu+0x48/0x160 [10136.669679] handle_irq_event+0x4c/0xc0 We can prevent that race condition entirely by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirel
y by masking the irqs at the beginning of the timeout handler, at which point we give up on waiting for that job entirely. The irqs will be enabled again at the next hard reset which is already done as a recovery by the timeout handler. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/03e7b2f7ae4c0ae5fb8e4e2454ba4008877f196a - https://git.kernel.org/stable/c/70aa1f2dec46b6fdb5f6b9f37b6bfa4a4dee0d3a - https://git.kernel.org/stable/c/9fd8ddd23793a50dbcd11c6ba51f437f1ea7d344 - https://git.kernel.org/stable/c/bdbc4ca77f5eaac15de7230814253cddfed273b1 - https://git.kernel.org/stable/c/58bfd311c93d66d8282bf21ebbf35cc3bb8ad9db
e/c/bdbc4ca77f5eaac15de7230814253cddfed273b1 - https://git.kernel.org/stable/c/58bfd311c93d66d8282bf21ebbf35cc3bb8ad9db - https://git.kernel.org/stable/c/a421cc7a6a001b70415aa4f66024fa6178885a14
CVE ID: CVE-2024-40977 State: PUBLISHED Published: 2024-07-12T12:32:13.447Z Last Updated: 2025-11-03T21:58:42.062Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mt76: mt7921s: fix potential hung tasks during chip recovery During chip recovery (e.g. chip reset), there is a possible situation that kernel worker reset_work is holding the lock and waiting for kernel thread stat_worker to be parked, while stat_worker is waiting for the release of the same lock. It causes a deadlock resulting in the dumping of hung tasks messages and possible rebooting of the device. This patch prevents the execution of stat_worker during the
f hung tasks messages and possible rebooting of the device. This patch prevents the execution of stat_worker during the chip recovery. Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/0b81faa05b0b9feb3ae2d69be1d21f0d126ecb08 - https://git.kernel.org/stable/c/85edd783f4539a994d66c4c014d5858f490b7a02 - https://git.kernel.org/stable/c/e974dd4c22a23ec3ce579fb6d31a674ac0435da9 - https://git.kernel.org/stable/c/ecf0b2b8a37c8464186620bef37812a117ff6366
CVE ID: CVE-2024-40978 State: PUBLISHED Published: 2024-07-12T12:32:14.149Z Last Updated: 2025-11-03T21:58:43.534Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: scsi: qedi: Fix crash while reading debugfs attribute The qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directly on a __user pointer, which results into the crash. To fix this issue, use a small local stack buffer for sprintf() and then call simple_read_from_buffer(), which in turns make the copy_to_user() call. BUG: unable to handle page fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops
age fault for address: 00007f4801111000 PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0 Oops: 0002 [#1] PREEMPT SMP PTI Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023 RIP: 0010:memcpy_orig+0xcd/0x130 RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202 RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000f RDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000 RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572 R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fff R13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000
00007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7af FS: 00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: <TASK> ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x
+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdc RIP: 0033:0x7f4800f20b4d Additional Analyst Notes: - CVE Program Container: - CISA ADP Vulnrichment: References: - https://git.kernel.org/stable/c/56bec63a7fc87ad50b3373a87517dc9770eef9e0 - https://git.kernel.org/stable/c/
eferences: - https://git.kernel.org/stable/c/56bec63a7fc87ad50b3373a87517dc9770eef9e0 - https://git.kernel.org/stable/c/21c963de2e86e88f6a8ca556bcebb8e62ab8e901 - https://git.kernel.org/stable/c/144d76a676b630e321556965011b00e2de0b40a7 - https://git.kernel.org/stable/c/397a8990c377ee4b61d6df768e61dff9e316d46b - https://git.kernel.org/stable/c/eaddb86637669f6bad89245ee63f8fb2bfb50241 - https://git.kernel.org/stable/c/fa85b016a56b9775a3fe41e5d26e666945963b46 - https://git.kernel.org/stable/c/e2f433ea7d0ff77998766a088a287337fb43ad75 - https://git.kernel.org/stable/c/28027ec8e32ecbadcd67623edb290dad61e735b5
CVE ID: CVE-2024-40979 State: PUBLISHED Published: 2024-07-12T12:32:14.902Z Last Updated: 2025-05-04T09:19:15.683Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: ath12k: fix kernel crash during resume Currently during resume, QMI target memory is not properly handled, resulting in kernel crash in case DMA remap is not supported: BUG: Bad page state in process kworker/u16:54 pfn:36e80 page: refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x36e80 page dumped because: nonzero _refcount Call Trace: bad_page free_page_is_bad_report __free_pages_ok __free_pages dma_direct_free dma_free_attrs ath12k_qmi_free_target_
ce: bad_page free_page_is_bad_report __free_pages_ok __free_pages dma_direct_free dma_free_attrs ath12k_qmi_free_target_mem_chunk ath12k_qmi_msg_mem_request_cb The reason is: Once ath12k module is loaded, firmware sends memory request to host. In case DMA remap not supported, ath12k refuses the first request due to failure in allocating with large segment size: ath12k_pci 0000:04:00.0: qmi firmware request memory request ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 7077888 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 8454144 ath12k_pci 0000:04:00.0: qmi dma allocation failed (7077888 B type 1), will try later with small size ath12k_pci 0000:04:00.0: qmi delays mem_request 2 ath12k_pc
on failed (7077888 B type 1), will try later with small size ath12k_pci 0000:04:00.0: qmi delays mem_request 2 ath12k_pci 0000:04:00.0: qmi firmware request memory request Later firmware comes back with more but small segments and allocation succeeds: ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144
524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 262144 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 1 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:0
000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg type 4 size 524288 ath12k_pci 0000:04:00.0: qmi mem seg typ