From: Eliav Farber <farbere@amazon.com>
To: <jesse.brandeburg@intel.com>, <anthony.l.nguyen@intel.com>,
<davem@davemloft.net>, <kuba@kernel.org>,
<vitaly.lifshits@intel.com>, <gregkh@linuxfoundation.org>,
<post@mikaelkw.online>, <intel-wired-lan@lists.osuosl.org>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: <farbere@amazon.com>, <jonnyc@amazon.com>
Subject: [Intel-wired-lan] [PATCH 5.10.y] e1000e: fix EEPROM length types for overflow checks
Date: Wed, 10 Sep 2025 17:31:38 +0000 [thread overview]
Message-ID: <20250910173138.8307-1-farbere@amazon.com> (raw)
Fix a compilation failure when warnings are treated as errors:
drivers/net/ethernet/intel/e1000e/ethtool.c: In function ‘e1000_set_eeprom’:
./include/linux/overflow.h:71:15: error: comparison of distinct pointer types lacks a cast [-Werror]
71 | (void) (&__a == __d); \
| ^~
drivers/net/ethernet/intel/e1000e/ethtool.c:582:6: note: in expansion of macro ‘check_add_overflow’
582 | if (check_add_overflow(eeprom->offset, eeprom->len, &total_len) ||
| ^~~~~~~~~~~~~~~~~~
To fix this, change total_len and max_len from size_t to u32 in
e1000_set_eeprom().
The check_add_overflow() helper requires that the first two operands
and the pointer to the result (third operand) all have the same type.
On 64-bit builds, using size_t caused a mismatch with the u32 fields
eeprom->offset and eeprom->len, leading to type check failures.
Fixes: ce8829d3d44b ("e1000e: fix heap overflow in e1000_set_eeprom")
Signed-off-by: Eliav Farber <farbere@amazon.com>
---
drivers/net/ethernet/intel/e1000e/ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c b/drivers/net/ethernet/intel/e1000e/ethtool.c
index 4aca854783e2..584378291f3f 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -559,7 +559,7 @@ static int e1000_set_eeprom(struct net_device *netdev,
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
- size_t total_len, max_len;
+ u32 total_len, max_len;
u16 *eeprom_buff;
int ret_val = 0;
int first_word;
--
2.47.3
WARNING: multiple messages have this Message-ID (diff)
From: Eliav Farber <farbere@amazon.com>
To: <jesse.brandeburg@intel.com>, <anthony.l.nguyen@intel.com>,
<davem@davemloft.net>, <kuba@kernel.org>,
<vitaly.lifshits@intel.com>, <gregkh@linuxfoundation.org>,
<post@mikaelkw.online>, <intel-wired-lan@lists.osuosl.org>,
<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: <farbere@amazon.com>, <jonnyc@amazon.com>
Subject: [PATCH 5.10.y] e1000e: fix EEPROM length types for overflow checks
Date: Wed, 10 Sep 2025 17:31:38 +0000 [thread overview]
Message-ID: <20250910173138.8307-1-farbere@amazon.com> (raw)
Fix a compilation failure when warnings are treated as errors:
drivers/net/ethernet/intel/e1000e/ethtool.c: In function ‘e1000_set_eeprom’:
./include/linux/overflow.h:71:15: error: comparison of distinct pointer types lacks a cast [-Werror]
71 | (void) (&__a == __d); \
| ^~
drivers/net/ethernet/intel/e1000e/ethtool.c:582:6: note: in expansion of macro ‘check_add_overflow’
582 | if (check_add_overflow(eeprom->offset, eeprom->len, &total_len) ||
| ^~~~~~~~~~~~~~~~~~
To fix this, change total_len and max_len from size_t to u32 in
e1000_set_eeprom().
The check_add_overflow() helper requires that the first two operands
and the pointer to the result (third operand) all have the same type.
On 64-bit builds, using size_t caused a mismatch with the u32 fields
eeprom->offset and eeprom->len, leading to type check failures.
Fixes: ce8829d3d44b ("e1000e: fix heap overflow in e1000_set_eeprom")
Signed-off-by: Eliav Farber <farbere@amazon.com>
---
drivers/net/ethernet/intel/e1000e/ethtool.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/intel/e1000e/ethtool.c b/drivers/net/ethernet/intel/e1000e/ethtool.c
index 4aca854783e2..584378291f3f 100644
--- a/drivers/net/ethernet/intel/e1000e/ethtool.c
+++ b/drivers/net/ethernet/intel/e1000e/ethtool.c
@@ -559,7 +559,7 @@ static int e1000_set_eeprom(struct net_device *netdev,
{
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = &adapter->hw;
- size_t total_len, max_len;
+ u32 total_len, max_len;
u16 *eeprom_buff;
int ret_val = 0;
int first_word;
--
2.47.3
next reply other threads:[~2025-09-10 17:48 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 17:31 Eliav Farber [this message]
2025-09-10 17:31 ` [PATCH 5.10.y] e1000e: fix EEPROM length types for overflow checks Eliav Farber
2025-09-11 5:53 ` [Intel-wired-lan] " Greg KH
2025-09-11 5:53 ` Greg KH
2025-09-11 6:13 ` [Intel-wired-lan] " Farber, Eliav
2025-09-11 6:13 ` Farber, Eliav
2025-09-11 6:27 ` [Intel-wired-lan] " Loktionov, Aleksandr
2025-09-11 6:27 ` Loktionov, Aleksandr
2025-09-11 8:37 ` [Intel-wired-lan] " Greg KH
2025-09-11 8:37 ` Greg KH
2025-09-12 13:07 ` [Intel-wired-lan] " Farber, Eliav
2025-09-12 13:07 ` Farber, Eliav
2025-09-12 13:41 ` [Intel-wired-lan] " Greg KH
2025-09-12 13:41 ` Greg KH
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=20250910173138.8307-1-farbere@amazon.com \
--to=farbere@amazon.com \
--cc=anthony.l.nguyen@intel.com \
--cc=davem@davemloft.net \
--cc=gregkh@linuxfoundation.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=jesse.brandeburg@intel.com \
--cc=jonnyc@amazon.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=post@mikaelkw.online \
--cc=vitaly.lifshits@intel.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.