drivers/net/ethernet/alteon/acenic.c | 15 +++++++++++++++ 1 file changed, 15 insertions(+)
The ace_start_xmit function does not check the return value of
dma_map_page (via ace_map_tx_skb) and skb_frag_dma_map when building
transmit descriptors. If mapping fails, an invalid DMA address is
written to the descriptor, which may cause hardware to access
illegal memory, leading to system instability or crashes.
Add proper dma_mapping_error() checks for all mapping calls. When
mapping fails, free the skb, increment the dropped packet counter,
and return NETDEV_TX_OK.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Wang Jun <1742789905@qq.com>
---
drivers/net/ethernet/alteon/acenic.c | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/drivers/net/ethernet/alteon/acenic.c b/drivers/net/ethernet/alteon/acenic.c
index 455ee8930824..acabede53663 100644
--- a/drivers/net/ethernet/alteon/acenic.c
+++ b/drivers/net/ethernet/alteon/acenic.c
@@ -2417,6 +2417,11 @@ static netdev_tx_t ace_start_xmit(struct sk_buff *skb,
u32 vlan_tag = 0;
mapping = ace_map_tx_skb(ap, skb, skb, idx);
+ if (dma_mapping_error(&ap->pdev->dev, mapping)) {
+ dev_kfree_skb(skb);
+ dev->stats.tx_dropped++;
+ return NETDEV_TX_OK;
+ }
flagsize = (skb->len << 16) | (BD_FLG_END);
if (skb->ip_summed == CHECKSUM_PARTIAL)
flagsize |= BD_FLG_TCP_UDP_SUM;
@@ -2438,6 +2443,11 @@ static netdev_tx_t ace_start_xmit(struct sk_buff *skb,
int i;
mapping = ace_map_tx_skb(ap, skb, NULL, idx);
+ if (dma_mapping_error(&ap->pdev->dev, mapping)) {
+ dev_kfree_skb(skb);
+ dev->stats.tx_dropped++;
+ return NETDEV_TX_OK;
+ }
flagsize = (skb_headlen(skb) << 16);
if (skb->ip_summed == CHECKSUM_PARTIAL)
flagsize |= BD_FLG_TCP_UDP_SUM;
@@ -2460,6 +2470,11 @@ static netdev_tx_t ace_start_xmit(struct sk_buff *skb,
mapping = skb_frag_dma_map(&ap->pdev->dev, frag, 0,
skb_frag_size(frag),
DMA_TO_DEVICE);
+ if (dma_mapping_error(&ap->pdev->dev, mapping)) {
+ dev_kfree_skb(skb);
+ dev->stats.tx_dropped++;
+ return NETDEV_TX_OK;
+ }
flagsize = skb_frag_size(frag) << 16;
if (skb->ip_summed == CHECKSUM_PARTIAL)
--
2.43.0
On Tue, Mar 31, 2026 at 09:48:41AM +0800, Wang Jun wrote:
> The ace_start_xmit function does not check the return value of
> dma_map_page (via ace_map_tx_skb) and skb_frag_dma_map when building
> transmit descriptors. If mapping fails, an invalid DMA address is
> written to the descriptor, which may cause hardware to access
> illegal memory, leading to system instability or crashes.
>
> Add proper dma_mapping_error() checks for all mapping calls. When
> mapping fails, free the skb, increment the dropped packet counter,
> and return NETDEV_TX_OK.
>
> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Is this fixing a bug you've seen in the wild? If not, I'd probably drop the
fixes tag and send this to net-next instead.
> Cc: stable@vger.kernel.org
> Signed-off-by: Wang Jun <1742789905@qq.com>
> ---
> drivers/net/ethernet/alteon/acenic.c | 15 +++++++++++++++
> 1 file changed, 15 insertions(+)
>
> diff --git a/drivers/net/ethernet/alteon/acenic.c b/drivers/net/ethernet/alteon/acenic.c
> index 455ee8930824..acabede53663 100644
> --- a/drivers/net/ethernet/alteon/acenic.c
> +++ b/drivers/net/ethernet/alteon/acenic.c
> @@ -2417,6 +2417,11 @@ static netdev_tx_t ace_start_xmit(struct sk_buff *skb,
> u32 vlan_tag = 0;
>
> mapping = ace_map_tx_skb(ap, skb, skb, idx);
> + if (dma_mapping_error(&ap->pdev->dev, mapping)) {
> + dev_kfree_skb(skb);
> + dev->stats.tx_dropped++;
> + return NETDEV_TX_OK;
> + }
> flagsize = (skb->len << 16) | (BD_FLG_END);
> if (skb->ip_summed == CHECKSUM_PARTIAL)
> flagsize |= BD_FLG_TCP_UDP_SUM;
> @@ -2438,6 +2443,11 @@ static netdev_tx_t ace_start_xmit(struct sk_buff *skb,
> int i;
>
> mapping = ace_map_tx_skb(ap, skb, NULL, idx);
> + if (dma_mapping_error(&ap->pdev->dev, mapping)) {
> + dev_kfree_skb(skb);
> + dev->stats.tx_dropped++;
> + return NETDEV_TX_OK;
> + }
I am not sure about this. The function ace_map_tx_skb seems to modify a
tx_ring_info entry, possibly writing invalid state to it if the dma_map_page
fails?
Maybe a better fix would be to refactor ace_map_tx_skb and do the
dma_mapping_error check there and change the return type of the function and
the code flow?
Then you wouldn't need to duplicate the error path handling code.
On Tue, 31 Mar 2026 16:43:22 -0700 Joe Damato wrote:
> On Tue, Mar 31, 2026 at 09:48:41AM +0800, Wang Jun wrote:
> > The ace_start_xmit function does not check the return value of
> > dma_map_page (via ace_map_tx_skb) and skb_frag_dma_map when building
> > transmit descriptors. If mapping fails, an invalid DMA address is
> > written to the descriptor, which may cause hardware to access
> > illegal memory, leading to system instability or crashes.
> >
> > Add proper dma_mapping_error() checks for all mapping calls. When
> > mapping fails, free the skb, increment the dropped packet counter,
> > and return NETDEV_TX_OK.
> >
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>
> Is this fixing a bug you've seen in the wild? If not, I'd probably drop the
> fixes tag and send this to net-next instead.
Either it's worth fixing in net or its not worth fixing at all.
My preference would be to try to delete this driver completely.
On 3/31/26 9:41 PM, Jakub Kicinski wrote:
> On Tue, 31 Mar 2026 16:43:22 -0700 Joe Damato wrote:
>> On Tue, Mar 31, 2026 at 09:48:41AM +0800, Wang Jun wrote:
>>> The ace_start_xmit function does not check the return value of
>>> dma_map_page (via ace_map_tx_skb) and skb_frag_dma_map when building
>>> transmit descriptors. If mapping fails, an invalid DMA address is
>>> written to the descriptor, which may cause hardware to access
>>> illegal memory, leading to system instability or crashes.
>>>
>>> Add proper dma_mapping_error() checks for all mapping calls. When
>>> mapping fails, free the skb, increment the dropped packet counter,
>>> and return NETDEV_TX_OK.
>>>
>>> Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
>>
>> Is this fixing a bug you've seen in the wild? If not, I'd probably drop the
>> fixes tag and send this to net-next instead.
>
> Either it's worth fixing in net or its not worth fixing at all.
>
> My preference would be to try to delete this driver completely.
The amount of hardware out there that is functional at this point must
be in the single digits.
© 2016 - 2026 Red Hat, Inc.