<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel/linux.git/drivers/net, branch v6.18.36</title>
<subtitle>Linux kernel stable tree (mirror)</subtitle>
<id>https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36</id>
<link rel='self' href='https://git.radix-linux.su/kernel/linux.git/atom?h=v6.18.36'/>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/'/>
<updated>2026-06-19T11:44:11+00:00</updated>
<entry>
<title>rtase: Reset TX subqueue when clearing TX ring</title>
<updated>2026-06-19T11:44:11+00:00</updated>
<author>
<name>Justin Lai</name>
<email>justinlai0215@realtek.com</email>
</author>
<published>2026-06-02T11:46:59+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=1bf84f4013fac894dd058f84cc534f8ad461e003'/>
<id>urn:sha1:1bf84f4013fac894dd058f84cc534f8ad461e003</id>
<content type='text'>
commit ab1ecaabe74b7d86c38ab2ab44bd56cdcc33645a upstream.

rtase_tx_clear() clears the TX ring and resets the ring indexes.
However, the TX queue state and BQL accounting are not reset at
the same time.

This may leave __QUEUE_STATE_STACK_XOFF asserted after
rtase_sw_reset(), preventing new TX packets from being scheduled.

Reset the TX subqueue when clearing the TX ring so the TX queue
state and BQL accounting are restored together.

Fixes: 5a2a2f15244c ("rtase: Implement the rtase_down function")
Cc: stable@vger.kernel.org
Signed-off-by: Justin Lai &lt;justinlai0215@realtek.com&gt;
Reviewed-by: Alexander Lobakin &lt;aleksander.lobakin@intel.com&gt;
Link: https://patch.msgid.link/20260602114659.12335-1-justinlai0215@realtek.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>rtase: Avoid sleeping in get_stats64()</title>
<updated>2026-06-19T11:44:11+00:00</updated>
<author>
<name>Justin Lai</name>
<email>justinlai0215@realtek.com</email>
</author>
<published>2026-06-03T06:18:16+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=54f9cdcd731181dc402770373dee2810f42dfd82'/>
<id>urn:sha1:54f9cdcd731181dc402770373dee2810f42dfd82</id>
<content type='text'>
commit 9fc237f8d49f06d05f0f8e80361047b718894e81 upstream.

The .ndo_get_stats64 callback must not sleep because it can be
called when reading /proc/net/dev.

rtase_get_stats64() calls rtase_dump_tally_counter(), which polls
the tally counter dump bit with read_poll_timeout(). This may
sleep while waiting for the hardware counter dump to complete.

Use read_poll_timeout_atomic() instead to avoid sleeping in the
get_stats64() path.

Fixes: 079600489960 ("rtase: Implement net_device_ops")
Cc: stable@vger.kernel.org
Signed-off-by: Justin Lai &lt;justinlai0215@realtek.com&gt;
Link: https://patch.msgid.link/20260603061816.31356-1-justinlai0215@realtek.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>octeontx2-af: fix memory leak in rvu_setup_hw_resources()</title>
<updated>2026-06-19T11:44:10+00:00</updated>
<author>
<name>Dawei Feng</name>
<email>dawei.feng@seu.edu.cn</email>
</author>
<published>2026-06-04T14:37:56+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e646b86b3b4809d6af5addc53b6fec692332104c'/>
<id>urn:sha1:e646b86b3b4809d6af5addc53b6fec692332104c</id>
<content type='text'>
commit 09a5bf856aa759513afc4afd233d15bcc711b84e upstream.

If rvu_npc_exact_init() fails in rvu_setup_hw_resources(), the function
returns directly instead of jumping to the error handling path. This
causes a resource leak for the previously initialized CGX, NPC, fwdata,
and MSI-X states.

Fix this by replacing the direct return with goto cgx_err to ensure
proper cleanup.

The bug was first flagged by an experimental analysis tool we are
developing for kernel memory-management bugs while analyzing
v6.13-rc1. The tool is still under development and is not yet publicly
available. Manual inspection confirms that the bug is still present in
v7.1-rc6.

An x86_64 allyesconfig build showed no new warnings. As we do not have
access to Marvell OcteonTX2 RVU AF hardware to test with, no runtime
testing was able to be performed.

