Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
ai_data->graph[dai->id]=NULL leading to NULL pointer exception: qcom-apm gprsvc:service:2:1: Error (1) Processing 0x01001002 cmd qcom-apm gprsvc:service:2:1: DSP returned error[1001002] 1 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: fail to start APM port 78 q6apm-lpass-dais 30000000.remoteproc:glink-edge:gpr:service@1:bedais: ASoC: error at snd_soc_pcm_dai_prepare on TX_CODEC_DMA_TX_3: -22 Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a8 ... Call trace: q6apm_graph_media_format_pcm+0x48/0x120 (P) q6apm_lpass_dai_prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0 Refe
prepare+0x110/0x1b4 snd_soc_pcm_dai_prepare+0x74/0x108 __soc_pcm_prepare+0x44/0x160 dpcm_be_dai_prepare+0x124/0x1c0 References: - https://git.kernel.org/stable/c/01d1ba106c9e02a2e7d41e07be49031a0ff0ecaa - https://git.kernel.org/stable/c/411f7d4f7038200cdf6d4f71ee31026ebf2dfedb - https://git.kernel.org/stable/c/9c534dbfd1726502abcf0bd393a04214f62c050b - https://git.kernel.org/stable/c/cc336b242ea7e7a09b3ab9f885341455ca0a3bdb - https://git.kernel.org/stable/c/68f27f7c7708183e7873c585ded2f1b057ac5b97
CVE ID: CVE-2025-39939 State: PUBLISHED Published: 2025-10-04T07:31:02.521Z Last Updated: 2025-10-04T07:31:02.521Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: iommu/s390: Fix memory corruption when using identity domain zpci_get_iommu_ctrs() returns counter information to be reported as part of device statistics; these counters are stored as part of the s390_domain. The problem, however, is that the identity domain is not backed by an s390_domain and so the conversion via to_s390_domain() yields a bad address that is zero'd initially and read on-demand later via a sysfs read. These counters aren't necessary for the identity
ss that is zero'd initially and read on-demand later via a sysfs read. These counters aren't necessary for the identity domain; just return NULL in this case. This issue was discovered via KASAN with reports that look like: BUG: KASAN: global-out-of-bounds in zpci_fmb_enable_device when using the identity domain for a device on s390. References: - https://git.kernel.org/stable/c/17a58caf3863163c4a84a218a9649be2c8061443 - https://git.kernel.org/stable/c/b3506e9bcc777ed6af2ab631c86a9990ed97b474
CVE ID: CVE-2025-39940 State: PUBLISHED Published: 2025-10-04T07:31:03.309Z Last Updated: 2025-10-04T07:31:03.309Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: dm-stripe: fix a possible integer overflow There's a possible integer overflow in stripe_io_hints if we have too large chunk size. Test if the overflow happened, and if it did, don't set limits->io_min and limits->io_opt; References: - https://git.kernel.org/stable/c/f8f64254bca5ae58f3b679441962bda4c409f659 - https://git.kernel.org/stable/c/ee27658c239b27721397f3e4eb16370b5cce596e - https://git.kernel.org/stable/c/1071d560afb4c245c2076494226df47db5a35708
CVE ID: CVE-2025-39941 State: PUBLISHED Published: 2025-10-04T07:31:04.080Z Last Updated: 2025-10-04T07:31:04.080Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: zram: fix slot write race condition Parallel concurrent writes to the same zram index result in leaked zsmalloc handles. Schematically we can have something like this: CPU0 CPU1 zram_slot_lock() zs_free(handle) zram_slot_lock() zram_slot_lock() zs_free(handle) zram_slot_lock() compress compress handle = zs_malloc() handle = zs_malloc() zram_slot_lock zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock Either CPU0 or CPU1 zsmallo
zram_set_handle(handle) zram_slot_lock zram_slot_lock zram_set_handle(handle) zram_slot_lock Either CPU0 or CPU1 zsmalloc handle will leak because zs_free() is done too early. In fact, we need to reset zram entry right before we set its new handle, all under the same slot lock scope. References: - https://git.kernel.org/stable/c/ff750e9f2c4d63854c33967d1646b5e89a9a19a2 - https://git.kernel.org/stable/c/ce4be9e4307c5a60701ff6e0cafa74caffdc54ce
CVE ID: CVE-2025-39942 State: PUBLISHED Published: 2025-10-04T07:31:04.810Z Last Updated: 2025-10-04T07:31:04.810Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: verify remaining_data_length respects max_fragmented_recv_size This is inspired by the check for data_offset + data_length. References: - https://git.kernel.org/stable/c/196a3a7676d726ee67621ea2bf3b7815ac2685b4 - https://git.kernel.org/stable/c/d3cb3f209d35c44b7ee74f77ed27ebb28995b9ce - https://git.kernel.org/stable/c/9644798294c7287e65a7b26e35aa6d2ce3345bcc - https://git.kernel.org/stable/c/c64b915bb3d9339adcae5db4be2c35ffbef5e615 - https://git.kerne
e65a7b26e35aa6d2ce3345bcc - https://git.kernel.org/stable/c/c64b915bb3d9339adcae5db4be2c35ffbef5e615 - https://git.kernel.org/stable/c/e1868ba37fd27c6a68e31565402b154beaa65df0
CVE ID: CVE-2025-39943 State: PUBLISHED Published: 2025-10-04T07:31:05.581Z Last Updated: 2025-10-04T07:37:03.203Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ksmbd: smbdirect: validate data_offset and data_length field of smb_direct_data_transfer If data_offset and data_length of smb_direct_data_transfer struct are invalid, out of bounds issue could happen. This patch validate data_offset and data_length field in recv_done. References: - https://git.kernel.org/stable/c/773fddf976d282ef059c36c575ddb81567acd6bc - https://git.kernel.org/stable/c/bdaab5c6538e250a9654127e688ecbbeb6f771d5 - https://git.kernel.org/stable/c/eb0378d
6bc - https://git.kernel.org/stable/c/bdaab5c6538e250a9654127e688ecbbeb6f771d5 - https://git.kernel.org/stable/c/eb0378dde086363046ed3d7db7f126fc3f76fd70 - https://git.kernel.org/stable/c/8be498fcbd5b07272f560b45981d4b9e5a2ad885 - https://git.kernel.org/stable/c/529b121b00a6ee3c88fb3c01b443b2b81f686d48 - https://git.kernel.org/stable/c/5282491fc49d5614ac6ddcd012e5743eecb6a67c
CVE ID: CVE-2025-39944 State: PUBLISHED Published: 2025-10-04T07:31:06.339Z Last Updated: 2025-10-04T07:31:06.339Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: Fix use-after-free bugs in otx2_sync_tstamp() The original code relies on cancel_delayed_work() in otx2_ptp_destroy(), which does not ensure that the delayed work item synctstamp_work has fully completed if it was already running. This leads to use-after-free scenarios where otx2_ptp is deallocated by otx2_ptp_destroy(), while synctstamp_work remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp(). Furthermore, the synctstamp_work is cyc
_work remains active and attempts to dereference otx2_ptp in otx2_sync_tstamp(). Furthermore, the synctstamp_work is cyclic, the likelihood of triggering the bug is nonnegligible. A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) otx2_remove() | otx2_ptp_destroy() | otx2_sync_tstamp() cancel_delayed_work() | kfree(ptp) | | ptp = container_of(...); //UAF | ptp-> //UAF This is confirmed by a KASAN report: BUG: KASAN: slab-use-after-free in __run_timer_base.part.0+0x7d7/0x8c0 Write of size 8 at addr ffff88800aa09a18 by task bash/136 ... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_repo
... Call Trace: <IRQ> dump_stack_lvl+0x55/0x70 print_report+0xcf/0x610 ? __run_timer_base.part.0+0x7d7/0x8c0 kasan_report+0xb8/0xf0 ? __run_timer_base.part.0+0x7d7/0x8c0 __run_timer_base.part.0+0x7d7/0x8c0 ? __pfx___run_timer_base.part.0+0x10/0x10 ? __pfx_read_tsc+0x10/0x10 ? ktime_get+0x60/0x140 ? lapic_next_event+0x11/0x20 ? clockevents_program_event+0x1d4/0x2a0 run_timer_softirq+0xd1/0x190 handle_softirqs+0x16a/0x550 irq_exit_rcu+0xaf/0xe0 sysvec_apic_timer_interrupt+0x70/0x80 </IRQ> ... Allocated by task 1: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 __kasan_kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x47
kmalloc+0x7f/0x90 otx2_ptp_init+0xb1/0x860 otx2_probe+0x4eb/0xc30 local_pci_probe+0xdc/0x190 pci_device_probe+0x2fe/0x470 really_probe+0x1ca/0x5c0 __driver_probe_device+0x248/0x310 driver_probe_device+0x44/0x120 __driver_attach+0xd2/0x310 bus_for_each_dev+0xed/0x170 bus_add_driver+0x208/0x500 driver_register+0x132/0x460 do_one_initcall+0x89/0x300 kernel_init_freeable+0x40d/0x720 kernel_init+0x1a/0x150 ret_from_fork+0x10c/0x1a0 ret_from_fork_asm+0x1a/0x30 Freed by task 136: kasan_save_stack+0x24/0x50 kasan_save_track+0x14/0x30 kasan_save_free_info+0x3a/0x60 __kasan_slab_free+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_rele
+0x3f/0x50 kfree+0x137/0x370 otx2_ptp_destroy+0x38/0x80 otx2_remove+0x10d/0x4c0 pci_device_remove+0xa6/0x1d0 device_release_driver_internal+0xf8/0x210 pci_stop_bus_device+0x105/0x150 pci_stop_and_remove_bus_device_locked+0x15/0x30 remove_store+0xcc/0xe0 kernfs_fop_write_iter+0x2c3/0x440 vfs_write+0x871/0xd70 ksys_write+0xee/0x1c0 do_syscall_64+0xac/0x280 entry_SYSCALL_64_after_hwframe+0x77/0x7f ... Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the delayed work item is properly canceled before the otx2_ptp is deallocated. This bug was initially identified through static analysis. To reproduce and test it, I simulated the OcteonTX2 PCI device in QEMU and introduc
identified through static analysis. To reproduce and test it, I simulated the OcteonTX2 PCI device in QEMU and introduced artificial delays within the otx2_sync_tstamp() function to increase the likelihood of triggering the bug. References: - https://git.kernel.org/stable/c/2786879aebf363806a13d41e8d5f99202ddd23d9 - https://git.kernel.org/stable/c/d2cfefa14ce8137b17f99683f968bebf134b6a48 - https://git.kernel.org/stable/c/ff27e23b311fed4d25e3852e27ba693416d4c7b3 - https://git.kernel.org/stable/c/5ca20bb7b4bde72110c3ae78423cbfdd0157aa36 - https://git.kernel.org/stable/c/f8b4687151021db61841af983f1cb7be6915d4ef
CVE ID: CVE-2025-39945 State: PUBLISHED Published: 2025-10-04T07:31:07.109Z Last Updated: 2025-10-04T07:37:04.574Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cnic: Fix use-after-free bugs in cnic_delete_task The original code uses cancel_delayed_work() in cnic_cm_stop_bnx2x_hw(), which does not guarantee that the delayed work item 'delete_task' has fully completed if it was already running. Additionally, the delayed work item is cyclic, the flush_workqueue() in cnic_cm_stop_bnx2x_hw() only blocks and waits for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_
for work items that were already queued to the workqueue prior to its invocation. Any work items submitted after flush_workqueue() is called are not included in the set of tasks that the flush operation awaits. This means that after the cyclic work items have finished executing, a delayed work item may still exist in the workqueue. This leads to use-after-free scenarios where the cnic_dev is deallocated by cnic_free_dev(), while delete_task remains active and attempt to dereference cnic_dev in cnic_delete_task(). A typical race condition is illustrated below: CPU 0 (cleanup) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | .
p) | CPU 1 (delayed work callback) cnic_netdev_event() | cnic_stop_hw() | cnic_delete_task() cnic_cm_stop_bnx2x_hw() | ... cancel_delayed_work() | /* the queue_delayed_work() flush_workqueue() | executes after flush_workqueue()*/ | queue_delayed_work() cnic_free_dev(dev)//free | cnic_delete_task() //new instance | dev = cp->dev; //use Replace cancel_delayed_work() with cancel_delayed_work_sync() to ensure that the cyclic delayed work item is properly canceled and that any ongoing execution of the work item completes before the cnic_dev is deallocated. Furthermore, since cancel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the
cel_delayed_work_sync() uses __flush_work(work, true) to synchronously wait for any currently executing instance of the work item to finish, the flush_workqueue() becomes redundant and should be removed. This bug was identified through static analysis. To reproduce the issue and validate the fix, I simulated the cnic PCI device in QEMU and introduced intentional delays — such as inserting calls to ssleep() within the cnic_delete_task() function — to increase the likelihood of triggering the bug. References: - https://git.kernel.org/stable/c/fde6e73189f40ebcf0633aed2b68e731c25f3aa3 - https://git.kernel.org/stable/c/7b6a5b0a6b392263c3767fc945b311ea04b34bbd - https://git.kernel.org/stable/c/040
25f3aa3 - https://git.kernel.org/stable/c/7b6a5b0a6b392263c3767fc945b311ea04b34bbd - https://git.kernel.org/stable/c/0405055930264ea8fd26f4131466fa7652e5e47d - https://git.kernel.org/stable/c/e1fcd4a9c09feac0902a65615e866dbf22616125 - https://git.kernel.org/stable/c/8eeb2091e72d75df8ceaa2172638d61b4cf8929a - https://git.kernel.org/stable/c/6e33a7eed587062ca8161ad1f4584882a860d697 - https://git.kernel.org/stable/c/0627e1481676669cae2df0d85b5ff13e7d24c390 - https://git.kernel.org/stable/c/cfa7d9b1e3a8604afc84e9e51d789c29574fb216
CVE ID: CVE-2025-39946 State: PUBLISHED Published: 2025-10-04T07:31:07.871Z Last Updated: 2025-10-04T07:31:07.871Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: tls: make sure to abort the stream if headers are bogus Normally we wait for the socket to buffer up the whole record before we service it. If the socket has a tiny buffer, however, we read out the data sooner, to prevent connection stalls. Make sure that we abort the connection when we find out late that the record is actually invalid. Retrying the parsing is fine in itself but since we copy some more data each time before we parse we can overflow the allocated skb sp
arsing is fine in itself but since we copy some more data each time before we parse we can overflow the allocated skb space. Constructing a scenario in which we're under pressure without enough data in the socket to parse the length upfront is quite hard. syzbot figured out a way to do this by serving us the header in small OOB sends, and then filling in the recvbuf with a large normal send. Make sure that tls_rx_msg_size() aborts strp, if we reach an invalid record there's really no way to recover. References: - https://git.kernel.org/stable/c/b36462146d86b1f22e594fe4dae611dffacfb203 - https://git.kernel.org/stable/c/4cefe5be73886f383639fe0850bb72d5b568a7b9 - https://git.kernel.org/stable/c
1dffacfb203 - https://git.kernel.org/stable/c/4cefe5be73886f383639fe0850bb72d5b568a7b9 - https://git.kernel.org/stable/c/208640e6225cc929a05adbf79d1df558add3e231 - https://git.kernel.org/stable/c/61ca2da5fb8f433ce8bbd1657c84a86272133e6b - https://git.kernel.org/stable/c/0aeb54ac4cd5cf8f60131b4d9ec0b6dc9c27b20d
CVE ID: CVE-2025-39947 State: PUBLISHED Published: 2025-10-04T07:31:08.636Z Last Updated: 2025-10-04T07:31:08.636Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Harden uplink netdev access against device unbind The function mlx5_uplink_netdev_get() gets the uplink netdevice pointer from mdev->mlx5e_res.uplink_netdev. However, the netdevice can be removed and its pointer cleared when unbound from the mlx5_core.eth driver. This results in a NULL pointer, causing a kernel panic. BUG: unable to handle page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: <TASK> ml
page fault for address: 0000000000001300 at RIP: 0010:mlx5e_vport_rep_load+0x22a/0x270 [mlx5_core] Call Trace: <TASK> mlx5_esw_offloads_rep_load+0x68/0xe0 [mlx5_core] esw_offloads_enable+0x593/0x910 [mlx5_core] mlx5_eswitch_enable_locked+0x341/0x420 [mlx5_core] mlx5_devlink_eswitch_mode_set+0x17e/0x3a0 [mlx5_core] devlink_nl_eswitch_set_doit+0x60/0xd0 genl_family_rcv_msg_doit+0xe0/0x130 genl_rcv_msg+0x183/0x290 netlink_rcv_skb+0x4b/0xf0 genl_rcv+0x24/0x40 netlink_unicast+0x255/0x380 netlink_sendmsg+0x1f3/0x420 __sock_sendmsg+0x38/0x60 __sys_sendto+0x119/0x180 do_syscall_64+0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Ensure the pointer is valid before use by checking it for NULL. If i
0x53/0x1d0 entry_SYSCALL_64_after_hwframe+0x4b/0x53 Ensure the pointer is valid before use by checking it for NULL. If it is valid, immediately call netdev_hold() to take a reference, and preventing the netdevice from being freed while it is in use. References: - https://git.kernel.org/stable/c/2cb17c88edd3a1c7aa6bc880dcdb35a6866fcb2e - https://git.kernel.org/stable/c/d1f3db4e7a3be29fc17f01850f162363f919370d - https://git.kernel.org/stable/c/8df354eb2dd63d111ed5ae2e956e0dbb22bcf93b - https://git.kernel.org/stable/c/6b4be64fd9fec16418f365c2d8e47a7566e9eba5
CVE ID: CVE-2025-39948 State: PUBLISHED Published: 2025-10-04T07:31:09.403Z Last Updated: 2025-10-04T07:31:09.403Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: ice: fix Rx page leak on multi-buffer frames The ice_put_rx_mbuf() function handles calling ice_put_rx_buf() for each buffer in the current frame. This function was introduced as part of handling multi-buffer XDP support in the ice driver. It works by iterating over the buffers from first_desc up to 1 plus the total number of fragments in the frame, cached from before the XDP program was executed. If the hardware posts a descriptor with a size of 0, the logic used in i
ached from before the XDP program was executed. If the hardware posts a descriptor with a size of 0, the logic used in ice_put_rx_mbuf() breaks. Such descriptors get skipped and don't get added as fragments in ice_add_xdp_frag. Since the buffer isn't counted as a fragment, we do not iterate over it in ice_put_rx_mbuf(), and thus we don't call ice_put_rx_buf(). Because we don't call ice_put_rx_buf(), we don't attempt to re-use the page or free it. This leaves a stale page in the ring, as we don't increment next_to_alloc. The ice_reuse_rx_page() assumes that the next_to_alloc has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't chec
has been incremented properly, and that it always points to a buffer with a NULL page. Since this function doesn't check, it will happily recycle a page over the top of the next_to_alloc buffer, losing track of the old page. Note that this leak only occurs for multi-buffer frames. The ice_put_rx_mbuf() function always handles at least one buffer, so a single-buffer frame will always get handled correctly. It is not clear precisely why the hardware hands us descriptors with a size of 0 sometimes, but it happens somewhat regularly with "jumbo frames" used by 9K MTU. To fix ice_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Bor
ce_put_rx_mbuf(), we need to make sure to call ice_put_rx_buf() on all buffers between first_desc and next_to_clean. Borrow the logic of a similar function in i40e used for this same purpose. Use the same logic also in ice_get_pgcnts(). Instead of iterating over just the number of fragments, use a loop which iterates until the current index reaches to the next_to_clean element just past the current frame. Unlike i40e, the ice_put_rx_mbuf() function does call ice_put_rx_buf() on the last buffer of the frame indicating the end of packet. For non-linear (multi-buffer) frames, we need to take care when adjusting the pagecnt_bias. An XDP program might release fragments from the tail of the frame,
we need to take care when adjusting the pagecnt_bias. An XDP program might release fragments from the tail of the frame, in which case that fragment page is already released. Only update the pagecnt_bias for the first descriptor and fragments still remaining post-XDP program. Take care to only access the shared info for fragmented buffers, as this avoids a significant cache miss. The xdp_xmit value only needs to be updated if an XDP program is run, and only once per packet. Drop the xdp_xmit pointer argument from ice_put_rx_mbuf(). Instead, set xdp_xmit in the ice_clean_rx_irq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the
irq() function directly. This avoids needing to pass the argument and avoids an extra bit-wise OR for each buffer in the frame. Move the increment of the ntc local variable to ensure its updated *before* all calls to ice_get_pgcnts() or ice_put_rx_mbuf(), as the loop logic requires the index of the element just after the current frame. Now that we use an index pointer in the ring to identify the packet, we no longer need to track or cache the number of fragments in the rx_ring. References: - https://git.kernel.org/stable/c/80555adb5c892f0e21d243ae96ed997ee520aea9 - https://git.kernel.org/stable/c/fcb5718ebfe7fd64144e3399280440cce361a3ae - https://git.kernel.org/stable/c/84bf1ac85af84d354c7a2
git.kernel.org/stable/c/fcb5718ebfe7fd64144e3399280440cce361a3ae - https://git.kernel.org/stable/c/84bf1ac85af84d354c7a2fdbdc0d4efc8aaec34b
CVE ID: CVE-2025-39949 State: PUBLISHED Published: 2025-10-04T07:31:10.164Z Last Updated: 2025-10-04T07:37:05.967Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: qed: Don't collect too many protection override GRC elements In the protection override dump path, the firmware can return far too many GRC elements, resulting in attempting to write past the end of the previously-kmalloc'ed dump buffer. This will result in a kernel panic with reason: BUG: unable to handle kernel paging request at ADDRESS where "ADDRESS" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_f
SS" is just past the end of the protection override dump buffer. The start address of the buffer is: p_hwfn->cdev->dbg_features[DBG_FEATURE_PROTECTION_OVERRIDE].dump_buf and the size of the buffer is buf_size in the same data structure. The panic can be arrived at from either the qede Ethernet driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc02662ed [qed] qed_dbg_protection_override_dump at ffffffffc0267792 [qed] qed_dbg_feature at ffffffffc026aa8f [qed] qed_dbg_all_data at ffffffffc026b211 [qed] qed_fw_fatal_reporter_dump at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_repo
at ffffffffc027298a [qed] devlink_health_do_dump at ffffffff82497f61 devlink_health_report at ffffffff8249cf29 qed_report_fatal_error at ffffffffc0272baf [qed] qede_sp_task at ffffffffc045ed32 [qede] process_one_work at ffffffff81d19783 or the qedf storage driver path: [exception RIP: qed_grc_dump_addr_range+0x108] qed_protection_override_dump at ffffffffc068b2ed [qed] qed_dbg_protection_override_dump at ffffffffc068c792 [qed] qed_dbg_feature at ffffffffc068fa8f [qed] qed_dbg_all_data at ffffffffc0690211 [qed] qed_fw_fatal_reporter_dump at ffffffffc069798a [qed] devlink_health_do_dump at ffffffff8aa95e51 devlink_health_report at ffffffff8aa9ae19 qed_report_fatal_error at ffffffffc0697baf [q