All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jacob Keller <jacob.e.keller@intel.com>
To: Paul Menzel <pmenzel@molgen.mpg.de>,
	Intel Wired LAN <intel-wired-lan@lists.osuosl.org>
Cc: Paul Greenwalt <paul.greenwalt@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2] ice: avoid infinite loop if NVM has invalid TLV length
Date: Fri, 17 May 2024 16:10:43 -0700	[thread overview]
Message-ID: <7d2e453f-8679-4dc0-9798-e13bfbc93ea1@intel.com> (raw)
In-Reply-To: <20240517-iwl-net-2024-05-16-fix-nvm-tlv-issue-v2-1-fdee184ece86@intel.com>



On 5/17/2024 4:08 PM, Jacob Keller wrote:
> The ice_get_pfa_module_tlv() function iterates over the TLVs in the
> Preserved Fields Area (PFA) of the NVM. This is used to access data such as
> the Part Board Assembly identifier.
> 
> Some NVMs in the wild have been found with incorrect TLV lengths including
> at least one which reports a TLV length of 0xFFFF. When trying to read the
> PBA from such an NVM, the driver will compute a new offset for the next_tlv
> which is lower, due to overflowing the 16-bit next_tlv variable.
> 
> In the best case, the driver will incorrectly interpret values until it
> finds one which has an offset greater than the PFA area without
> overflowing. In the worst case, the values in the NVM result in an infinite
> loop as the misinterpreted lengths result in checking offsets which are
> valid within the PFA, and which ultimately point in an infinite loop.
> 
> Fix this by using check_add_overflow when calculating the NVM offsets, and
> bailing if we ever overflow. Additionally, use check_add_overflow when
> calculating the initial maximum PFA size.
> 
> This ensures that we bail immediately on encountering any TLV who's length
> would have caused the naive addition to overflow, rather than entering an
> infinite loop or otherwise misinterpreting NVM values.
> 
> Co-developed-by: Paul Greenwalt <paul.greenwalt@intel.com>
> Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com>
> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com>

Fixes: e961b679fb0b ("ice: add board identifier info to devlink .info_get")

I'll ensure this gets added to the commit when queuing, as I forgot to
add it when re-writing this commit message.

  reply	other threads:[~2024-05-17 23:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-05-17 23:08 [Intel-wired-lan] [PATCH iwl-net v2] ice: avoid infinite loop if NVM has invalid TLV length Jacob Keller
2024-05-17 23:10 ` Jacob Keller [this message]
2024-05-17 23:18 ` Jacob Keller

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=7d2e453f-8679-4dc0-9798-e13bfbc93ea1@intel.com \
    --to=jacob.e.keller@intel.com \
    --cc=intel-wired-lan@lists.osuosl.org \
    --cc=paul.greenwalt@intel.com \
    --cc=pmenzel@molgen.mpg.de \
    /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.