Fixes: 3571fe07a090 ("octeontx2-af: Drop rules for NPC MCAM")
Cc: stable@vger.kernel.org
Signed-off-by: Dawei Feng &lt;dawei.feng@seu.edu.cn&gt;
Signed-off-by: Zilin Guan &lt;zilin@seu.edu.cn&gt;
Link: https://patch.msgid.link/20260604143756.1524482-1-dawei.feng@seu.edu.cn
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: sfp: initialize i2c_block_size at adapter configure time</title>
<updated>2026-06-19T11:44:09+00:00</updated>
<author>
<name>Jonas Jelonek</name>
<email>jelonek.jonas@gmail.com</email>
</author>
<published>2026-05-28T20:52:40+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bef389a210e7dc96073c813fab3a03a5136f8b13'/>
<id>urn:sha1:bef389a210e7dc96073c813fab3a03a5136f8b13</id>
<content type='text'>
commit 56d0885514491e5ed8f7593400879ab77c52504c upstream.

sfp-&gt;i2c_block_size is only assigned in sfp_sm_mod_probe(), which runs
from the state machine timer after SFP_F_PRESENT has been set. Between
those two points, sfp_module_eeprom() (the ethtool -m callback) gates
only on SFP_F_PRESENT and can be entered with i2c_block_size still at
its kzalloc'd value of 0.

On a pure-I2C adapter, sfp_i2c_read() then issues an i2c_transfer()
with msgs[1].len = 0 inside a loop that subtracts this_len from len
each iteration; on adapters that succeed a zero-length read the loop
never advances, spinning while holding rtnl_lock.

This was previously addressed by initializing i2c_block_size in
sfp_alloc() (commit 813c2dd78618), but the initialization was dropped
when i2c_block_size was split from i2c_max_block_size.

Initialize sfp-&gt;i2c_block_size from sfp-&gt;i2c_max_block_size in
sfp_i2c_configure(), so the field is valid as soon as the adapter is
known. sfp_sm_mod_probe() still reassigns it on each module insertion
to recover from a per-module clamp to 1 (sfp_id_needs_byte_io).

Fixes: 7662abf4db94 ("net: phy: sfp: Add support for SMBus module access")
Cc: stable@vger.kernel.org
Signed-off-by: Jonas Jelonek &lt;jelonek.jonas@gmail.com&gt;
Link: https://patch.msgid.link/20260528205242.971410-2-jelonek.jonas@gmail.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: mv643xx: fix OF node refcount</title>
<updated>2026-06-19T11:44:09+00:00</updated>
<author>
<name>Bartosz Golaszewski</name>
<email>bartosz.golaszewski@oss.qualcomm.com</email>
</author>
<published>2026-06-02T07:34:14+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=4a73cacb55863ca480d8ddda752d3944ad75bbbb'/>
<id>urn:sha1:4a73cacb55863ca480d8ddda752d3944ad75bbbb</id>
<content type='text'>
commit 4aacf509e537a711fa71bca9f234e5eb6968850e upstream.

Platform devices created with platform_device_alloc() call
platform_device_release() when the last reference to the device's
kobject is dropped. This function calls of_node_put() unconditionally.
This works fine for devices created with platform_device_register_full()
but users of the split approach (platform_device_alloc() +
platform_device_add()) must bump the reference of the of_node they
assign manually. Add the missing call to of_node_get().

Cc: stable@vger.kernel.org
Fixes: 76723bca2802 ("net: mv643xx_eth: add DT parsing support")
Signed-off-by: Bartosz Golaszewski &lt;bartosz.golaszewski@oss.qualcomm.com&gt;
Link: https://patch.msgid.link/20260602073414.22500-1-bartosz.golaszewski@oss.qualcomm.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: bonding: fix NULL pointer dereference in bond_do_ioctl()</title>
<updated>2026-06-19T11:44:09+00:00</updated>
<author>
<name>ZhaoJinming</name>
<email>zhaojinming@uniontech.com</email>
</author>
<published>2026-06-01T08:56:49+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=bcb8fad90f27300add583a8371db504b766d95c7'/>
<id>urn:sha1:bcb8fad90f27300add583a8371db504b766d95c7</id>
<content type='text'>
commit a764b0e8317a863006e05732e1aefe821b9d8c2d upstream.

In bond_do_ioctl(), slave_dev is obtained via __dev_get_by_name() which
can return NULL if the requested interface name does not exist. However,
the subsequent slave_dbg() call is placed before the NULL check:

    slave_dev = __dev_get_by_name(net, ifr-&gt;ifr_slave);
    slave_dbg(bond_dev, slave_dev, "slave_dev=%p:\n", slave_dev); //here
    if (!slave_dev)
        return -ENODEV;

The slave_dbg() macro expands to netdev_dbg(bond_dev, "(slave %s): " fmt,
(slave_dev)-&gt;name, ...) which unconditionally dereferences slave_dev-&gt;name
before the NULL check is performed. This results in a NULL pointer
dereference kernel oops when a user calls bonding ioctl (e.g.
SIOCBONDENSLAVE, SIOCBONDRELEASE, etc.) with a non-existent slave
interface name.

This is reachable from userspace via the bonding ioctl interface with
CAP_NET_ADMIN capability, making it a potential local denial-of-service
vector.

Fix by moving the slave_dbg() call after the NULL check.

Fixes: e2a7420df2e0 ("bonding/main: convert to using slave printk macros")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: ZhaoJinming &lt;zhaojinming@uniontech.com&gt;
Link: https://patch.msgid.link/20260601085649.4029067-1-zhaojinming@uniontech.com
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net: airoha: Add NULL check for of_reserved_mem_lookup() in airoha_qdma_init_hfwd_queues()</title>
<updated>2026-06-19T11:44:09+00:00</updated>
<author>
<name>ZhaoJinming</name>
<email>zhaojinming@uniontech.com</email>
</author>
<published>2026-06-04T07:03:52+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=01f7d4b504580664d36faea5671cde5e3f0d8a5b'/>
<id>urn:sha1:01f7d4b504580664d36faea5671cde5e3f0d8a5b</id>
<content type='text'>
commit f9f25118faa4dd2b6e3d14a03d123bbdbd59925d upstream.

of_reserved_mem_lookup() may return NULL if the reserved memory region
referenced by the "memory-region" phandle is not found in the reserved
memory table (e.g. due to a misconfigured DTS or a removed
memory-region node).  The current code dereferences the returned
pointer without checking for NULL, leading to a kernel NULL pointer
dereference at the following lines:

    dma_addr = rmem-&gt;base;                          // line 1156
    num_desc = div_u64(rmem-&gt;size, buf_size);       // line 1160

Add a NULL check after of_reserved_mem_lookup() and return -ENODEV if
the lookup fails, which is consistent with the existing error handling
for of_parse_phandle() failure in the same code block.

Fixes: 3a1ce9e3d01b ("net: airoha: Add the capability to allocate hwfd buffers via reserved-memory")
Cc: stable@vger.kernel.org
Signed-off-by: ZhaoJinming &lt;zhaojinming@uniontech.com&gt;
Acked-by: Lorenzo Bianconi &lt;lorenzo@kernel.org&gt;
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>net/mlx5: Reorder completion before putting command entry in cmd_work_handler</title>
<updated>2026-06-19T11:44:09+00:00</updated>
<author>
<name>Nikolay Kuratov</name>
<email>kniv@yandex-team.ru</email>
</author>
<published>2026-05-26T16:29:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=e0df4d9c090955c25a641f1df22593da6711a137'/>
<id>urn:sha1:e0df4d9c090955c25a641f1df22593da6711a137</id>
<content type='text'>
commit 02896a7fa4cd3ec61d60ba30136841e4f04bdeac upstream.

Assuming callback != NULL &amp;&amp; !page_queue, cmd_work_handler takes
command entry with refcnt == 1 from mlx5_cmd_invoke.
If either semaphore timeout or index allocation error happens,
it does final cmd_ent_put(ent). To avoid access to freed memory,
notify slotted completion before cmd_ent_put.

This is theoretical issue found by Svace static analyser.

