From: Simon Horman <horms@kernel.org>
To: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Ariel Elior <aelior@marvell.com>,
Manish Chopra <manishc@marvell.com>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
Michal Kalderon <Michal.Kalderon@cavium.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-hardening@vger.kernel.org
Subject: Re: [PATCH] qed/red_ll2: Fix undefined behavior bug in struct qed_ll2_info
Date: Thu, 28 Sep 2023 15:27:37 +0200 [thread overview]
Message-ID: <20230928132737.GL24230@kernel.org> (raw)
In-Reply-To: <ZQ+Nz8DfPg56pIzr@work>
On Sat, Sep 23, 2023 at 07:15:59PM -0600, Gustavo A. R. Silva wrote:
> The flexible structure (a structure that contains a flexible-array member
> at the end) `qed_ll2_tx_packet` is nested within the second layer of
> `struct qed_ll2_info`:
>
> struct qed_ll2_tx_packet {
> ...
> /* Flexible Array of bds_set determined by max_bds_per_packet */
> struct {
> struct core_tx_bd *txq_bd;
> dma_addr_t tx_frag;
> u16 frag_len;
> } bds_set[];
> };
>
> struct qed_ll2_tx_queue {
> ...
> struct qed_ll2_tx_packet cur_completing_packet;
> };
>
> struct qed_ll2_info {
> ...
> struct qed_ll2_tx_queue tx_queue;
> struct qed_ll2_cbs cbs;
> };
>
> The problem is that member `cbs` in `struct qed_ll2_info` is placed just
> after an object of type `struct qed_ll2_tx_queue`, which is in itself
> an implicit flexible structure, which by definition ends in a flexible
> array member, in this case `bds_set`. This causes an undefined behavior
> bug at run-time when dynamic memory is allocated for `bds_set`, which
> could lead to a serious issue if `cbs` in `struct qed_ll2_info` is
> overwritten by the contents of `bds_set`. Notice that the type of `cbs`
> is a structure full of function pointers (and a cookie :) ):
>
> include/linux/qed/qed_ll2_if.h:
> 107 typedef
> 108 void (*qed_ll2_complete_rx_packet_cb)(void *cxt,
> 109 struct qed_ll2_comp_rx_data *data);
> 110
> 111 typedef
> 112 void (*qed_ll2_release_rx_packet_cb)(void *cxt,
> 113 u8 connection_handle,
> 114 void *cookie,
> 115 dma_addr_t rx_buf_addr,
> 116 bool b_last_packet);
> 117
> 118 typedef
> 119 void (*qed_ll2_complete_tx_packet_cb)(void *cxt,
> 120 u8 connection_handle,
> 121 void *cookie,
> 122 dma_addr_t first_frag_addr,
> 123 bool b_last_fragment,
> 124 bool b_last_packet);
> 125
> 126 typedef
> 127 void (*qed_ll2_release_tx_packet_cb)(void *cxt,
> 128 u8 connection_handle,
> 129 void *cookie,
> 130 dma_addr_t first_frag_addr,
> 131 bool b_last_fragment, bool b_last_packet);
> 132
> 133 typedef
> 134 void (*qed_ll2_slowpath_cb)(void *cxt, u8 connection_handle,
> 135 u32 opaque_data_0, u32 opaque_data_1);
> 136
> 137 struct qed_ll2_cbs {
> 138 qed_ll2_complete_rx_packet_cb rx_comp_cb;
> 139 qed_ll2_release_rx_packet_cb rx_release_cb;
> 140 qed_ll2_complete_tx_packet_cb tx_comp_cb;
> 141 qed_ll2_release_tx_packet_cb tx_release_cb;
> 142 qed_ll2_slowpath_cb slowpath_cb;
> 143 void *cookie;
> 144 };
>
> Fix this by moving the declaration of `cbs` to the middle of its
> containing structure `qed_ll2_info`, preventing it from being
> overwritten by the contents of `bds_set` at run-time.
>
> This bug was introduced in 2017, when `bds_set` was converted to a
> one-element array, and started to be used as a Variable Length Object
> (VLO) at run-time.
>
> Fixes: f5823fe6897c ("qed: Add ll2 option to limit the number of bds per packet")
> Cc: stable@vger.kernel.org
> Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2023-09-28 13:27 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-24 1:15 [PATCH] qed/red_ll2: Fix undefined behavior bug in struct qed_ll2_info Gustavo A. R. Silva
2023-09-23 19:43 ` Kees Cook
2023-09-28 13:27 ` Simon Horman [this message]
2023-10-03 8:40 ` patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230928132737.GL24230@kernel.org \
--to=horms@kernel.org \
--cc=Michal.Kalderon@cavium.com \
--cc=aelior@marvell.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=gustavoars@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=manishc@marvell.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.