<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/drivers/net/ethernet/freescale, branch linux-6.18.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.</subtitle>
<id>https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.18.y</id>
<link rel='self' href='https://universe.0xinfinity.dev/distro/kernel/atom?h=linux-6.18.y'/>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/'/>
<updated>2026-03-12T11:10:02Z</updated>
<entry>
<title>net: enetc: use truesize as XDP RxQ info frag_size</title>
<updated>2026-03-12T11:10:02Z</updated>
<author>
<name>Larysa Zaremba</name>
<email>larysa.zaremba@intel.com</email>
</author>
<published>2026-03-05T11:12:49Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=45a41aecf5e541ec4d195ab61ec774ab45b90004'/>
<id>urn:sha1:45a41aecf5e541ec4d195ab61ec774ab45b90004</id>
<content type='text'>
[ Upstream commit f8e18abf183dbd636a8725532c7f5aa58957de84 ]

The only user of frag_size field in XDP RxQ info is
bpf_xdp_frags_increase_tail(). It clearly expects truesize instead of DMA
write size. Different assumptions in enetc driver configuration lead to
negative tailroom.

Set frag_size to the same value as frame_sz.

Fixes: 2768b2e2f7d2 ("net: enetc: register XDP RX queues with frag_size")
Reviewed-by: Aleksandr Loktionov &lt;aleksandr.loktionov@intel.com&gt;
Reviewed-by: Vladimir Oltean &lt;vladimir.oltean@nxp.com&gt;
Signed-off-by: Larysa Zaremba &lt;larysa.zaremba@intel.com&gt;
Link: https://patch.msgid.link/20260305111253.2317394-9-larysa.zaremba@intel.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dpaa2-switch: Fix interrupt storm after receiving bad if_id in IRQ handler</title>
<updated>2026-03-12T11:09:51Z</updated>
<author>
<name>Guenter Roeck</name>
<email>linux@roeck-us.net</email>
</author>
<published>2026-02-27T05:58:12Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=00f42ace446f1e4bf84988f2281131f52cd32796'/>
<id>urn:sha1:00f42ace446f1e4bf84988f2281131f52cd32796</id>
<content type='text'>
[ Upstream commit 74badb9c20b1a9c02a95c735c6d3cd6121679c93 ]

