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>
prev parent reply other threads:[~2023-09-28 13:27 UTC|newest]
Thread overview: 3+ 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]
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox