[PATCH v1 6/8] net/zxdh: allocate a zeroed full-size payload buffer

[Junlong Wang]

zxdh_bar_irq_recv() allocates the request buffer with
rte_malloc(NULL, msg_header.len, 0), where len is written by the
sender into the shared window and is only checked against the 2036
byte maximum. pf_recv_bar_msg() then casts the buffer to a full
struct zxdh_msg_info and dispatches it through zxdh_proc_cb[] without
passing the length on, so no handler can check it.

A short request therefore reads past the allocation, and a
ZXDH_FLOW_HW_GET request with len = 180 writes the 16-byte result
field at offset 180 entirely outside the 180-byte buffer, corrupting
the EAL heap. The dispatcher itself already over-reads for len < 7.

Allocate the maximum payload size, zeroed, and still copy in only
len bytes: ZXDH_BAR_MSG_PAYLOAD_MAX_LEN equals
sizeof(struct zxdh_msg_info), which the header check already
guarantees len does not exceed, so every handler access stays inside
the buffer and a short head decodes as zeroed instead of reading past
the end. The reply path already allocates the maximum for its buffer.

Fixes: 3630ac8bd81f ("net/zxdh: configure interrupt")
Cc: stable at dpdk.org

Signed-off-by: Junlong Wang <wang.junlong1 at zte.com.cn>
---
 drivers/net/zxdh/zxdh_msg.c | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/net/zxdh/zxdh_msg.c b/drivers/net/zxdh/zxdh_msg.c
index c7a3281987..95b2f5a60b 100644
--- a/drivers/net/zxdh/zxdh_msg.c
+++ b/drivers/net/zxdh/zxdh_msg.c
@@ -1009,7 +1009,12 @@ zxdh_bar_irq_recv(uint8_t src, uint8_t dst, uint64_t virt_addr, void *dev)
 		return -1;
 	}
 
-	recved_msg = rte_malloc(NULL, msg_header.len, 0);
+	/*
+	 * The sender chooses the length, but the receive callbacks access the
+	 * payload as a full struct zxdh_msg_info: always give them a zeroed
+	 * buffer of the maximum payload size.
+	 */
+	recved_msg = rte_zmalloc(NULL, ZXDH_BAR_MSG_PAYLOAD_MAX_LEN, 0);
 	if (recved_msg == NULL) {
 		PMD_MSG_LOG(ERR, "malloc temp buff failed");
 		return -1;
-- 
2.27.0
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mails.dpdk.org/archives/stable/attachments/20261107/667b185d/attachment.htm>