Commit 31a7a0bbeb00 ("dpaa2-switch: add bounds check for if_id in IRQ
handler") introduces a range check for if_id to avoid an out-of-bounds
access. If an out-of-bounds if_id is detected, the interrupt status is
not cleared. This may result in an interrupt storm.

Clear the interrupt status after detecting an out-of-bounds if_id to avoid
the problem.

Found by an experimental AI code review agent at Google.

Fixes: 31a7a0bbeb00 ("dpaa2-switch: add bounds check for if_id in IRQ handler")
Cc: Junrui Luo &lt;moonafterrain@outlook.com&gt;
Signed-off-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Reviewed-by: Ioana Ciornei &lt;ioana.ciornei@nxp.com&gt;
Link: https://patch.msgid.link/20260227055812.1777915-1-linux@roeck-us.net
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dpaa2-switch: validate num_ifs to prevent out-of-bounds write</title>
<updated>2026-03-04T12:20:52Z</updated>
<author>
<name>Junrui Luo</name>
<email>moonafterrain@outlook.com</email>
</author>
<published>2026-02-24T11:05:56Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=89764cf44544e943230f5e03b8c40a90da26537c'/>
<id>urn:sha1:89764cf44544e943230f5e03b8c40a90da26537c</id>
<content type='text'>
[ Upstream commit 8a5752c6dcc085a3bfc78589925182e4e98468c5 ]

The driver obtains sw_attr.num_ifs from firmware via dpsw_get_attributes()
but never validates it against DPSW_MAX_IF (64). This value controls
iteration in dpaa2_switch_fdb_get_flood_cfg(), which writes port indices
into the fixed-size cfg-&gt;if_id[DPSW_MAX_IF] array. When firmware reports
num_ifs &gt;= 64, the loop can write past the array bounds.

Add a bound check for num_ifs in dpaa2_switch_init().

dpaa2_switch_fdb_get_flood_cfg() appends the control interface (port
num_ifs) after all matched ports. When num_ifs == DPSW_MAX_IF and all
ports match the flood filter, the loop fills all 64 slots and the control
interface write overflows by one entry.

The check uses &gt;= because num_ifs == DPSW_MAX_IF is also functionally
broken.

build_if_id_bitmap() silently drops any ID &gt;= 64:
      if (id[i] &lt; DPSW_MAX_IF)
          bmap[id[i] / 64] |= ...

Fixes: 539dda3c5d19 ("staging: dpaa2-switch: properly setup switching domains")
Signed-off-by: Junrui Luo &lt;moonafterrain@outlook.com&gt;
Reviewed-by: Ioana Ciornei &lt;ioana.ciornei@nxp.com&gt;
Link: https://patch.msgid.link/SYBPR01MB78812B47B7F0470B617C408AAF74A@SYBPR01MB7881.ausprd01.prod.outlook.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: enetc: Convert 16-bit register reads to 32-bit for ENETC v4</title>
<updated>2026-02-11T12:41:57Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@nxp.com</email>
</author>
<published>2026-01-30T14:10:35Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=5a2b4b0e9c00388d49e200620f1f1614a6dceb49'/>
<id>urn:sha1:5a2b4b0e9c00388d49e200620f1f1614a6dceb49</id>
<content type='text'>
[ Upstream commit c28d765ec5da160d3a48d0928528084cef97bf19 ]

It is not recommended to access the 32‑bit registers of this hardware IP
using lower‑width accessors (i.e. 16‑bit), and the only exception to
this rule was introduced in the initial ENETC v1 driver for the PMAR1
register, which holds the lower 16 bits of the primary MAC address of
an SI. Meanwhile, this exception has been replicated in the v4 driver
code as well.

Since LS1028 (the only SoC with ENETC v1) is not affected by this issue,
the current patch converts the 16‑bit reads from PMAR1 starting with
ENETC v4.

Fixes: 99100d0d9922 ("net: enetc: add preliminary support for i.MX95 ENETC PF")
Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@nxp.com&gt;
Reviewed-by: Wei Fang &lt;wei.fang@nxp.com&gt;
Link: https://patch.msgid.link/20260130141035.272471-5-claudiu.manoil@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: enetc: Convert 16-bit register writes to 32-bit for ENETC v4</title>
<updated>2026-02-11T12:41:57Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@nxp.com</email>
</author>
<published>2026-01-30T14:10:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=566ea5769ec276e96462722e17ffc4467a61b34e'/>
<id>urn:sha1:566ea5769ec276e96462722e17ffc4467a61b34e</id>
<content type='text'>
[ Upstream commit 21d0fc95b5920ae8e69a2c0394bef82b8392bcc9 ]

For ENETC v4, which is integrated into more complex SoCs (compared to v1),
16‑bit register writes are blocked in the SoC interconnect on some chips.

To be fair, it is not recommended to access 32‑bit registers of this IP
using lower‑width accessors (i.e. 16‑bit), and the only exception to
this rule was introduced by me in the initial ENETC v1 driver for the
PMAR1 register, which holds the lower 16 bits of the primary MAC address
of an SI. Meanwhile, this exception has been replicated for v4 as well.

Since LS1028 (the only SoC with ENETC v1) is not affected by this issue,
the current patch fixes the 16‑bit writes to PMAR1 starting with ENETC
v4.

Fixes: 99100d0d9922 ("net: enetc: add preliminary support for i.MX95 ENETC PF")
Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@nxp.com&gt;
Reviewed-by: Wei Fang &lt;wei.fang@nxp.com&gt;
Link: https://patch.msgid.link/20260130141035.272471-4-claudiu.manoil@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: enetc: Remove CBDR cacheability AXI settings for ENETC v4</title>
<updated>2026-02-11T12:41:57Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@nxp.com</email>
</author>
<published>2026-01-30T14:10:33Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=f346253e5fd95bda6a94486bb84ae8a4c0b4c150'/>
<id>urn:sha1:f346253e5fd95bda6a94486bb84ae8a4c0b4c150</id>
<content type='text'>
[ Upstream commit 9ae13b2e64fcd2ca00a76b7d60fc4641a6b9209d ]

For ENETC v4 these settings are controlled by the global ENETC
command cache attribute registers (EnCAR), from the IERB register
block.

The hardcoded CDBR cacheability settings were inherited from LS1028A,
and should be removed from the ENETC v4 driver as they conflict
with the global IERB settings.

Fixes: e3f4a0a8ddb4 ("net: enetc: add command BD ring support for i.MX95 ENETC")
Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@nxp.com&gt;
Reviewed-by: Wei Fang &lt;wei.fang@nxp.com&gt;
Link: https://patch.msgid.link/20260130141035.272471-3-claudiu.manoil@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: enetc: Remove SI/BDR cacheability AXI settings for ENETC v4</title>
<updated>2026-02-11T12:41:57Z</updated>
<author>
<name>Claudiu Manoil</name>
<email>claudiu.manoil@nxp.com</email>
</author>
<published>2026-01-30T14:10:32Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=d98745c68023f8a45a4f5d7299b83994ee96213c'/>
<id>urn:sha1:d98745c68023f8a45a4f5d7299b83994ee96213c</id>
<content type='text'>
[ Upstream commit a69c17230cab07bd156f894fdc82bd78b43ea72f ]

For ENETC v4 these settings are controlled by the global ENETC
message and buffer cache attribute registers (EnBCAR and EnMCAR),
from the IERB register block.

The hardcoded cacheability settings were inherited from LS1028A,
and should be removed from the ENETC v4 driver as they conflict
with the global IERB settings.

Fixes: 99100d0d9922 ("net: enetc: add preliminary support for i.MX95 ENETC PF")
Signed-off-by: Claudiu Manoil &lt;claudiu.manoil@nxp.com&gt;
Reviewed-by: Wei Fang &lt;wei.fang@nxp.com&gt;
Link: https://patch.msgid.link/20260130141035.272471-2-claudiu.manoil@nxp.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dpaa2-switch: add bounds check for if_id in IRQ handler</title>
<updated>2026-02-11T12:41:55Z</updated>
<author>
<name>Junrui Luo</name>
<email>moonafterrain@outlook.com</email>
</author>
<published>2026-01-28T16:55:13Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=1b381a638e1851d8cfdfe08ed9cdbec5295b18c9'/>
<id>urn:sha1:1b381a638e1851d8cfdfe08ed9cdbec5295b18c9</id>
<content type='text'>
[ Upstream commit 31a7a0bbeb006bac2d9c81a2874825025214b6d8 ]

The IRQ handler extracts if_id from the upper 16 bits of the hardware
status register and uses it to index into ethsw-&gt;ports[] without
validation. Since if_id can be any 16-bit value (0-65535) but the ports
array is only allocated with sw_attr.num_ifs elements, this can lead to
an out-of-bounds read potentially.

Add a bounds check before accessing the array, consistent with the
existing validation in dpaa2_switch_rx().

Reported-by: Yuhao Jiang &lt;danisjiang@gmail.com&gt;
Reported-by: Junrui Luo &lt;moonafterrain@outlook.com&gt;
Fixes: 24ab724f8a46 ("dpaa2-switch: use the port index in the IRQ handler")
Signed-off-by: Junrui Luo &lt;moonafterrain@outlook.com&gt;
Link: https://patch.msgid.link/SYBPR01MB7881D420AB43FF1A227B84AFAF91A@SYBPR01MB7881.ausprd01.prod.outlook.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>dpaa2-switch: prevent ZERO_SIZE_PTR dereference when num_ifs is zero</title>
<updated>2026-02-11T12:41:55Z</updated>
<author>
<name>Junrui Luo</name>
<email>moonafterrain@outlook.com</email>
</author>
<published>2026-01-28T08:07:34Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=155eb99aff2920153bf21217ae29565fff81e6af'/>
<id>urn:sha1:155eb99aff2920153bf21217ae29565fff81e6af</id>
<content type='text'>
[ Upstream commit ed48a84a72fefb20a82dd90a7caa7807e90c6f66 ]

The driver allocates arrays for ports, FDBs, and filter blocks using
kcalloc() with ethsw-&gt;sw_attr.num_ifs as the element count. When the
device reports zero interfaces (either due to hardware configuration
or firmware issues), kcalloc(0, ...) returns ZERO_SIZE_PTR (0x10)
instead of NULL.

Later in dpaa2_switch_probe(), the NAPI initialization unconditionally
accesses ethsw-&gt;ports[0]-&gt;netdev, which attempts to dereference
ZERO_SIZE_PTR (address 0x10), resulting in a kernel panic.

Add a check to ensure num_ifs is greater than zero after retrieving
device attributes. This prevents the zero-sized allocations and
subsequent invalid pointer dereference.

Reported-by: Yuhao Jiang &lt;danisjiang@gmail.com&gt;
Reported-by: Junrui Luo &lt;moonafterrain@outlook.com&gt;
Fixes: 0b1b71370458 ("staging: dpaa2-switch: handle Rx path on control interface")
Signed-off-by: Junrui Luo &lt;moonafterrain@outlook.com&gt;
Reviewed-by: Andrew Lunn &lt;andrew@lunn.ch&gt;
Link: https://patch.msgid.link/SYBPR01MB7881BEABA8DA896947962470AF91A@SYBPR01MB7881.ausprd01.prod.outlook.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>net: fec: account for VLAN header in frame length calculations</title>
<updated>2026-01-30T09:32:26Z</updated>
<author>
<name>Clemens Gruber</name>
<email>mail@clemensgruber.at</email>
</author>
<published>2026-01-21T08:37:51Z</published>
<link rel='alternate' type='text/html' href='https://universe.0xinfinity.dev/distro/kernel/commit/?id=326470b33c28ac1f4a4795f4c73eac3ba74b14ea'/>
<id>urn:sha1:326470b33c28ac1f4a4795f4c73eac3ba74b14ea</id>
<content type='text'>
commit ca1bb3fedf26a08ed31974131bc0064d4fe33649 upstream.

The MAX_FL (maximum frame length) and related calculations used ETH_HLEN,
which does not account for the 4-byte VLAN tag in tagged frames. This
caused the hardware to reject valid VLAN frames as oversized, resulting
in RX errors and dropped packets.

Use VLAN_ETH_HLEN instead of ETH_HLEN in the MAX_FL register setup,
cut-through mode threshold, buffer allocation, and max_mtu calculation.

Cc: stable@kernel.org # v6.18+
Fixes: 62b5bb7be7bc ("net: fec: update MAX_FL based on the current MTU")
Fixes: d466c16026e9 ("net: fec: enable the Jumbo frame support for i.MX8QM")
Fixes: 59e9bf037d75 ("net: fec: add change_mtu to support dynamic buffer allocation")
Fixes: ec2a1681ed4f ("net: fec: use a member variable for maximum buffer size")
Signed-off-by: Clemens Gruber &lt;mail@clemensgruber.at&gt;
Reviewed-by: Wei Fang &lt;wei.fang@nxp.com&gt;
Link: https://patch.msgid.link/20260121083751.66997-1-mail@clemensgruber.at
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