Cc: stable@vger.kernel.org
Fixes: 485d65e135712 ("net/mlx5: Add a timeout to acquire the command queue semaphore")
Fixes: 0e2909c6bec90 ("net/mlx5: Fix variable not being completed when function returns")
Signed-off-by: Nikolay Kuratov &lt;kniv@yandex-team.ru&gt;
Reviewed-by: Md Haris Iqbal &lt;haris.iqbal@linux.dev&gt;
Reviewed-by: Moshe Shemesh &lt;moshe@nvidia.com&gt;
Acked-by: Tariq Toukan &lt;tariqt@nvidia.com&gt;
Link: https://patch.msgid.link/20260526162932.501584-1-kniv@yandex-team.ru
Signed-off-by: Paolo Abeni &lt;pabeni@redhat.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>bnxt_en: Fix NULL pointer dereference</title>
<updated>2026-06-19T11:44:07+00:00</updated>
<author>
<name>Kyle Meyer</name>
<email>kyle.meyer@hpe.com</email>
</author>
<published>2026-06-05T22:25:24+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=3884976f87448e269908ae61bd5d62d54ce9c0c7'/>
<id>urn:sha1:3884976f87448e269908ae61bd5d62d54ce9c0c7</id>
<content type='text'>
commit d930276f2cddd0b7294cac7a8fe7b877f6d9e08d upstream.

PCIe errors detected by a Root Port or Downstream Port cause error
recovery services to run on all subordinate devices regardless of
administrative state.

The .error_detected() callback, bnxt_io_error_detected(), disables
and synchronizes IRQs via bnxt_disable_int_sync(), which calls
bnxt_cp_num_to_irq_num() to map completion rings to IRQs using
bp-&gt;bnapi.

Since bp-&gt;bnapi is allocated on NIC open and freed on NIC close, PCIe
error recovery on a closed NIC can dereference a NULL pointer.

Check if bp-&gt;bnapi is NULL before disabling and synchronizing IRQs.

Fixes: e5811b8c09df ("bnxt_en: Add IRQ remapping logic.")
Cc: stable@vger.kernel.org
Signed-off-by: Kyle Meyer &lt;kyle.meyer@hpe.com&gt;
Reviewed-by: Pavan Chebbi &lt;pavan.chebbi@broadcom.com&gt;
Link: https://patch.msgid.link/aiNM1CY2-StPilxW@hpe.com
Signed-off-by: Jakub Kicinski &lt;kuba@kernel.org&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
<entry>
<title>wifi: iwlwifi: pcie: simplify the resume flow if fast resume is not used</title>
<updated>2026-06-19T11:44:06+00:00</updated>
<author>
<name>Emmanuel Grumbach</name>
<email>emmanuel.grumbach@intel.com</email>
</author>
<published>2026-05-31T10:30:19+00:00</published>
<link rel='alternate' type='text/html' href='https://git.radix-linux.su/kernel/linux.git/commit/?id=ac2000be0cbedab32c05644f10937dbde804aff5'/>
<id>urn:sha1:ac2000be0cbedab32c05644f10937dbde804aff5</id>
<content type='text'>
commit 093305d801fae6ff9b8bb531fd78b579794c4f80 upstream.

In most distributions, NetworkManager shuts the device down before
entering system suspend, so fast suspend is typically not used.

On older devices, resume currently tries to grab NIC access to infer
whether the device was powered off while suspended. That probe is only
meaningful for the fast-suspend path where the device is expected to
remain alive.

Unfortunately, for unclear reasons, grabbing NIC access was harmful as
reported in the bugzilla ticket below.

Workaround this issue by simply not grabbing NIC access if fast suspend
is not used.

Cc: stable@vger.kernel.org
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221501
Assisted-by: GitHub Copilot:gpt-5.3-codex
Signed-off-by: Emmanuel Grumbach &lt;emmanuel.grumbach@intel.com&gt;
Link: https://patch.msgid.link/20260531133005.e2ed9e0cd44f.If283625983a843933e0c01561a421daff184e9e9@changeid
Signed-off-by: Miri Korenblit &lt;miriam.rachel.korenblit@intel.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
</entry>
</feed>
