From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 4EA2C4591E; Fri, 6 Sep 2024 15:57:55 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D792640B99; Fri, 6 Sep 2024 15:57:54 +0200 (CEST) Received: from inbox.dpdk.org (inbox.dpdk.org [95.142.172.178]) by mails.dpdk.org (Postfix) with ESMTP id 626A24025D for ; Fri, 6 Sep 2024 15:57:54 +0200 (CEST) Received: by inbox.dpdk.org (Postfix, from userid 33) id 4BAA44591F; Fri, 6 Sep 2024 15:57:54 +0200 (CEST) From: bugzilla@dpdk.org To: dev@dpdk.org Subject: [DPDK/ethdev Bug 1536] net/tap: crash in tap pmd when using more than RTE_MP_MAX_FD_NUM rx queues Date: Fri, 06 Sep 2024 13:57:54 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: DPDK X-Bugzilla-Component: ethdev X-Bugzilla-Version: 22.03 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: edwin.brossette@6wind.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: Normal X-Bugzilla-Assigned-To: dev@dpdk.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version rep_platform op_sys bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: multipart/alternative; boundary=17256310740.C1e6.2477811 Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All MIME-Version: 1.0 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --17256310740.C1e6.2477811 Date: Fri, 6 Sep 2024 15:57:54 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All https://bugs.dpdk.org/show_bug.cgi?id=3D1536 Bug ID: 1536 Summary: net/tap: crash in tap pmd when using more than RTE_MP_MAX_FD_NUM rx queues Product: DPDK Version: 22.03 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: Normal Component: ethdev Assignee: dev@dpdk.org Reporter: edwin.brossette@6wind.com Target Milestone: --- Hello, I have recently stumbled into an issue with my DPDK-based application runni= ng the failsafe pmd. This pmd uses a tap device, with which my application fai= ls to start if more than 8 rx queues are used. This issue appears to be relate= d to this patch: https://git.dpdk.org/dpdk/commit/?id=3Dc36ce7099c2187926cd62cff7ebd47982355= 4929 I have seen in the documentation that there was a limitation to 8 max queues shared when using a tap device shared between multiple processes. However, = my application uses a single primary process, with no secondary process, but it appears that I am still running into this limitation. Now if we look at this small chunk of code: memset(&msg, 0, sizeof(msg)); strlcpy(msg.name, TAP_MP_REQ_START_RXTX, sizeof(msg.name)); strlcpy(request_param->port_name, dev->data->name, sizeof(request_param->port_name)); msg.len_param =3D sizeof(*request_param); for (i =3D 0; i < dev->data->nb_tx_queues; i++) { msg.fds[fd_iterator++] =3D process_private->txq_fds[i]; msg.num_fds++; request_param->txq_count++; } for (i =3D 0; i < dev->data->nb_rx_queues; i++) { msg.fds[fd_iterator++] =3D process_private->rxq_fds[i]; msg.num_fds++; request_param->rxq_count++; } (Note that I am not using the latest DPDK version, but stable v23.11.1. But= I believe the issue is still present on latest.) There are no checks on the maximum value i can take in the for loops. Since= the size of msg.fds is limited by the maximum of 8 queues shared between process because of the IPC API, there is a potential buffer overflow which can happ= en here. See the struct declaration: struct rte_mp_msg { char name[RTE_MP_MAX_NAME_LEN]; int len_param; int num_fds; uint8_t param[RTE_MP_MAX_PARAM_LEN]; int fds[RTE_MP_MAX_FD_NUM]; }; This means that if the number of queues used is more than 8, the program wi= ll crash. This is what happens on my end as I get the following log: *** stack smashing detected ***: terminated Reverting the commit mentioned above fixes my issue. Also setting a check l= ike this works for me: if (dev->data->nb_tx_queues + dev->data->nb_rx_queues > RTE_MP_MAX_FD_NUM) return -1; I've made the changes on my local branch to fix my issue. ---------- Potential fixes discussed:=20 1. Add "nb_rx_queues > RTE_MP_MAX_FD_NUM" check to not blindly update the 'msg.fds[]' 2. Prevent this to be a limit for tap PMD when there is only a primary proc= ess. --=20 You are receiving this mail because: You are the assignee for the bug.= --17256310740.C1e6.2477811 Date: Fri, 6 Sep 2024 15:57:54 +0200 MIME-Version: 1.0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://bugs.dpdk.org/ Auto-Submitted: auto-generated X-Auto-Response-Suppress: All
Bug ID 1536
Summary net/tap: crash in tap pmd when using more than RTE_MP_MAX_FD_= NUM rx queues
Product DPDK
Version 22.03
Hardware All
OS All
Status UNCONFIRMED
Severity normal
Priority Normal
Component ethdev
Assignee dev@dpdk.org
Reporter edwin.brossette@6wind.com
Target Milestone --- 

Hello,

I have recently stumbled into an issue with my DPDK-based application runni=
ng
the failsafe pmd. This pmd uses a tap device, with which my application fai=
ls
to start if more than 8 rx queues are used. This issue appears to be relate=
d to
this patch:
https://git.dpdk.org/dpdk/commit/?id=3Dc36ce7099c2187926cd=
62cff7ebd479823554929

I have seen in the documentation that there was a limitation to 8 max queues
shared when using a tap device shared between multiple processes. However, =
my
application uses a single primary process, with no secondary process, but it
appears that I am still running into this limitation.

Now if we look at this small chunk of code:

memset(&msg, 0, sizeof(msg));
strlcpy(msg.name, TAP_MP_REQ_START_RXTX, sizeof(msg.name));
strlcpy(request_param->port_name, dev->data->name,
sizeof(request_param->port_name));
msg.len_param =3D sizeof(*request_param);
for (i =3D 0; i < dev->data->nb_tx_queues; i++) {
    msg.fds[fd_iterator++] =3D process_private->txq_fds[i];
    msg.num_fds++;
    request_param->txq_count++;
}
for (i =3D 0; i < dev->data->nb_rx_queues; i++) {
    msg.fds[fd_iterator++] =3D process_private->rxq_fds[i];
    msg.num_fds++;
    request_param->rxq_count++;
}
(Note that I am not using the latest DPDK version, but stable v23.11.1. But=
 I
believe the issue is still present on latest.)

There are no checks on the maximum value i can take in the for loops. Since=
 the
size of msg.fds is limited by the maximum of 8 queues shared between process
because of the IPC API, there is a potential buffer overflow which can happ=
en
here.

See the struct declaration:
struct rte_mp_msg {
     char name[RTE_MP_MAX_NAME_LEN];
     int len_param;
     int num_fds;
     uint8_t param[RTE_MP_MAX_PARAM_LEN];
     int fds[RTE_MP_MAX_FD_NUM];
};

This means that if the number of queues used is more than 8, the program wi=
ll
crash. This is what happens on my end as I get the following log:
*** stack smashing detected ***: terminated

Reverting the commit mentioned above fixes my issue. Also setting a check l=
ike
this works for me:

if (dev->data->nb_tx_queues + dev->data->nb_rx_queues > RTE_=
MP_MAX_FD_NUM)
     return -1;

I've made the changes on my local branch to fix my issue.

----------

Potential fixes discussed:=20

1. Add "nb_rx_queues > RTE_MP_MAX_FD_NUM" check to not blindly=
 update the
'msg.fds[]'

2. Prevent this to be a limit for tap PMD when there is only a primary proc=
ess.

You are receiving this mail because:
  • You are the assignee for the bug.
=20=20=20=20=20=20=20=20=20=20
= --17256310740.C1e6.2477811--