https://bugs.dpdk.org/show_bug.cgi?id=2030
Bug ID: 2030
Summary: Duplicate mbox_alloc_msg_npa_aq_enq() causes orphaned
AQ message to be sent to AF
Product: DPDK
Version: 24.11
Hardware: ARM
OS: Linux
Status: UNCONFIRMED
Severity: major
Priority: Normal
Component: ethdev
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Created attachment 389
--> https://bugs.dpdk.org/attachment.cgi?id=389&action=edit
Issue description
In npa_aura_pool_init(), the pool init message allocation is performed twice on
non-CN20K platforms (e.g. CN10K).
Line 110 allocates a message via the else branch, but line 112 unconditionally
allocates another message, overwriting the pool_init_req pointer. The message
allocated at line 110 is never initialized by the caller and is sent to the AF
with only its mbox header (sig, id) set — all other fields (aura_id, ctype, op,
context data) contain whatever was in the mbox buffer at the time of
allocation.
// roc_npa.c lines 106-118
106 if (roc_model_is_cn20k()) {
107 pool_init_req_cn20k =
mbox_alloc_msg_npa_cn20k_aq_enq(mbox);
108 pool_init_req = (struct npa_aq_enq_req
*)pool_init_req_cn20k;
109 } else {
110 pool_init_req = mbox_alloc_msg_npa_aq_enq(mbox);
111 }
112 pool_init_req = mbox_alloc_msg_npa_aq_enq(mbox);
113 if (pool_init_req == NULL)
114 goto exit;
115 pool_init_req->aura_id = aura_id;
116 pool_init_req->ctype = NPA_AQ_CTYPE_POOL;
117 pool_init_req->op = NPA_AQ_INSTOP_INIT;
118 mbox_memcpy(&pool_init_req->pool, pool, sizeof(*pool));
As a result, mbox_process() at line 120 sends three NPA_AQ_ENQ messages to the
AF instead of the intended two (AURA_INIT + POOL_INIT). The orphaned message is
processed by the AF with uninitialized fields.
On CN20K, the same issue exists: line 107 allocates via
mbox_alloc_msg_npa_cn20k_aq_enq(), and line 112 allocates again
unconditionally.
Impact:
- Every call to roc_npa_pool_create() sends a spurious AQ command to the AF
with uninitialized payload. This occurs once per pool/aura pair created during
the lifetime of the application.
- The uninitialized fields default to ctype=0 (NPA_AQ_CTYPE_AURA) and op=0
(NPA_AQ_INSTOP_NOP) if the mbox buffer was zeroed, which is likely benign.
However, if the buffer contains residual data from a prior message, the AF may
execute an unintended operation (e.g., INIT or WRITE with corrupt context data)
on an arbitrary aura/pool.
Suggested fix:
Remove line 112. The if/else block at lines 106-111 already handles both
CN20K and non-CN20K allocation correctly:
if (roc_model_is_cn20k()) {
pool_init_req_cn20k = mbox_alloc_msg_npa_cn20k_aq_enq(mbox);
pool_init_req = (struct npa_aq_enq_req *)pool_init_req_cn20k;
} else {
pool_init_req = mbox_alloc_msg_npa_aq_enq(mbox);
}
- pool_init_req = mbox_alloc_msg_npa_aq_enq(mbox);
if (pool_init_req == NULL)
goto exit;
How to reproduce:
Any application that creates an NPA pool on CN10K or CN20K will trigger this.
Enable debug logging (--log-level=*:debug) and observe three NPA_AQ_ENQ
messages sent during npa_aura_pool_init() instead of two.
--
You are receiving this mail because:
You are the assignee for the bug.
