All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Loic Poulain" <loic.poulain@oss.qualcomm.com>
Cc: robh@kernel.org, devicetree@vger.kernel.org, conor+dt@kernel.org
Subject: Re: [PATCH v6 6/9] net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup
Date: Tue, 30 Jun 2026 08:56:01 +0000	[thread overview]
Message-ID: <20260630085601.77AB31F00A3A@smtp.kernel.org> (raw)
In-Reply-To: <20260629-block-as-nvmem-v6-6-f02513dcd46d@oss.qualcomm.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Replacing memcpy() with ether_addr_copy() imposes an unsafe 16-bit alignment requirement on the caller-provided addr buffer, which can trigger unaligned access faults (kernel panics) on strict-alignment architectures.
--

commit a4898c618dc4fdc91885d4184cdfd51af73fa946
Author: Loic Poulain <loic.poulain@oss.qualcomm.com>

net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup

This commit factors out the common NVMEM EUI-48 retrieval logic from
of_get_mac_address_nvmem() into a new helper. The original function
is updated to call the new helper, preserving the lookup behavior.

> diff --git a/net/core/of_net.c b/net/core/of_net.c
> --- a/net/core/of_net.c
> +++ b/net/core/of_net.c
[ ... ]
> @@ -75,27 +73,54 @@ int of_get_mac_address_nvmem(struct device_node *np, u8 *addr)
[ ... ]
> -	memcpy(addr, mac, ETH_ALEN);
> -	kfree(mac);
> +	ret = of_get_nvmem_eui48(np, "mac-address", mac);
> +	if (ret)
> +		return ret;
> +
> +	if (!is_valid_ether_addr(mac))
> +		return -EINVAL;
> +
> +	ether_addr_copy(addr, mac);
> +	return 0;
>  }

[Severity: High]
Will the use of ether_addr_copy() here cause an unaligned access fault on
strict-alignment architectures?

The original code used memcpy(), which handles unaligned destination pointers
safely. The ether_addr_copy() function requires both source and destination
pointers to be 16-bit aligned.

While the local mac buffer is explicitly aligned to 16 bits in this patch,
the destination addr buffer is provided by the caller. Callers like
of_get_ethdev_address() often allocate a 1-byte aligned array on the stack:

of_get_ethdev_address() {
        u8 addr[ETH_ALEN];
        
        ret = of_get_mac_address(np, addr);
        ...
}

Could this lead to kernel panics during device probe when the stack-allocated
addr buffer happens to be unaligned?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260629-block-as-nvmem-v6-0-f02513dcd46d@oss.qualcomm.com?part=6

  reply	other threads:[~2026-06-30  8:56 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-29  8:55 [PATCH v6 0/9] Support for block device NVMEM providers Loic Poulain
2026-06-29  8:55 ` [PATCH v6 1/9] block: partitions: of: Skip child nodes without reg property Loic Poulain
2026-06-29 12:30   ` Support for block device NVMEM providers bluez.test.bot
2026-06-30  8:56   ` [PATCH v6 1/9] block: partitions: of: Skip child nodes without reg property sashiko-bot
2026-06-30 18:02   ` Rob Herring
2026-06-30 19:59     ` Loic Poulain
2026-06-30 21:45       ` Rob Herring
2026-07-01 13:35         ` Loic Poulain
2026-06-29  8:55 ` [PATCH v6 2/9] dt-bindings: mmc: Document support for nvmem-layout Loic Poulain
2026-06-29  8:55 ` [PATCH v6 3/9] dt-bindings: net: wireless: qcom,ath10k: Document NVMEM cells Loic Poulain
2026-06-29  8:55 ` [PATCH v6 4/9] dt-bindings: bluetooth: qcom: Add NVMEM BD address cell Loic Poulain
2026-06-29  8:55 ` [PATCH v6 5/9] block: implement NVMEM provider Loic Poulain
2026-06-30  7:59   ` Bartosz Golaszewski
2026-06-29  8:55 ` [PATCH v6 6/9] net: of_net: Add of_get_nvmem_eui48() helper for EUI-48 lookup Loic Poulain
2026-06-30  8:56   ` sashiko-bot [this message]
2026-06-29  8:55 ` [PATCH v6 7/9] Bluetooth: hci_sync: Add NVMEM-backed BD address retrieval Loic Poulain
2026-06-29  9:23   ` Kwapulinski, Piotr
2026-06-29  8:55 ` [PATCH v6 8/9] Bluetooth: qca: Set NVMEM BD address quirks when address is invalid Loic Poulain
2026-06-29  8:55 ` [PATCH v6 9/9] arm64: dts: qcom: arduino-imola: Describe NVMEM layout for WiFi/BT addresses Loic Poulain

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=20260630085601.77AB31F00A3A@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=loic.poulain@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    /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.