<?xml version='1.0' encoding='UTF-8'?>
<?xml-stylesheet href="/static/style.xsl" type="text/xsl"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
  <id>https://vulnerability.circl.lu/rss/recent/all/10</id>
  <title>Most recent entries from all</title>
  <updated>2026-09-29T22:05:50.832074+00:00</updated>
  <author>
    <name>Vulnerability-Lookup</name>
    <email>info@circl.lu</email>
  </author>
  <link href="https://vulnerability.circl.lu" rel="alternate"/>
  <generator uri="https://lkiesow.github.io/python-feedgen" version="1.0.0">python-feedgen</generator>
  <subtitle>Contains only the most 10 recent entries.</subtitle>
  <entry>
    <id>https://vulnerability.circl.lu/vuln/cve-2026-90100</id>
    <title>CVE-2026-90100 — ptp: netc: fix period truncation and potential divide-by-zero in PEROUT</title>
    <updated>2026-09-29T22:05:51.072597+00:00</updated>
    <content type="xhtml">
      <div xmlns="http://www.w3.org/1999/xhtml"><p><strong>Affected:</strong> Linux</p>
<p>In the Linux kernel, the following vulnerability has been resolved:</p>
<p>ptp: netc: fix period truncation and potential divide-by-zero in PEROUT</p>
<p>The max_period bound in net_timer_enable_perout() was computed as:</p>
<p>max_period = (u64)NETC_TMR_DEFAULT_FIPER + integral_period;</p>
<p>which exceeds U32_MAX when integral_period &gt; 0 (e.g. 0x100000002 for
the default 333333333 Hz clock). A period_ns that passes this check but
exceeds U32_MAX is then silently truncated when stored into the u32
struct netc_pp::period field.</p>
<p>A truncated value of zero can reach netc_timer_set_perout_alarm(), where
the local u32 period variable would also be 0, causing a divide-by-zero
in roundup_u64(delta, period) whenever the stime &lt; min_time branch is
taken (which always happens for a start time of {0, 0}).</p>
<p>Additionally, netc_timer_enable_periodic_pulse() and
netc_timer_enable_fiper() both compute:</p>
<p>fiper = pp-&gt;period - integral_period;</p>
<p>A zero pp-&gt;period results in an unsigned wraparound to 0xFFFFFFFD,
mis-programming the FIPER hardware register.</p>
<p>Fix all three issues by capping max_period at NETC_TMR_DEFAULT_FIPER
(0xFFFFFFFF). This ensures that any period_ns passing the range check
fits in a u32 without truncation, so the stored value is always valid
and non-zero. The accepted range is reduced by integral_period ns
(typically only a few nanoseconds), which is negligible in practice.</p></div>
    </content>
    <link href="https://vulnerability.circl.lu/vuln/cve-2026-90100"/>
  </entry>
</feed>
