[DPDK/ethdev Bug 2030] Duplicate mbox_alloc_msg_npa_aq_enq() causes orphaned AQ message to be sent to AF

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: dev@dpdk.org
          Reporter: amiyaranjan.mohakud@gmail.com
  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.