* [PATCH AUTOSEL 6.18] netfilter: nfnetlink_queue: make hash table per queue
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Florian Westphal, Scott Mitchell, Sasha Levin, pablo, davem,
edumazet, kuba, pabeni, netfilter-devel, coreteam, netdev,
linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Florian Westphal <fw@strlen.de>
[ Upstream commit 936206e3f6ff411581e615e930263d6f8b78df9d ]
Sharing a global hash table among all queues is tempting, but
it can cause crash:
BUG: KASAN: slab-use-after-free in nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]
[..]
nfqnl_recv_verdict+0x11ac/0x15e0 [nfnetlink_queue]
nfnetlink_rcv_msg+0x46a/0x930
kmem_cache_alloc_node_noprof+0x11e/0x450
struct nf_queue_entry is freed via kfree, but parallel cpu can still
encounter such an nf_queue_entry when walking the list.
Alternative fix is to free the nf_queue_entry via kfree_rcu() instead,
but as we have to alloc/free for each skb this will cause more mem
pressure.
Cc: Scott Mitchell <scott.k.mitch1@gmail.com>
Fixes: e19079adcd26 ("netfilter: nfnetlink_queue: optimize verdict lookup with hash table")
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
include/net/netfilter/nf_queue.h | 1 -
net/netfilter/nfnetlink_queue.c | 139 +++++++++++--------------------
2 files changed, 49 insertions(+), 91 deletions(-)
diff --git a/include/net/netfilter/nf_queue.h b/include/net/netfilter/nf_queue.h
index 45eb26b2e95b3..d17035d14d96c 100644
--- a/include/net/netfilter/nf_queue.h
+++ b/include/net/netfilter/nf_queue.h
@@ -23,7 +23,6 @@ struct nf_queue_entry {
struct nf_hook_state state;
bool nf_ct_is_unconfirmed;
u16 size; /* sizeof(entry) + saved route keys */
- u16 queue_num;
/* extra space to store route keys */
};
diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
index a39d3b989063c..fe5942535245d 100644
--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -49,8 +49,8 @@
#endif
#define NFQNL_QMAX_DEFAULT 1024
-#define NFQNL_HASH_MIN 1024
-#define NFQNL_HASH_MAX 1048576
+#define NFQNL_HASH_MIN 8
+#define NFQNL_HASH_MAX 32768
/* We're using struct nlattr which has 16bit nla_len. Note that nla_len
* includes the header length. Thus, the maximum packet length that we
@@ -60,29 +60,10 @@
*/
#define NFQNL_MAX_COPY_RANGE (0xffff - NLA_HDRLEN)
-/* Composite key for packet lookup: (net, queue_num, packet_id) */
-struct nfqnl_packet_key {
- possible_net_t net;
- u32 packet_id;
- u16 queue_num;
-} __aligned(sizeof(u32)); /* jhash2 requires 32-bit alignment */
-
-/* Global rhashtable - one for entire system, all netns */
-static struct rhashtable nfqnl_packet_map __read_mostly;
-
-/* Helper to initialize composite key */
-static inline void nfqnl_init_key(struct nfqnl_packet_key *key,
- struct net *net, u32 packet_id, u16 queue_num)
-{
- memset(key, 0, sizeof(*key));
- write_pnet(&key->net, net);
- key->packet_id = packet_id;
- key->queue_num = queue_num;
-}
-
struct nfqnl_instance {
struct hlist_node hlist; /* global list of queues */
- struct rcu_head rcu;
+ struct rhashtable nfqnl_packet_map;
+ struct rcu_work rwork;
u32 peer_portid;
unsigned int queue_maxlen;
@@ -106,6 +87,7 @@ struct nfqnl_instance {
typedef int (*nfqnl_cmpfn)(struct nf_queue_entry *, unsigned long);
+static struct workqueue_struct *nfq_cleanup_wq __read_mostly;
static unsigned int nfnl_queue_net_id __read_mostly;
#define INSTANCE_BUCKETS 16
@@ -124,34 +106,10 @@ static inline u_int8_t instance_hashfn(u_int16_t queue_num)
return ((queue_num >> 8) ^ queue_num) % INSTANCE_BUCKETS;
}
-/* Extract composite key from nf_queue_entry for hashing */
-static u32 nfqnl_packet_obj_hashfn(const void *data, u32 len, u32 seed)
-{
- const struct nf_queue_entry *entry = data;
- struct nfqnl_packet_key key;
-
- nfqnl_init_key(&key, entry->state.net, entry->id, entry->queue_num);
-
- return jhash2((u32 *)&key, sizeof(key) / sizeof(u32), seed);
-}
-
-/* Compare stack-allocated key against entry */
-static int nfqnl_packet_obj_cmpfn(struct rhashtable_compare_arg *arg,
- const void *obj)
-{
- const struct nfqnl_packet_key *key = arg->key;
- const struct nf_queue_entry *entry = obj;
-
- return !net_eq(entry->state.net, read_pnet(&key->net)) ||
- entry->queue_num != key->queue_num ||
- entry->id != key->packet_id;
-}
-
static const struct rhashtable_params nfqnl_rhashtable_params = {
.head_offset = offsetof(struct nf_queue_entry, hash_node),
- .key_len = sizeof(struct nfqnl_packet_key),
- .obj_hashfn = nfqnl_packet_obj_hashfn,
- .obj_cmpfn = nfqnl_packet_obj_cmpfn,
+ .key_offset = offsetof(struct nf_queue_entry, id),
+ .key_len = sizeof(u32),
.automatic_shrinking = true,
.min_size = NFQNL_HASH_MIN,
.max_size = NFQNL_HASH_MAX,
@@ -190,6 +148,10 @@ instance_create(struct nfnl_queue_net *q, u_int16_t queue_num, u32 portid)
spin_lock_init(&inst->lock);
INIT_LIST_HEAD(&inst->queue_list);
+ err = rhashtable_init(&inst->nfqnl_packet_map, &nfqnl_rhashtable_params);
+ if (err < 0)
+ goto out_free;
+
spin_lock(&q->instances_lock);
if (instance_lookup(q, queue_num)) {
err = -EEXIST;
@@ -210,6 +172,8 @@ instance_create(struct nfnl_queue_net *q, u_int16_t queue_num, u32 portid)
out_unlock:
spin_unlock(&q->instances_lock);
+ rhashtable_destroy(&inst->nfqnl_packet_map);
+out_free:
kfree(inst);
return ERR_PTR(err);
}
@@ -217,15 +181,18 @@ instance_create(struct nfnl_queue_net *q, u_int16_t queue_num, u32 portid)
static void nfqnl_flush(struct nfqnl_instance *queue, nfqnl_cmpfn cmpfn,
unsigned long data);
-static void
-instance_destroy_rcu(struct rcu_head *head)
+static void instance_destroy_work(struct work_struct *work)
{
- struct nfqnl_instance *inst = container_of(head, struct nfqnl_instance,
- rcu);
+ struct nfqnl_instance *inst;
+ inst = container_of(to_rcu_work(work), struct nfqnl_instance,
+ rwork);
rcu_read_lock();
nfqnl_flush(inst, NULL, 0);
rcu_read_unlock();
+
+ rhashtable_destroy(&inst->nfqnl_packet_map);
+
kfree(inst);
module_put(THIS_MODULE);
}
@@ -234,7 +201,9 @@ static void
__instance_destroy(struct nfqnl_instance *inst)
{
hlist_del_rcu(&inst->hlist);
- call_rcu(&inst->rcu, instance_destroy_rcu);
+
+ INIT_RCU_WORK(&inst->rwork, instance_destroy_work);
+ queue_rcu_work(nfq_cleanup_wq, &inst->rwork);
}
static void
@@ -250,9 +219,7 @@ __enqueue_entry(struct nfqnl_instance *queue, struct nf_queue_entry *entry)
{
int err;
- entry->queue_num = queue->queue_num;
-
- err = rhashtable_insert_fast(&nfqnl_packet_map, &entry->hash_node,
+ err = rhashtable_insert_fast(&queue->nfqnl_packet_map, &entry->hash_node,
nfqnl_rhashtable_params);
if (unlikely(err))
return err;
@@ -266,23 +233,19 @@ __enqueue_entry(struct nfqnl_instance *queue, struct nf_queue_entry *entry)
static void
__dequeue_entry(struct nfqnl_instance *queue, struct nf_queue_entry *entry)
{
- rhashtable_remove_fast(&nfqnl_packet_map, &entry->hash_node,
+ rhashtable_remove_fast(&queue->nfqnl_packet_map, &entry->hash_node,
nfqnl_rhashtable_params);
list_del(&entry->list);
queue->queue_total--;
}
static struct nf_queue_entry *
-find_dequeue_entry(struct nfqnl_instance *queue, unsigned int id,
- struct net *net)
+find_dequeue_entry(struct nfqnl_instance *queue, unsigned int id)
{
- struct nfqnl_packet_key key;
struct nf_queue_entry *entry;
- nfqnl_init_key(&key, net, id, queue->queue_num);
-
spin_lock_bh(&queue->lock);
- entry = rhashtable_lookup_fast(&nfqnl_packet_map, &key,
+ entry = rhashtable_lookup_fast(&queue->nfqnl_packet_map, &id,
nfqnl_rhashtable_params);
if (entry)
@@ -1531,7 +1494,7 @@ static int nfqnl_recv_verdict(struct sk_buff *skb, const struct nfnl_info *info,
verdict = ntohl(vhdr->verdict);
- entry = find_dequeue_entry(queue, ntohl(vhdr->id), info->net);
+ entry = find_dequeue_entry(queue, ntohl(vhdr->id));
if (entry == NULL)
return -ENOENT;
@@ -1880,40 +1843,38 @@ static int __init nfnetlink_queue_init(void)
{
int status;
- status = rhashtable_init(&nfqnl_packet_map, &nfqnl_rhashtable_params);
- if (status < 0)
- return status;
+ nfq_cleanup_wq = alloc_ordered_workqueue("nfq_workqueue", 0);
+ if (!nfq_cleanup_wq)
+ return -ENOMEM;
status = register_pernet_subsys(&nfnl_queue_net_ops);
- if (status < 0) {
- pr_err("failed to register pernet ops\n");
- goto cleanup_rhashtable;
- }
+ if (status < 0)
+ goto cleanup_pernet_subsys;
- netlink_register_notifier(&nfqnl_rtnl_notifier);
- status = nfnetlink_subsys_register(&nfqnl_subsys);
- if (status < 0) {
- pr_err("failed to create netlink socket\n");
- goto cleanup_netlink_notifier;
- }
+ status = netlink_register_notifier(&nfqnl_rtnl_notifier);
+ if (status < 0)
+ goto cleanup_rtnl_notifier;
status = register_netdevice_notifier(&nfqnl_dev_notifier);
- if (status < 0) {
- pr_err("failed to register netdevice notifier\n");
- goto cleanup_netlink_subsys;
- }
+ if (status < 0)
+ goto cleanup_dev_notifier;
+
+ status = nfnetlink_subsys_register(&nfqnl_subsys);
+ if (status < 0)
+ goto cleanup_nfqnl_subsys;
nf_register_queue_handler(&nfqh);
return status;
-cleanup_netlink_subsys:
- nfnetlink_subsys_unregister(&nfqnl_subsys);
-cleanup_netlink_notifier:
+cleanup_nfqnl_subsys:
+ unregister_netdevice_notifier(&nfqnl_dev_notifier);
+cleanup_dev_notifier:
netlink_unregister_notifier(&nfqnl_rtnl_notifier);
+cleanup_rtnl_notifier:
unregister_pernet_subsys(&nfnl_queue_net_ops);
-cleanup_rhashtable:
- rhashtable_destroy(&nfqnl_packet_map);
+cleanup_pernet_subsys:
+ destroy_workqueue(nfq_cleanup_wq);
return status;
}
@@ -1924,9 +1885,7 @@ static void __exit nfnetlink_queue_fini(void)
nfnetlink_subsys_unregister(&nfqnl_subsys);
netlink_unregister_notifier(&nfqnl_rtnl_notifier);
unregister_pernet_subsys(&nfnl_queue_net_ops);
-
- rhashtable_destroy(&nfqnl_packet_map);
-
+ destroy_workqueue(nfq_cleanup_wq);
rcu_barrier(); /* Wait for completion of call_rcu()'s */
}
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] net: sfp: add quirks for Hisense and HSGQ GPON ONT SFP modules
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: John Pavlick, Russell King (Oracle), Marcin Nita, Jakub Kicinski,
Sasha Levin, linux, andrew, hkallweit1, davem, edumazet, pabeni,
netdev, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: John Pavlick <jspavlick@posteo.net>
[ Upstream commit 95aca8602ef70ffd3d971675751c81826e124f90 ]
Several GPON ONT SFP sticks based on Realtek RTL960x report
1000BASE-LX at 1300MBd in their EEPROM but can operate at 2500base-X.
On hosts capable of 2500base-X (e.g. Banana Pi R3 / MT7986), the
kernel negotiates only 1G because it trusts the incorrect EEPROM data.
Add quirks for:
- Hisense-Leox LXT-010S-H
- Hisense ZNID-GPON-2311NA
- HSGQ HSGQ-XPON-Stick
Each quirk advertises 2500base-X and ignores TX_FAULT during the
module's ~40s Linux boot time.
Tested on Banana Pi R3 (MT7986) with OpenWrt 25.12.1, confirmed
2.5Gbps link and full throughput with flow offloading.
Reviewed-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
Suggested-by: Marcin Nita <marcin.nita@leolabs.pl>
Signed-off-by: John Pavlick <jspavlick@posteo.net>
Link: https://patch.msgid.link/20260406132321.72563-1-jspavlick@posteo.net
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/net/phy/sfp.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/net/phy/sfp.c b/drivers/net/phy/sfp.c
index 7a85b758fb1e6..c62e3f364ea73 100644
--- a/drivers/net/phy/sfp.c
+++ b/drivers/net/phy/sfp.c
@@ -543,6 +543,22 @@ static const struct sfp_quirk sfp_quirks[] = {
SFP_QUIRK("HUAWEI", "MA5671A", sfp_quirk_2500basex,
sfp_fixup_ignore_tx_fault_and_los),
+ // Hisense LXT-010S-H is a GPON ONT SFP (sold as LEOX LXT-010S-H) that
+ // can operate at 2500base-X, but reports 1000BASE-LX / 1300MBd in its
+ // EEPROM
+ SFP_QUIRK("Hisense-Leox", "LXT-010S-H", sfp_quirk_2500basex,
+ sfp_fixup_ignore_tx_fault),
+
+ // Hisense ZNID-GPON-2311NA can operate at 2500base-X, but reports
+ // 1000BASE-LX / 1300MBd in its EEPROM
+ SFP_QUIRK("Hisense", "ZNID-GPON-2311NA", sfp_quirk_2500basex,
+ sfp_fixup_ignore_tx_fault),
+
+ // HSGQ HSGQ-XPON-Stick can operate at 2500base-X, but reports
+ // 1000BASE-LX / 1300MBd in its EEPROM
+ SFP_QUIRK("HSGQ", "HSGQ-XPON-Stick", sfp_quirk_2500basex,
+ sfp_fixup_ignore_tx_fault),
+
// Lantech 8330-262D-E and 8330-265D can operate at 2500base-X, but
// incorrectly report 2500MBd NRZ in their EEPROM.
// Some 8330-265D modules have inverted LOS, while all of them report
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] ixgbevf: add missing negotiate_features op to Hyper-V ops table
From: Sasha Levin @ 2026-04-20 13:08 UTC (permalink / raw)
To: patches, stable
Cc: Michal Schmidt, Xiaoqiang Xiong, Aleksandr Loktionov, Tony Nguyen,
Sasha Levin, przemyslaw.kitszel, andrew+netdev, davem, edumazet,
kuba, pabeni, jacob.e.keller, jedrzej.jagielski, intel-wired-lan,
netdev, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Michal Schmidt <mschmidt@redhat.com>
[ Upstream commit 4821d563cd7f251ae728be1a6d04af82a294a5b9 ]
Commit a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by
negotiating supported features") added the .negotiate_features callback
to ixgbe_mac_operations and populated it in ixgbevf_mac_ops, but forgot
to add it to ixgbevf_hv_mac_ops. This leaves the function pointer NULL
on Hyper-V VMs.
During probe, ixgbevf_negotiate_api() calls ixgbevf_set_features(),
which unconditionally dereferences hw->mac.ops.negotiate_features().
On Hyper-V this results in a NULL pointer dereference:
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
Hardware name: Microsoft Corporation Virtual Machine/Virtual Machine [...]
Workqueue: events work_for_cpu_fn
RIP: 0010:0x0
[...]
Call Trace:
ixgbevf_negotiate_api+0x66/0x160 [ixgbevf]
ixgbevf_sw_init+0xe4/0x1f0 [ixgbevf]
ixgbevf_probe+0x20f/0x4a0 [ixgbevf]
local_pci_probe+0x50/0xa0
work_for_cpu_fn+0x1a/0x30
[...]
Add ixgbevf_hv_negotiate_features_vf() that returns -EOPNOTSUPP and
wire it into ixgbevf_hv_mac_ops. The caller already handles -EOPNOTSUPP
gracefully.
Fixes: a7075f501bd3 ("ixgbevf: fix mailbox API compatibility by negotiating supported features")
Reported-by: Xiaoqiang Xiong <xxiong@redhat.com>
Closes: https://issues.redhat.com/browse/RHEL-155455
Assisted-by: Claude:claude-4.6-opus-high Cursor
Tested-by: Xiaoqiang Xiong <xxiong@redhat.com>
Signed-off-by: Michal Schmidt <mschmidt@redhat.com>
Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/net/ethernet/intel/ixgbevf/vf.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/drivers/net/ethernet/intel/ixgbevf/vf.c b/drivers/net/ethernet/intel/ixgbevf/vf.c
index b67b580f7f1c9..f6df86d124b9e 100644
--- a/drivers/net/ethernet/intel/ixgbevf/vf.c
+++ b/drivers/net/ethernet/intel/ixgbevf/vf.c
@@ -709,6 +709,12 @@ static int ixgbevf_negotiate_features_vf(struct ixgbe_hw *hw, u32 *pf_features)
return err;
}
+static int ixgbevf_hv_negotiate_features_vf(struct ixgbe_hw *hw,
+ u32 *pf_features)
+{
+ return -EOPNOTSUPP;
+}
+
/**
* ixgbevf_set_vfta_vf - Set/Unset VLAN filter table address
* @hw: pointer to the HW structure
@@ -1142,6 +1148,7 @@ static const struct ixgbe_mac_operations ixgbevf_hv_mac_ops = {
.setup_link = ixgbevf_setup_mac_link_vf,
.check_link = ixgbevf_hv_check_mac_link_vf,
.negotiate_api_version = ixgbevf_hv_negotiate_api_version_vf,
+ .negotiate_features = ixgbevf_hv_negotiate_features_vf,
.set_rar = ixgbevf_hv_set_rar_vf,
.update_mc_addr_list = ixgbevf_hv_update_mc_addr_list_vf,
.update_xcast_mode = ixgbevf_hv_update_xcast_mode,
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] wifi: ath12k: Fix the assignment of logical link index
From: Sasha Levin @ 2026-04-20 13:09 UTC (permalink / raw)
To: patches, stable
Cc: Manish Dharanenthiran, Roopni Devanathan, Rameshkumar Sundaram,
Baochen Qiang, Vasanthakumar Thiagarajan, Jeff Johnson,
Sasha Levin, kvalo, davem, kuba, linux-wireless, netdev,
linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>
[ Upstream commit aecb569d7fb689e3e5b0005ca7bd0a2ef28915e8 ]
Per-link logical index is assigned from the global counter,
ahsta->num_peer. This logical index is sent to firmware during peer
association. If there is a failure in creating a link station,
ath12k_mac_free_unassign_link_sta() clears the link, but does not decrement
the logical link index. This will result in a higher logical link index for
the next link station created. Also, if there is a leak in logical link
index as we assign the incremented num_peer, then the index can exceed the
maximum valid value of 15.
As an example, let's say we have a 2 GHz + 5 GHz + 6 GHz MLO setup. So the
logical link indices that they have are 0, 1 and 2, respectively. If the
5 GHz link is removed, logical link index 1 becomes available, and num_peer
is not reduced to 2 and still remains at 3. If a new 5 GHz link is added
later, it gets the index 3, instead of reusing link index 1. Also,
num_peer is increased to 4, though only 3 links are present.
To resolve these, create a bitmap, free_logical_link_idx, that tracks the
available logical link indices. When a link station is created, select the
first free logical index and when a link station is removed, mark its
logical link index as available by setting the bit.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.6-01181-QCAHKSWPL_SILICONZ-1
Signed-off-by: Manish Dharanenthiran <manish.dharanenthiran@oss.qualcomm.com>
Signed-off-by: Roopni Devanathan <roopni.devanathan@oss.qualcomm.com>
Reviewed-by: Rameshkumar Sundaram <rameshkumar.sundaram@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20260226041911.2434999-1-roopni.devanathan@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information I need. Let me compile the final
analysis.
---
## Complete Analysis
### PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1:**
- Subsystem: `wifi: ath12k`
- Action verb: "Fix"
- Summary: Fixes the assignment of logical link index for MLO (Multi-
Link Operation) link stations.
**Step 1.2: Tags:**
- `Tested-on: QCN9274 hw2.0 PCI` — hardware tested
- `Signed-off-by: Manish Dharanenthiran` — original author
- `Signed-off-by: Roopni Devanathan` — submitter
- `Reviewed-by: Rameshkumar Sundaram`, `Baochen Qiang`, `Vasanthakumar
Thiagarajan` — 3 Qualcomm reviewers
- `Link:` to patch.msgid.link — original submission
- `Signed-off-by: Jeff Johnson` — ath12k maintainer applied it
- No Fixes: tag, no Reported-by, no syzbot, no Cc: stable — expected for
autoselection candidates.
**Step 1.3:** The commit message describes a clear bug: `num_peer` is a
monotonically incrementing counter used to assign logical link indices.
When links are removed, the counter is never decremented, causing
"leakage" of index values. Over time with link add/remove cycles, the
index exceeds the firmware's maximum valid value of 15.
**Step 1.4:** This is NOT a hidden bug fix — the subject explicitly says
"Fix".
### PHASE 2: DIFF ANALYSIS
**Step 2.1:**
- `core.h`: 1 line changed (`u8 num_peer` -> `u16
free_logical_link_idx_map`)
- `mac.c`: ~20 lines changed across 3 functions
- Functions modified: `ath12k_mac_free_unassign_link_sta`,
`ath12k_mac_assign_link_sta`, `ath12k_mac_op_sta_state`
- Scope: well-contained, single-subsystem fix
**Step 2.2:**
- In `ath12k_mac_free_unassign_link_sta`: adds
`ahsta->free_logical_link_idx_map |= BIT(arsta->link_idx)` — returns
the freed index to the pool
- In `ath12k_mac_assign_link_sta`: replaces `arsta->link_idx =
ahsta->num_peer++` with bitmap-based allocation using `__ffs()` + adds
`-ENOSPC` check
- In `ath12k_mac_op_sta_state`: initializes
`ahsta->free_logical_link_idx_map = U16_MAX` when a new station is
created (all bits set = all indices free)
**Step 2.3:** Bug category: Logic/correctness bug — resource index leak.
The old approach only increments, never reuses indices. The new bitmap
approach properly tracks available indices.
**Step 2.4:** Fix quality:
- The fix is correct — bitmap tracks available indices, `__ffs` gets the
lowest free bit, removal sets the bit back
- It adds a proper `-ENOSPC` check for when all indices are exhausted
- Minimal regression risk — the logic is straightforward and only
touches the specific allocation/deallocation paths
- The U16_MAX initialization means 16 indices (0-15), which matches the
firmware's maximum
### PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1:** `git blame` confirms both the buggy code (`num_peer++` at
line 7124) and the incomplete cleanup function were introduced by the
same commit: `8e6f8bc286031` ("Add MLO station state change handling")
by Sriram R, dated 2024-11-21, first in v6.14-rc1.
**Step 3.2:** No Fixes: tag present. The bug was introduced by
8e6f8bc286031.
**Step 3.3:** No intermediate fixes for the same issue. No prerequisites
found — the patch modifies code that exists in the tree as-is.
**Step 3.4:** The author (Manish Dharanenthiran) is a regular ath12k
contributor with 9+ commits in the subsystem. Jeff Johnson (ath12k
maintainer) applied it.
**Step 3.5:** This is a standalone single-patch fix. No dependencies on
other commits.
### PHASE 4: MAILING LIST RESEARCH
Lore was not accessible due to anti-bot protection. b4 dig could not
find the exact commit (it hasn't landed in the main tree yet from the
perspective of this 7.0 tree). The patch was sent to
`ath12k@lists.infradead.org` and `linux-wireless@vger.kernel.org`. It
was reviewed by 3 Qualcomm engineers and applied by the ath12k
maintainer Jeff Johnson.
### PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1:** Modified functions: `ath12k_mac_free_unassign_link_sta`,
`ath12k_mac_assign_link_sta`, `ath12k_mac_op_sta_state`
**Step 5.2:** `arsta->link_idx` is used in `ath12k_peer_assoc_h_mlo()`
(line 3531) to populate `ml->logical_link_idx` which is sent to firmware
via `wmi.c` line 2348 as `ml_params->logical_link_idx`. This is a WMI
command parameter — an invalid value directly impacts firmware behavior.
**Step 5.4:** The path: `ath12k_mac_op_sta_state` ->
`ath12k_mac_assign_link_sta` -> sets `link_idx` -> later used in
`ath12k_peer_assoc_h_mlo` -> sent via WMI to firmware. This is a
standard MLO station association path triggered during Wi-Fi connection
setup.
### PHASE 6: STABLE TREE ANALYSIS
**Step 6.1:** The buggy code (`num_peer` field) was introduced in commit
`8e6f8bc286031`, first in v6.14-rc1. It is:
- **NOT in v6.13, v6.12, or any earlier LTS tree**
- Present in v6.14, v6.15, v6.16, v6.17, v6.18, v6.19, v7.0
For the 7.0.y stable tree specifically, the buggy code IS present.
**Step 6.2:** The code in v7.0 matches exactly what the patch expects
(verified by reading lines 7096-7137 and 6771-6798 of mac.c). The patch
should apply cleanly.
### PHASE 7: SUBSYSTEM CONTEXT
**Step 7.1:** Subsystem: wireless driver (ath12k) — IMPORTANT for WiFi 7
users with Qualcomm QCN9274 and similar chipsets. MLO is a key WiFi 7
feature.
**Step 7.2:** ath12k is very actively developed (183 commits to mac.c
between v6.14 and v7.0).
### PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1:** Affected users: Users of Qualcomm ath12k WiFi 7 hardware
with MLO enabled (QCN9274, etc.).
**Step 8.2:** Trigger: Happens when MLO links are removed and re-added —
occurs during roaming, channel switching, or temporary link degradation.
In a typical MLO setup with frequent link changes, this can be triggered
relatively easily.
**Step 8.3:** Failure mode: Sending an invalid logical link index (>15)
to firmware can cause firmware malfunction, potential firmware crash, or
incorrect MLO behavior. Severity: **HIGH** — firmware receives invalid
commands.
**Step 8.4:**
- Benefit: Prevents firmware from receiving invalid index values during
MLO operations, which could cause connection instability or firmware
crashes
- Risk: LOW — the change is ~20 lines, well-contained, uses standard
bitmap operations, reviewed by 3 engineers plus maintainer
- Ratio: Favorable
### PHASE 9: FINAL SYNTHESIS
**Evidence FOR backporting:**
- Fixes a real, clearly described bug (index leak leading to invalid
firmware commands)
- Small, well-contained fix (~20 lines across 2 files)
- Obviously correct bitmap-based approach
- 3 Reviewed-by tags from Qualcomm engineers + maintainer sign-off
- Tested on hardware (QCN9274 hw2.0)
- The buggy code exists in v7.0 (target tree)
- Should apply cleanly
**Evidence AGAINST backporting:**
- No Fixes: tag, no syzbot/crash report, no user-reported symptom
- Replaces a data structure member (counter -> bitmap), slightly more
than a trivial patch
- MLO is relatively new; impact limited to WiFi 7 MLO users
- No explicit Cc: stable nomination
- The bug requires specific MLO link add/remove cycles to manifest
**Stable rules checklist:**
1. Obviously correct and tested? **Yes** — bitmap approach is
straightforward, hardware tested
2. Fixes a real bug? **Yes** — index leak causing invalid firmware
commands
3. Important issue? **Medium-High** — can cause firmware malfunction in
MLO
4. Small and contained? **Yes** — ~20 lines in 2 files, single subsystem
5. No new features? **Correct** — pure bug fix
6. Can apply to stable? **Yes** — code matches cleanly
**Verification:**
- [Phase 1] Parsed tags: 3 Reviewed-by, tested-on, Link, maintainer SOB
- [Phase 2] Diff analysis: replaces `num_peer` counter with
`free_logical_link_idx_map` bitmap across 3 functions
- [Phase 3] git blame: buggy code introduced in 8e6f8bc286031
(v6.14-rc1), confirmed by `git merge-base --is-ancestor` checks
- [Phase 3] `git merge-base --is-ancestor 8e6f8bc286031 v6.13` → Not in
v6.13; `v6.14` → Yes
- [Phase 3] Author has 9+ ath12k commits, is a regular contributor
- [Phase 4] b4 dig could not find the commit (not merged in this tree);
lore blocked by anti-bot
- [Phase 5] Traced `link_idx` usage: set in `ath12k_mac_assign_link_sta`
→ used in `ath12k_peer_assoc_h_mlo` (line 3531) → sent to firmware via
WMI (wmi.c line 2348)
- [Phase 6] Buggy code confirmed present in v7.0 tree; code at lines
7096-7137 matches patch context exactly
- [Phase 6] NOT in v6.13 or earlier LTS trees (v6.12.y, v6.6.y, etc.)
- [Phase 8] Invalid logical_link_idx sent to firmware can cause firmware
malfunction
- UNVERIFIED: Could not access lore discussion to check for reviewer
stable nominations or concerns
This is a real bug fix for a resource index leak in WiFi 7 MLO handling
that can lead to invalid firmware commands. The fix is small, self-
contained, well-reviewed, and hardware-tested. The buggy code exists in
the target 7.0.y tree.
**YES**
drivers/net/wireless/ath/ath12k/core.h | 2 +-
drivers/net/wireless/ath/ath12k/mac.c | 16 ++++++++++++++--
2 files changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/ath/ath12k/core.h b/drivers/net/wireless/ath/ath12k/core.h
index 990934ec92fca..5498ff285102b 100644
--- a/drivers/net/wireless/ath/ath12k/core.h
+++ b/drivers/net/wireless/ath/ath12k/core.h
@@ -522,7 +522,7 @@ struct ath12k_sta {
u16 links_map;
u8 assoc_link_id;
u16 ml_peer_id;
- u8 num_peer;
+ u16 free_logical_link_idx_map;
enum ieee80211_sta_state state;
};
diff --git a/drivers/net/wireless/ath/ath12k/mac.c b/drivers/net/wireless/ath/ath12k/mac.c
index b253d1e3f4052..769d240e3ae24 100644
--- a/drivers/net/wireless/ath/ath12k/mac.c
+++ b/drivers/net/wireless/ath/ath12k/mac.c
@@ -6784,6 +6784,8 @@ static void ath12k_mac_free_unassign_link_sta(struct ath12k_hw *ah,
return;
ahsta->links_map &= ~BIT(link_id);
+ ahsta->free_logical_link_idx_map |= BIT(arsta->link_idx);
+
rcu_assign_pointer(ahsta->link[link_id], NULL);
synchronize_rcu();
@@ -7102,6 +7104,7 @@ static int ath12k_mac_assign_link_sta(struct ath12k_hw *ah,
struct ieee80211_sta *sta = ath12k_ahsta_to_sta(ahsta);
struct ieee80211_link_sta *link_sta;
struct ath12k_link_vif *arvif;
+ int link_idx;
lockdep_assert_wiphy(ah->hw->wiphy);
@@ -7120,8 +7123,16 @@ static int ath12k_mac_assign_link_sta(struct ath12k_hw *ah,
ether_addr_copy(arsta->addr, link_sta->addr);
- /* logical index of the link sta in order of creation */
- arsta->link_idx = ahsta->num_peer++;
+ if (!ahsta->free_logical_link_idx_map)
+ return -ENOSPC;
+
+ /*
+ * Allocate a logical link index by selecting the first available bit
+ * from the free logical index map
+ */
+ link_idx = __ffs(ahsta->free_logical_link_idx_map);
+ ahsta->free_logical_link_idx_map &= ~BIT(link_idx);
+ arsta->link_idx = link_idx;
arsta->link_id = link_id;
ahsta->links_map |= BIT(arsta->link_id);
@@ -7630,6 +7641,7 @@ int ath12k_mac_op_sta_state(struct ieee80211_hw *hw,
if (old_state == IEEE80211_STA_NOTEXIST &&
new_state == IEEE80211_STA_NONE) {
memset(ahsta, 0, sizeof(*ahsta));
+ ahsta->free_logical_link_idx_map = U16_MAX;
arsta = &ahsta->deflink;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] Bluetooth: hci_sync: annotate data-races around hdev->req_status
From: Sasha Levin @ 2026-04-20 13:09 UTC (permalink / raw)
To: patches, stable
Cc: Cen Zhang, Luiz Augusto von Dentz, Sasha Levin, marcel,
johan.hedberg, davem, kuba, linux-bluetooth, netdev, linux-kernel
In-Reply-To: <20260420131539.986432-1-sashal@kernel.org>
From: Cen Zhang <zzzccc427@gmail.com>
[ Upstream commit b6807cfc195ef99e1ac37b2e1e60df40295daa8c ]
__hci_cmd_sync_sk() sets hdev->req_status under hdev->req_lock:
hdev->req_status = HCI_REQ_PEND;
However, several other functions read or write hdev->req_status without
holding any lock:
- hci_send_cmd_sync() reads req_status in hci_cmd_work (workqueue)
- hci_cmd_sync_complete() reads/writes from HCI event completion
- hci_cmd_sync_cancel() / hci_cmd_sync_cancel_sync() read/write
- hci_abort_conn() reads in connection abort path
Since __hci_cmd_sync_sk() runs on hdev->req_workqueue while
hci_send_cmd_sync() runs on hdev->workqueue, these are different
workqueues that can execute concurrently on different CPUs. The plain
C accesses constitute a data race.
Add READ_ONCE()/WRITE_ONCE() annotations on all concurrent accesses
to hdev->req_status to prevent potential compiler optimizations that
could affect correctness (e.g., load fusing in the wait_event
condition or store reordering).
Signed-off-by: Cen Zhang <zzzccc427@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
net/bluetooth/hci_conn.c | 2 +-
net/bluetooth/hci_core.c | 2 +-
net/bluetooth/hci_sync.c | 20 ++++++++++----------
3 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/net/bluetooth/hci_conn.c b/net/bluetooth/hci_conn.c
index 24b71ec8897ff..71a24be2a6d67 100644
--- a/net/bluetooth/hci_conn.c
+++ b/net/bluetooth/hci_conn.c
@@ -2967,7 +2967,7 @@ int hci_abort_conn(struct hci_conn *conn, u8 reason)
* hci_connect_le serializes the connection attempts so only one
* connection can be in BT_CONNECT at time.
*/
- if (conn->state == BT_CONNECT && hdev->req_status == HCI_REQ_PEND) {
+ if (conn->state == BT_CONNECT && READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
switch (hci_skb_event(hdev->sent_cmd)) {
case HCI_EV_CONN_COMPLETE:
case HCI_EV_LE_CONN_COMPLETE:
diff --git a/net/bluetooth/hci_core.c b/net/bluetooth/hci_core.c
index 8ccec73dce45c..0f86b81b39730 100644
--- a/net/bluetooth/hci_core.c
+++ b/net/bluetooth/hci_core.c
@@ -4125,7 +4125,7 @@ static int hci_send_cmd_sync(struct hci_dev *hdev, struct sk_buff *skb)
kfree_skb(skb);
}
- if (hdev->req_status == HCI_REQ_PEND &&
+ if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND &&
!hci_dev_test_and_set_flag(hdev, HCI_CMD_PENDING)) {
kfree_skb(hdev->req_skb);
hdev->req_skb = skb_clone(hdev->sent_cmd, GFP_KERNEL);
diff --git a/net/bluetooth/hci_sync.c b/net/bluetooth/hci_sync.c
index 9a7bd4a4b14c4..f498ab28f1aa0 100644
--- a/net/bluetooth/hci_sync.c
+++ b/net/bluetooth/hci_sync.c
@@ -25,11 +25,11 @@ static void hci_cmd_sync_complete(struct hci_dev *hdev, u8 result, u16 opcode,
{
bt_dev_dbg(hdev, "result 0x%2.2x", result);
- if (hdev->req_status != HCI_REQ_PEND)
+ if (READ_ONCE(hdev->req_status) != HCI_REQ_PEND)
return;
hdev->req_result = result;
- hdev->req_status = HCI_REQ_DONE;
+ WRITE_ONCE(hdev->req_status, HCI_REQ_DONE);
/* Free the request command so it is not used as response */
kfree_skb(hdev->req_skb);
@@ -167,20 +167,20 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev, u16 opcode, u32 plen,
hci_cmd_sync_add(&req, opcode, plen, param, event, sk);
- hdev->req_status = HCI_REQ_PEND;
+ WRITE_ONCE(hdev->req_status, HCI_REQ_PEND);
err = hci_req_sync_run(&req);
if (err < 0)
return ERR_PTR(err);
err = wait_event_interruptible_timeout(hdev->req_wait_q,
- hdev->req_status != HCI_REQ_PEND,
+ READ_ONCE(hdev->req_status) != HCI_REQ_PEND,
timeout);
if (err == -ERESTARTSYS)
return ERR_PTR(-EINTR);
- switch (hdev->req_status) {
+ switch (READ_ONCE(hdev->req_status)) {
case HCI_REQ_DONE:
err = -bt_to_errno(hdev->req_result);
break;
@@ -194,7 +194,7 @@ struct sk_buff *__hci_cmd_sync_sk(struct hci_dev *hdev, u16 opcode, u32 plen,
break;
}
- hdev->req_status = 0;
+ WRITE_ONCE(hdev->req_status, 0);
hdev->req_result = 0;
skb = hdev->req_rsp;
hdev->req_rsp = NULL;
@@ -665,9 +665,9 @@ void hci_cmd_sync_cancel(struct hci_dev *hdev, int err)
{
bt_dev_dbg(hdev, "err 0x%2.2x", err);
- if (hdev->req_status == HCI_REQ_PEND) {
+ if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
hdev->req_result = err;
- hdev->req_status = HCI_REQ_CANCELED;
+ WRITE_ONCE(hdev->req_status, HCI_REQ_CANCELED);
queue_work(hdev->workqueue, &hdev->cmd_sync_cancel_work);
}
@@ -683,12 +683,12 @@ void hci_cmd_sync_cancel_sync(struct hci_dev *hdev, int err)
{
bt_dev_dbg(hdev, "err 0x%2.2x", err);
- if (hdev->req_status == HCI_REQ_PEND) {
+ if (READ_ONCE(hdev->req_status) == HCI_REQ_PEND) {
/* req_result is __u32 so error must be positive to be properly
* propagated.
*/
hdev->req_result = err < 0 ? -err : err;
- hdev->req_status = HCI_REQ_CANCELED;
+ WRITE_ONCE(hdev->req_status, HCI_REQ_CANCELED);
wake_up_interruptible(&hdev->req_wait_q);
}
--
2.53.0
^ permalink raw reply related
* [PATCH net] vsock/virtio: fix MSG_ZEROCOPY pinned-pages accounting
From: Stefano Garzarella @ 2026-04-20 13:20 UTC (permalink / raw)
To: netdev
Cc: Eric Dumazet, Simon Horman, Stefano Garzarella, kvm,
Arseniy Krasnov, David S. Miller, Paolo Abeni, Jakub Kicinski,
Michael S. Tsirkin, Jason Wang, virtualization, linux-kernel,
Eugenio Pérez, Xuan Zhuo, Stefan Hajnoczi, Yiming Qian
From: Stefano Garzarella <sgarzare@redhat.com>
virtio_transport_init_zcopy_skb() uses iter->count as the size argument
for msg_zerocopy_realloc(), which in turn passes it to
mm_account_pinned_pages() for RLIMIT_MEMLOCK accounting. However, this
function is called after virtio_transport_fill_skb() has already consumed
the iterator via __zerocopy_sg_from_iter(), so on the last skb, iter->count
will be 0, skipping the RLIMIT_MEMLOCK enforcement.
Pass pkt_len (the total bytes being sent) as an explicit parameter to
virtio_transport_init_zcopy_skb() instead of reading the already-consumed
iter->count.
This matches TCP and UDP, which both call msg_zerocopy_realloc() with
the original message size.
Fixes: 581512a6dc93 ("vsock/virtio: MSG_ZEROCOPY flag support")
Reported-by: Yiming Qian <yimingqian591@gmail.com>
Signed-off-by: Stefano Garzarella <sgarzare@redhat.com>
---
net/vmw_vsock/virtio_transport_common.c | 11 ++++++++---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/net/vmw_vsock/virtio_transport_common.c b/net/vmw_vsock/virtio_transport_common.c
index 0742091beae7..416d533f493d 100644
--- a/net/vmw_vsock/virtio_transport_common.c
+++ b/net/vmw_vsock/virtio_transport_common.c
@@ -73,6 +73,7 @@ static bool virtio_transport_can_zcopy(const struct virtio_transport *t_ops,
static int virtio_transport_init_zcopy_skb(struct vsock_sock *vsk,
struct sk_buff *skb,
struct msghdr *msg,
+ size_t pkt_len,
bool zerocopy)
{
struct ubuf_info *uarg;
@@ -81,12 +82,10 @@ static int virtio_transport_init_zcopy_skb(struct vsock_sock *vsk,
uarg = msg->msg_ubuf;
net_zcopy_get(uarg);
} else {
- struct iov_iter *iter = &msg->msg_iter;
struct ubuf_info_msgzc *uarg_zc;
uarg = msg_zerocopy_realloc(sk_vsock(vsk),
- iter->count,
- NULL, false);
+ pkt_len, NULL, false);
if (!uarg)
return -1;
@@ -398,11 +397,17 @@ static int virtio_transport_send_pkt_info(struct vsock_sock *vsk,
* each iteration. If this is last skb for this buffer
* and MSG_ZEROCOPY mode is in use - we must allocate
* completion for the current syscall.
+ *
+ * Pass pkt_len because msg iter is already consumed
+ * by virtio_transport_fill_skb(), so iter->count
+ * can not be used for RLIMIT_MEMLOCK pinned-pages
+ * accounting done by msg_zerocopy_realloc().
*/
if (info->msg && info->msg->msg_flags & MSG_ZEROCOPY &&
skb_len == rest_len && info->op == VIRTIO_VSOCK_OP_RW) {
if (virtio_transport_init_zcopy_skb(vsk, skb,
info->msg,
+ pkt_len,
can_zcopy)) {
kfree_skb(skb);
ret = -ENOMEM;
--
2.53.0
^ permalink raw reply related
* Re: [PATCH 6.6.y/6.1.y] net: add proper RCU protection to /proc/net/ptype
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: XiaoHua Wang; +Cc: Sasha Levin, stable, netdev, Eric Dumazet, Jakub Kicinski
In-Reply-To: <20260414121118.4227-1-561399680@139.com>
On Tue, Apr 14, 2026, XiaoHua Wang wrote:
> Backport of f613e8b4afea ("net: add proper RCU protection to
> /proc/net/ptype") to 6.6.y and 6.1.y.
Queued for 6.6 and 6.1, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 6.12.y/6.6.y/6.1.y] net: sched: fix TCF_LAYER_TRANSPORT handling in tcf_get_base_ptr()
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: Chelsy Ratnawat
Cc: Sasha Levin, stable, netdev, Jamal Hadi Salim, Cong Wang,
Jiri Pirko
In-Reply-To: <20260415214348.850171-1-chelsyratnawat2001@gmail.com>
On Wed, Apr 15, 2026, Chelsy Ratnawat wrote:
> Backport of 4fe5a00ec707 ("net: sched: fix TCF_LAYER_TRANSPORT
> handling in tcf_get_base_ptr()") to 6.12.y/6.6.y/6.1.y.
Queued for 6.12, 6.6, and 6.1, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 6.1.y 0/2] Backport 2 commits to 6.1.y to fix bond issue
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: Rajani Kantha; +Cc: Sasha Levin, stable, netdev, Jay Vosburgh, Andrew Lunn
In-Reply-To: <20260415091232.3244-1-681739313@139.com>
On Wed, Apr 15, 2026, Rajani Kantha wrote:
> Backport of 22ccb684c1ca ("bonding: return detailed error when
> loading native XDP fails") and 094ee6017ea0 ("bonding: check xdp
> prog when set bond mode") to 6.1.y.
Queued for 6.1, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 6.6.y] nfc: nci: complete pending data exchange on device close
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: Rajani Kantha; +Cc: Sasha Levin, stable, netdev, Krzysztof Kozlowski
In-Reply-To: <20260416081119.2197-1-681739313@139.com>
On Thu, Apr 16, 2026, Rajani Kantha wrote:
> Backport of 66083581945b ("nfc: nci: complete pending data exchange
> on device close") to 6.6.y.
Queued for 6.6, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 6.6.y] ice: Fix memory leak in ice_set_ringparam()
From: Sasha Levin @ 2026-04-20 13:21 UTC (permalink / raw)
To: Rajani Kantha; +Cc: Sasha Levin, stable, intel-wired-lan, netdev, Tony Nguyen
In-Reply-To: <20260417091753.4175-1-681739313@139.com>
On Fri, Apr 17, 2026, Rajani Kantha wrote:
> Backport of fe868b499d16 ("ice: Fix memory leak in
> ice_set_ringparam()") to 6.6.y.
Queued for 6.6, thanks.
--
Thanks,
Sasha
^ permalink raw reply
* [PATCH AUTOSEL 7.0-5.10] FDDI: defxx: Rate-limit memory allocation errors
From: Sasha Levin @ 2026-04-20 13:16 UTC (permalink / raw)
To: patches, stable
Cc: Maciej W. Rozycki, Andrew Lunn, Jakub Kicinski, Sasha Levin,
andrew+netdev, davem, edumazet, pabeni, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: "Maciej W. Rozycki" <macro@orcam.me.uk>
[ Upstream commit 7fae6616704a17c64438ad4b73a6effa6c03ffda ]
Prevent the system from becoming unstable or unusable due to a flood of
memory allocation error messages under memory pressure, e.g.:
[...]
fddi0: Could not allocate receive buffer. Dropping packet.
fddi0: Could not allocate receive buffer. Dropping packet.
fddi0: Could not allocate receive buffer. Dropping packet.
fddi0: Could not allocate receive buffer. Dropping packet.
rcu: INFO: rcu_sched self-detected stall on CPU
rcu: 0-...!: (332 ticks this GP) idle=255c/1/0x40000000 softirq=16420123/16420123 fqs=0
rcu: (t=2103 jiffies g=35680089 q=4 ncpus=1)
rcu: rcu_sched kthread timer wakeup didn't happen for 2102 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402
rcu: Possible timer handling issue on cpu=0 timer-softirq=12779658
rcu: rcu_sched kthread starved for 2103 jiffies! g35680089 f0x0 RCU_GP_WAIT_FQS(5) ->state=0x402 ->cpu=0
rcu: Unless rcu_sched kthread gets sufficient CPU time, OOM is now expected behavior.
rcu: RCU grace-period kthread stack dump:
task:rcu_sched state:I stack:0 pid:14 tgid:14 ppid:2 flags:0x00004000
Call Trace:
__schedule+0x258/0x580
schedule+0x19/0xa0
schedule_timeout+0x4a/0xb0
? hrtimers_cpu_dying+0x1b0/0x1b0
rcu_gp_fqs_loop+0xb1/0x450
rcu_gp_kthread+0x9d/0x130
kthread+0xb2/0xe0
? rcu_gp_init+0x4a0/0x4a0
? kthread_park+0x90/0x90
ret_from_fork+0x2d/0x50
? kthread_park+0x90/0x90
ret_from_fork_asm+0x12/0x20
entry_INT80_32+0x10d/0x10d
CPU: 0 UID: 500 PID: 21895 Comm: 31370.exe Not tainted 6.13.0-dirty #2
(here running the libstdc++-v3 testsuite).
Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/alpine.DEB.2.21.2603291236590.60268@angie.orcam.me.uk
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for a thorough analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: Subject Line
- **Subsystem:** `FDDI: defxx:` (FDDI network driver, DEC FDDI
controllers)
- **Action verb:** "Rate-limit" — this implies controlling the frequency
of something
- **Summary:** Rate-limit memory allocation error messages to prevent
system instability
### Step 1.2: Tags
- **Signed-off-by:** Maciej W. Rozycki `<macro@orcam.me.uk>` — **the
driver maintainer** (verified from line 24 of defxx.c)
- **Reviewed-by:** Andrew Lunn `<andrew@lunn.ch>` — well-known
networking reviewer
- **Link:** patch.msgid.link URL (lore.kernel.org was blocked by Anubis)
- **Signed-off-by:** Jakub Kicinski `<kuba@kernel.org>` — **the net
subsystem maintainer** (applied by him)
- No Fixes: tag, no Cc: stable, no Reported-by — expected for manual
review candidates
### Step 1.3: Commit Body
The commit describes a **real observed problem**: under memory pressure,
the unlimited `printk()` in the receive path floods the console so badly
that it causes:
- RCU stall (`rcu_sched self-detected stall on CPU`)
- RCU kthread starvation (`rcu_sched kthread starved for 2103 jiffies!`)
- System becoming "unstable or unusable"
- The message "Unless rcu_sched kthread gets sufficient CPU time, OOM is
now expected behavior"
A full stack trace is provided showing the real crash scenario. The
trigger was running the libstdc++-v3 testsuite, causing memory pressure
leading to allocation failures in the receive path.
### Step 1.4: Hidden Bug Fix Detection
This IS a bug fix, not a cosmetic change. The unlimited printk in a hot
interrupt-driven receive path causes:
1. Console flooding → CPU time consumed by printk
2. RCU stalls → system instability
3. Potential OOM due to RCU kthread starvation
The fix prevents a **soft lockup/RCU stall** which is a serious system
stability issue.
---
## PHASE 2: DIFF ANALYSIS
### Step 2.1: Inventory
- **Files changed:** 1 (`drivers/net/fddi/defxx.c`)
- **Lines changed:** 1 line modified (`printk` → `printk_ratelimited`)
- **Function modified:** `dfx_rcv_queue_process()`
- **Scope:** Single-file, single-line, surgical fix
### Step 2.2: Code Flow Change
- **Before:** Every failed `netdev_alloc_skb()` in the receive path
prints an unrestricted message via `printk()`
- **After:** The same message is printed via `printk_ratelimited()`,
which limits output to
DEFAULT_RATELIMIT_INTERVAL/DEFAULT_RATELIMIT_BURST (typically 5
seconds/10 messages)
- **Execution path affected:** The error/failure path within the
interrupt-driven packet receive handler
### Step 2.3: Bug Mechanism
This is a **system stability fix** — the unlimited printk in a hot path
(interrupt handler → receive queue processing) causes:
- Console output flooding
- CPU starvation for other kernel threads (RCU)
- RCU stalls leading to system hang
Category: **Performance/stability fix that prevents soft lockups and RCU
stalls** — this is a CRITICAL stability issue, not a mere optimization.
### Step 2.4: Fix Quality
- **Obviously correct:** Yes. `printk_ratelimited()` is a drop-in
replacement for `printk()` with rate limiting. It's a well-established
kernel API.
- **Minimal/surgical:** Yes — exactly 1 line changed, same format
string, same arguments.
- **Regression risk:** Virtually none. The only behavioral difference is
fewer log messages under sustained failure, which is the desired
behavior.
- **Red flags:** None.
---
## PHASE 3: GIT HISTORY
### Step 3.1: Blame
The buggy `printk` line dates back to commit `1da177e4c3f41` — the
**initial Linux git import** (April 2005, Linux 2.6.12-rc2). This code
has been present in every kernel version since the beginning of git
history, meaning **all active stable trees** contain this bug.
### Step 3.2: Fixes Tag
No Fixes: tag present (expected for manual review candidates).
### Step 3.3: File History
The file has had very few changes in recent history (only 1 change since
v6.1 — `HAS_IOPORT` dependencies). This means the fix will apply cleanly
to all stable trees.
### Step 3.4: Author
Maciej W. Rozycki is the **listed maintainer** of the defxx driver (line
24: "Maintainers: macro Maciej W. Rozycki <macro@orcam.me.uk>"). This is
a fix from the subsystem maintainer who encountered the issue firsthand.
### Step 3.5: Dependencies
None. `printk_ratelimited` has been available in the kernel since ~2010.
No prerequisites needed.
---
## PHASE 4: MAILING LIST RESEARCH
### Step 4.1-4.5
The lore.kernel.org and patch.msgid.link URLs were blocked by Anubis
anti-bot protection. However:
- The patch was **reviewed by Andrew Lunn** (well-known net reviewer)
- The patch was **applied by Jakub Kicinski** (net subsystem maintainer)
- The commit message includes a detailed real-world reproduction
scenario
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1: Key Functions
- `dfx_rcv_queue_process()` — the function where the change is made
### Step 5.2: Callers
- Called from `dfx_int_common()` (line 1889), which is the interrupt
service routine
- `dfx_int_common()` is called from `dfx_interrupt()` (lines 1972, 1998,
2023) — the hardware IRQ handler
- This is called on **every received packet interrupt**, making it a hot
path
### Step 5.3-5.4: Call Chain
The call chain is: `Hardware IRQ → dfx_interrupt() → dfx_int_common() →
dfx_rcv_queue_process() → [allocation failure] → printk()`
Under memory pressure, every incoming packet that fails allocation
triggers the printk. On an active FDDI network (100 Mbit/s), this could
be thousands of packets per second, each generating a printk call —
overwhelming the system.
### Step 5.5: Similar Patterns
There are many other `printk("Could not...")` calls in the driver (11
total), but only this one is in a hot interrupt-driven path where rapid
repetition is possible.
---
## PHASE 6: STABLE TREE ANALYSIS
### Step 6.1: Buggy Code in Stable Trees
The buggy code has been present since the initial git import (2005). It
exists in **all stable trees** (5.4.y, 5.10.y, 5.15.y, 6.1.y, 6.6.y,
6.12.y, etc.).
### Step 6.2: Backport Complications
The file has had minimal changes. The printk line is unchanged since
2005. The patch will apply **cleanly** to all active stable trees.
### Step 6.3: Related Fixes
No related fixes for this specific issue found in stable.
---
## PHASE 7: SUBSYSTEM CONTEXT
### Step 7.1: Subsystem
- **Path:** `drivers/net/fddi/` — FDDI networking driver
- **Criticality:** PERIPHERAL — FDDI is a legacy technology, but there
are real users (the maintainer himself encountered this bug while
testing)
### Step 7.2: Activity
Very low activity — the file has had only a handful of changes in recent
years. This is mature, stable code.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: Affected Population
Users of DEC FDDI controllers (DEFTA/DEFEA/DEFPA) under memory pressure.
While this is a niche user base, the fix is risk-free for everyone.
### Step 8.2: Trigger Conditions
- System must be under memory pressure (allocation failures)
- FDDI interface must be receiving packets
- The combination causes printk flooding → RCU stalls → system hang
- Triggered in real life (libstdc++ testsuite causing memory pressure)
### Step 8.3: Failure Mode Severity
- **RCU stall / soft lockup → CRITICAL** (system becomes
unusable/unstable)
- Can lead to OOM as stated in the RCU warning
- Data loss risk from system hang
### Step 8.4: Risk-Benefit Ratio
- **Benefit:** Prevents system hang/RCU stall under memory pressure —
HIGH
- **Risk:** 1 line change, `printk` → `printk_ratelimited`, well-
established API — VERY LOW
- **Ratio:** Strongly favorable
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: Evidence Compilation
**FOR backporting:**
- Fixes a real RCU stall / system instability issue with concrete
reproduction
- Single-line, obviously correct change (`printk` →
`printk_ratelimited`)
- Fix is from the driver maintainer who observed the bug firsthand
- Reviewed by Andrew Lunn, applied by Jakub Kicinski (net maintainer)
- Buggy code exists in all stable trees since 2005
- Patch applies cleanly — no dependencies, no conflicts expected
- Zero regression risk
**AGAINST backporting:**
- FDDI is a legacy/niche technology with a small user base
- The trigger requires specific conditions (memory pressure + active
FDDI traffic)
### Step 9.2: Stable Rules Checklist
1. **Obviously correct and tested?** YES — author encountered and
reproduced it; 1-line drop-in replacement
2. **Fixes a real bug?** YES — RCU stall / system hang under memory
pressure
3. **Important issue?** YES — system instability, RCU stalls, potential
OOM
4. **Small and contained?** YES — single line change in a single file
5. **No new features or APIs?** YES — no new features
6. **Can apply to stable trees?** YES — code unchanged since 2005, clean
apply expected
### Step 9.3: Exception Categories
Not an exception category — this is a straightforward bug fix.
### Step 9.4: Decision
This is a minimal, zero-risk fix for a real system stability issue (RCU
stalls). It meets all stable kernel criteria.
---
## Verification
- [Phase 1] Parsed tags: Reviewed-by Andrew Lunn, applied by Jakub
Kicinski (net maintainer SOB)
- [Phase 1] Commit body includes full RCU stall stack trace
demonstrating the real-world bug
- [Phase 2] Diff: exactly 1 line changed in `dfx_rcv_queue_process()`,
`printk` → `printk_ratelimited`
- [Phase 3] git blame: buggy printk line from `1da177e4c3f41` (initial
git import, 2005), present in all stable trees
- [Phase 3] git log --author: Maciej W. Rozycki is the driver maintainer
(confirmed from file header line 24)
- [Phase 3] git log v6.6../v6.1../v5.15.. -- defxx.c: minimal changes,
patch will apply cleanly
- [Phase 4] b4 dig and WebFetch: lore blocked by Anubis; could not
verify mailing list discussion directly
- [Phase 5] Callers traced: `dfx_interrupt()` → `dfx_int_common()` →
`dfx_rcv_queue_process()` — this is a hardware IRQ path, hot path for
every received packet
- [Phase 5] Grep confirmed: `printk_ratelimited` is a well-established
macro in `include/linux/printk.h`
- [Phase 6] Code present in all stable trees (unchanged since 2005)
- [Phase 8] Failure mode: RCU stall → system hang, severity CRITICAL
- UNVERIFIED: Could not access lore.kernel.org discussion due to Anubis
protection; however, the commit message and review tags provide
sufficient evidence
**YES**
drivers/net/fddi/defxx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/fddi/defxx.c b/drivers/net/fddi/defxx.c
index 0fbbb7286008d..6b8cfbee3b9d6 100644
--- a/drivers/net/fddi/defxx.c
+++ b/drivers/net/fddi/defxx.c
@@ -3182,7 +3182,7 @@ static void dfx_rcv_queue_process(
pkt_len + 3);
if (skb == NULL)
{
- printk("%s: Could not allocate receive buffer. Dropping packet.\n", bp->dev->name);
+ printk_ratelimited("%s: Could not allocate receive buffer. Dropping packet.\n", bp->dev->name);
bp->rcv_discards++;
break;
}
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] xsk: fix XDP_UMEM_SG_FLAG issues
From: Sasha Levin @ 2026-04-20 13:16 UTC (permalink / raw)
To: patches, stable
Cc: Maciej Fijalkowski, Björn Töpel, Jakub Kicinski,
Sasha Levin, magnus.karlsson, davem, edumazet, pabeni, ast,
tirthendu.sarkar, netdev, bpf, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
[ Upstream commit 93e84fe45b752d17a5a46b306ed78f0133bbc719 ]
Currently xp_assign_dev_shared() is missing XDP_USE_SG being propagated
to flags so set it in order to preserve mtu check that is supposed to be
done only when no multi-buffer setup is in picture.
Also, this flag has the same value as XDP_UMEM_TX_SW_CSUM so we could
get unexpected SG setups for software Tx checksums. Since csum flag is
UAPI, modify value of XDP_UMEM_SG_FLAG.
Fixes: d609f3d228a8 ("xsk: add multi-buffer support for sockets sharing umem")
Reviewed-by: Björn Töpel <bjorn@kernel.org>
Signed-off-by: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
Link: https://patch.msgid.link/20260402154958.562179-4-maciej.fijalkowski@intel.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
include/net/xdp_sock.h | 2 +-
net/xdp/xsk_buff_pool.c | 4 ++++
2 files changed, 5 insertions(+), 1 deletion(-)
diff --git a/include/net/xdp_sock.h b/include/net/xdp_sock.h
index ce587a2256618..7c2bc46c67050 100644
--- a/include/net/xdp_sock.h
+++ b/include/net/xdp_sock.h
@@ -14,7 +14,7 @@
#include <linux/mm.h>
#include <net/sock.h>
-#define XDP_UMEM_SG_FLAG (1 << 1)
+#define XDP_UMEM_SG_FLAG BIT(3)
struct net_device;
struct xsk_queue;
diff --git a/net/xdp/xsk_buff_pool.c b/net/xdp/xsk_buff_pool.c
index aa9788f20d0db..677c7d00f8c32 100644
--- a/net/xdp/xsk_buff_pool.c
+++ b/net/xdp/xsk_buff_pool.c
@@ -259,6 +259,10 @@ int xp_assign_dev_shared(struct xsk_buff_pool *pool, struct xdp_sock *umem_xs,
return -EINVAL;
flags = umem->zc ? XDP_ZEROCOPY : XDP_COPY;
+
+ if (umem->flags & XDP_UMEM_SG_FLAG)
+ flags |= XDP_USE_SG;
+
if (umem_xs->pool->uses_need_wakeup)
flags |= XDP_USE_NEED_WAKEUP;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] net: rose: reject truncated CLEAR_REQUEST frames in state machines
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Mashiro Chen, Jakub Kicinski, Sasha Levin, davem, edumazet,
pabeni, linux-hams, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Mashiro Chen <mashiro.chen@mailbox.org>
[ Upstream commit 2835750dd6475a5ddc116be0b4c81fee8ce1a902 ]
All five ROSE state machines (states 1-5) handle ROSE_CLEAR_REQUEST
by reading the cause and diagnostic bytes directly from skb->data[3]
and skb->data[4] without verifying that the frame is long enough:
rose_disconnect(sk, ..., skb->data[3], skb->data[4]);
The entry-point check in rose_route_frame() only enforces
ROSE_MIN_LEN (3 bytes), so a remote peer on a ROSE network can
send a syntactically valid but truncated CLEAR_REQUEST (3 or 4
bytes) while a connection is open in any state. Processing such a
frame causes a one- or two-byte out-of-bounds read past the skb
data, leaking uninitialized heap content as the cause/diagnostic
values returned to user space via getsockopt(ROSE_GETCAUSE).
Add a single length check at the rose_process_rx_frame() dispatch
point, before any state machine is entered, to drop frames that
carry the CLEAR_REQUEST type code but are too short to contain the
required cause and diagnostic fields.
Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>
Link: https://patch.msgid.link/20260408172551.281486-1-mashiro.chen@mailbox.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
I now have all the information needed for a complete analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: PARSE THE SUBJECT LINE**
- Subsystem: `net: rose:`
- Action verb: "reject" (implies adding a safety check / validation — a
bug fix)
- Summary: Reject truncated CLEAR_REQUEST frames to prevent out-of-
bounds read
Record: [net: rose] [reject] [Add length validation for CLEAR_REQUEST
frames to prevent OOB read]
**Step 1.2: PARSE ALL COMMIT MESSAGE TAGS**
- `Signed-off-by: Mashiro Chen <mashiro.chen@mailbox.org>` — author
- `Link: https://patch.msgid.link/20260408172551.281486-1-
mashiro.chen@mailbox.org` — original patch submission
- `Signed-off-by: Jakub Kicinski <kuba@kernel.org>` — network maintainer
(committed the patch)
- No Fixes: tag (expected for this review pipeline)
- No Reported-by: tag
- No Cc: stable tag
Record: Patch accepted by Jakub Kicinski (net maintainer). Single
standalone patch (not part of a series).
**Step 1.3: ANALYZE THE COMMIT BODY TEXT**
The commit body clearly describes:
- **Bug**: All five ROSE state machines (states 1-5) handle
ROSE_CLEAR_REQUEST by reading `skb->data[3]` and `skb->data[4]`
without verifying the frame is long enough.
- **Root cause**: `rose_route_frame()` only enforces `ROSE_MIN_LEN` (3
bytes), but `data[3]` and `data[4]` need at least 5 bytes.
- **Trigger**: A remote peer on a ROSE network can send a 3- or 4-byte
CLEAR_REQUEST.
- **Consequence**: 1-2 byte out-of-bounds read past skb data, leaking
uninitialized heap content as cause/diagnostic values returned to
userspace via `getsockopt(ROSE_GETCAUSE)`.
Record: OOB read vulnerability. Remote trigger. Info leak to userspace.
Clear mechanism explained.
**Step 1.4: DETECT HIDDEN BUG FIXES**
This is not hidden — it's an explicit security/memory safety bug fix.
The word "reject" means "add missing input validation."
Record: Explicit bug fix, not disguised.
---
## PHASE 2: DIFF ANALYSIS
**Step 2.1: INVENTORY THE CHANGES**
- 1 file changed: `net/rose/rose_in.c`
- +7 lines added (5 lines comment + 2 lines of code)
- Function modified: `rose_process_rx_frame()`
- Scope: Single-file surgical fix
Record: [net/rose/rose_in.c +7/-0] [rose_process_rx_frame] [Single-file
surgical fix]
**Step 2.2: UNDERSTAND THE CODE FLOW CHANGE**
- **Before**: After `rose_decode()` returns the frametype, the code
dispatches directly to state machines. If `frametype ==
ROSE_CLEAR_REQUEST` and `skb->len < 5`, the state machines would read
`skb->data[3]` and `skb->data[4]` beyond the buffer.
- **After**: A length check drops CLEAR_REQUEST frames shorter than 5
bytes before any state machine is entered. This prevents the OOB
access in all 5 state machines with one check.
Record: [Before: no length validation for CLEAR_REQUEST → OOB read |
After: reject truncated frames early]
**Step 2.3: IDENTIFY THE BUG MECHANISM**
Category: **Memory safety fix — out-of-bounds read**
- The frame minimum is 3 bytes (`ROSE_MIN_LEN = 3`)
- `ROSE_CLEAR_REQUEST` needs bytes at offsets 3 and 4 (requiring 5
bytes)
- All five state machines access `skb->data[3]` and `skb->data[4]` when
handling CLEAR_REQUEST
- The OOB-read values are stored in `rose->cause` and
`rose->diagnostic`, which are exposed to userspace via `SIOCRSGCAUSE`
ioctl
Record: [OOB read, 1-2 bytes past skb data] [Remote trigger via
malformed ROSE frame] [Info leak to userspace via ioctl]
**Step 2.4: ASSESS THE FIX QUALITY**
- Obviously correct: The check is trivially verifiable — CLEAR_REQUEST
needs bytes at index 3 and 4, so minimum length must be 5.
- Minimal/surgical: 2 lines of actual code + comment, at a single
dispatch point that covers all 5 state machines.
- Regression risk: Near zero. It only drops malformed frames that would
cause OOB access anyway.
- No side effects: Returns 0 (drops the frame silently), which is the
standard behavior for invalid frames.
Record: [Obviously correct, minimal, near-zero regression risk]
---
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: BLAME THE CHANGED LINES**
Git blame shows the vulnerable `skb->data[3]` / `skb->data[4]` accesses
originate from commit `1da177e4c3f41` — **Linux 2.6.12-rc2 (April
2005)**. This is the initial import of the Linux kernel into git. The
bug has existed since the very beginning of the ROSE protocol
implementation.
Record: [Buggy code from Linux 2.6.12-rc2 (2005)] [Present in ALL stable
trees]
**Step 3.2: FOLLOW THE FIXES TAG**
No Fixes: tag present (expected). Based on blame, the theoretical Fixes:
target would be `1da177e4c3f41 ("Linux-2.6.12-rc2")`.
Record: [Bug exists since initial kernel git import, affects all stable
trees]
**Step 3.3: CHECK FILE HISTORY FOR RELATED CHANGES**
Recent changes to `rose_in.c` are minimal: `d860d1faa6b2c` (refcount
conversion), `a6f190630d070` (drop reason tracking), `b6459415b384c`
(include fix). None conflict with this fix. The fix applies cleanly with
no dependencies.
Record: [No conflicting changes, standalone fix, no dependencies]
**Step 3.4: CHECK THE AUTHOR**
Mashiro Chen has other ROSE/hamradio-related patches (visible in the
.mbx files in the workspace: `v2_20260409_mashiro_chen_net_hamradio_fix_
missing_input_validation_in_bpqether_and_scc.mbx`). The patch was
accepted by Jakub Kicinski, the network subsystem maintainer.
Record: [Author contributes to amateur radio subsystem, patch accepted
by net maintainer]
**Step 3.5: CHECK FOR DEPENDENT/PREREQUISITE COMMITS**
The fix only uses `frametype`, `ROSE_CLEAR_REQUEST`, and `skb->len` —
all of which have existed since the file's creation. No dependencies.
Record: [No dependencies. Applies standalone to any kernel version.]
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
**Step 4.1-4.2: FIND ORIGINAL PATCH DISCUSSION**
b4 dig could not find the exact match (possibly too recent or the commit
hash `028ef9c96e961` is the Linux 7.0 tag, not the fix commit). However,
the Link tag points to
`patch.msgid.link/20260408172551.281486-1-mashiro.chen@mailbox.org`, and
the patch was signed off by Jakub Kicinski, confirming acceptance by the
net maintainer.
Record: [b4 dig could not match (HEAD is Linux 7.0 tag)] [Patch accepted
by Jakub Kicinski (net maintainer)]
**Step 4.3-4.5**: Lore is behind Anubis protection, preventing direct
fetching. But the commit message is detailed enough to fully understand
the bug.
Record: [Lore inaccessible due to bot protection] [Commit message
provides complete technical detail]
---
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: KEY FUNCTIONS**
Modified function: `rose_process_rx_frame()`
**Step 5.2: CALLERS**
`rose_process_rx_frame()` is called from:
1. `rose_route_frame()` in `rose_route.c:944` — the main frame routing
entry point from AX.25
2. `rose_loopback_dequeue()` in `rose_loopback.c:93` — the loopback
queue processor
Both callers only enforce `ROSE_MIN_LEN` (3 bytes) before calling,
confirming the vulnerability.
**Step 5.3: CALLEES**
The state machine functions (`rose_state1_machine` through
`rose_state5_machine`) are callees. All five access `skb->data[3]` and
`skb->data[4]` for CLEAR_REQUEST, making the single check at the
dispatch point the optimal fix location.
**Step 5.4: CALL CHAIN / REACHABILITY**
- `rose_route_frame()` is the AX.25 protocol handler for ROSE
(`rose_pid.func = rose_route_frame`), registered at module load via
`ax25_protocol_register()`. This is directly reachable from network
input — a remote peer on a ROSE network can send malformed frames.
- `rose_loopback_dequeue()` processes locally-queued frames. Also
reachable.
Record: [Remotely triggerable via ROSE network frames. Both entry paths
affected.]
**Step 5.5: USER DATA LEAK PATH**
Verified: `rose_disconnect()` stores the OOB-read values in
`rose->cause` and `rose->diagnostic`. The `SIOCRSGCAUSE` ioctl in
`af_rose.c:1389-1393` copies these to userspace via `copy_to_user()`.
This completes the info leak chain from OOB kernel heap read to
userspace.
Record: [Complete info leak chain verified: OOB read →
rose->cause/diagnostic → ioctl → userspace]
---
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
**Step 6.1: DOES THE BUGGY CODE EXIST IN STABLE TREES?**
The buggy code dates from Linux 2.6.12-rc2 (2005). Very few changes have
been made to `rose_in.c` across kernel versions. Since v5.15, only 3
unrelated commits touched this file (include changes, pfmemalloc
tracking, refcount conversion). The vulnerable
`skb->data[3]`/`skb->data[4]` accesses are present in ALL active stable
trees.
Record: [Bug present in all stable trees: 5.4.y, 5.10.y, 5.15.y, 6.1.y,
6.6.y, 6.12.y]
**Step 6.2: BACKPORT COMPLICATIONS**
The fix patches the `rose_process_rx_frame()` function which has been
nearly unchanged since 2005. The recent `d860d1faa6b2c` (refcount_t
conversion) doesn't affect the patch point. This will apply cleanly to
all stable trees.
Record: [Clean apply expected for all stable trees]
**Step 6.3: RELATED FIXES IN STABLE**
No related fix for this specific OOB read issue exists in any stable
tree.
Record: [No prior fix for this bug]
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: SUBSYSTEM CRITICALITY**
- Subsystem: `net/rose/` — ROSE (Radio Over Serial Ethernet) amateur
radio protocol
- Criticality: PERIPHERAL (niche protocol used by amateur radio
operators)
- However: This is a network protocol reachable from external input,
making it security-relevant despite limited user base.
Record: [net/rose — peripheral subsystem but remotely triggerable,
security-relevant]
**Step 7.2: SUBSYSTEM ACTIVITY**
The ROSE subsystem is mature/stable — minimal development activity. The
file has only had trivial/treewide changes since 2005. This means the
bug has been present for ~21 years.
Record: [Very mature code, minimal activity, bug present for 21 years]
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: WHO IS AFFECTED**
Users with `CONFIG_ROSE` enabled who have ROSE sockets open. This is
primarily amateur radio operators using AX.25/ROSE networking.
Record: [Affected: systems with CONFIG_ROSE enabled and active ROSE
connections]
**Step 8.2: TRIGGER CONDITIONS**
- **Remote trigger**: A peer on a ROSE network sends a 3- or 4-byte
frame with frametype byte 0x13 (CLEAR_REQUEST)
- **No authentication needed**: Any ROSE peer can send this
- **Deterministic**: Not a race condition — always triggers on receipt
of truncated frame
- **Any connection state**: All 5 state machines are vulnerable
Record: [Remotely triggerable, no authentication, deterministic, any
connection state]
**Step 8.3: FAILURE MODE SEVERITY**
- **OOB read**: 1-2 bytes read past allocated skb data — reads
uninitialized heap memory
- **Info leak to userspace**: The leaked bytes are stored in
`rose->cause`/`rose->diagnostic` and returned via `SIOCRSGCAUSE` ioctl
- Severity: **HIGH** — kernel heap info leak reachable from network
input
Record: [Severity: HIGH — remotely-triggered kernel heap info leak]
**Step 8.4: RISK-BENEFIT RATIO**
- **Benefit**: Fixes a remotely-triggered OOB read / kernel info leak in
a 21-year-old bug
- **Risk**: 2 lines of code, obviously correct bounds check, zero
regression potential
- **Ratio**: Extremely favorable — maximum benefit, minimum risk
Record: [Benefit: HIGH (security fix) | Risk: VERY LOW (2 lines,
trivially correct) | Ratio: Strongly favorable]
---
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: COMPILE THE EVIDENCE**
Evidence FOR backporting:
- Fixes a remotely-triggerable out-of-bounds read (security
vulnerability)
- Kernel heap info leak to userspace via ioctl (complete exploit chain
verified)
- Bug present since Linux 2.6.12 (2005) — affects ALL stable trees
- Fix is 2 lines of code, obviously correct
- No dependencies, applies cleanly to all stable trees
- Accepted by net maintainer Jakub Kicinski
- Single centralized check covers all 5 vulnerable state machines
Evidence AGAINST backporting:
- ROSE is a niche protocol (limited user base)
- No Fixes: tag (expected)
Unresolved:
- Could not access lore discussion (Anubis protection)
**Step 9.2: STABLE RULES CHECKLIST**
1. Obviously correct and tested? **YES** — trivial bounds check,
accepted by net maintainer
2. Fixes a real bug? **YES** — OOB read with info leak to userspace
3. Important issue? **YES** — security vulnerability (remotely-triggered
kernel info leak)
4. Small and contained? **YES** — 7 lines added (2 code + 5 comment),
single file
5. No new features or APIs? **YES** — only adds validation
6. Can apply to stable trees? **YES** — no conflicting changes, code
unchanged since 2005
**Step 9.3: EXCEPTION CATEGORIES**
Not an exception category — this is a standard security bug fix, which
is core stable material.
**Step 9.4: DECISION**
This is a textbook stable backport candidate: a small, obvious security
fix for a remotely-triggerable OOB read that has been present for 21
years in all kernel versions.
---
## Verification
- [Phase 1] Parsed tags: Signed-off-by Jakub Kicinski (net maintainer),
Link to original patch
- [Phase 2] Diff analysis: +7 lines (2 code + 5 comment) in
rose_process_rx_frame(), adds `skb->len < 5` check for CLEAR_REQUEST
- [Phase 2] Verified all 5 state machines access `skb->data[3]` and
`skb->data[4]` for CLEAR_REQUEST (lines 58, 81, 123, 236, 256 of
rose_in.c)
- [Phase 3] git blame: buggy code from `1da177e4c3f41` (Linux
2.6.12-rc2, April 2005), present in all stable trees
- [Phase 3] git log: only 3 unrelated changes to rose_in.c since v5.15,
fix applies cleanly
- [Phase 4] b4 dig: could not match (HEAD is Linux 7.0 tag, not the fix
commit)
- [Phase 4] UNVERIFIED: Full lore discussion (Anubis protection blocked
access)
- [Phase 5] Verified callers: rose_route_frame() and
rose_loopback_dequeue() both only check ROSE_MIN_LEN (3 bytes)
- [Phase 5] Verified info leak chain: OOB values →
rose->cause/diagnostic → SIOCRSGCAUSE ioctl → copy_to_user
- [Phase 5] Verified ROSE_MIN_LEN = 3 and ROSE_CLEAR_REQUEST = 0x13 in
include/net/rose.h
- [Phase 6] Code exists unchanged in all active stable trees (v5.4+)
- [Phase 7] net/rose is peripheral but network-reachable (security-
relevant)
- [Phase 8] Failure mode: remotely-triggered kernel heap OOB read with
info leak to userspace, severity HIGH
**YES**
net/rose/rose_in.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/net/rose/rose_in.c b/net/rose/rose_in.c
index 0276b393f0e53..e268005819627 100644
--- a/net/rose/rose_in.c
+++ b/net/rose/rose_in.c
@@ -271,6 +271,13 @@ int rose_process_rx_frame(struct sock *sk, struct sk_buff *skb)
frametype = rose_decode(skb, &ns, &nr, &q, &d, &m);
+ /*
+ * ROSE_CLEAR_REQUEST carries cause and diagnostic in bytes 3..4.
+ * Reject a malformed frame that is too short to contain them.
+ */
+ if (frametype == ROSE_CLEAR_REQUEST && skb->len < 5)
+ return 0;
+
switch (rose->state) {
case ROSE_STATE_1:
queued = rose_state1_machine(sk, skb, frametype);
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] netfilter: nfnetlink_queue: nfqnl_instance GFP_ATOMIC -> GFP_KERNEL_ACCOUNT allocation
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Scott Mitchell, Florian Westphal, Sasha Levin, pablo, davem,
edumazet, kuba, pabeni, netfilter-devel, coreteam, netdev,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Scott Mitchell <scott.k.mitch1@gmail.com>
[ Upstream commit a4400a5b343d1bc4aa8f685608515413238e7ee2 ]
Currently, instance_create() uses GFP_ATOMIC because it's called while
holding instances_lock spinlock. This makes allocation more likely to
fail under memory pressure.
Refactor nfqnl_recv_config() to drop RCU lock after instance_lookup()
and peer_portid verification. A socket cannot simultaneously send a
message and close, so the queue owned by the sending socket cannot be
destroyed while processing its CONFIG message. This allows
instance_create() to allocate with GFP_KERNEL_ACCOUNT before taking
the spinlock.
Suggested-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Scott Mitchell <scott.k.mitch1@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Stable-dep-of: 936206e3f6ff ("netfilter: nfnetlink_queue: make hash table per queue")
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
net/netfilter/nfnetlink_queue.c | 75 +++++++++++++++------------------
1 file changed, 34 insertions(+), 41 deletions(-)
diff --git a/net/netfilter/nfnetlink_queue.c b/net/netfilter/nfnetlink_queue.c
index 0b96d20bacb73..a39d3b989063c 100644
--- a/net/netfilter/nfnetlink_queue.c
+++ b/net/netfilter/nfnetlink_queue.c
@@ -178,17 +178,9 @@ instance_create(struct nfnl_queue_net *q, u_int16_t queue_num, u32 portid)
unsigned int h;
int err;
- spin_lock(&q->instances_lock);
- if (instance_lookup(q, queue_num)) {
- err = -EEXIST;
- goto out_unlock;
- }
-
- inst = kzalloc(sizeof(*inst), GFP_ATOMIC);
- if (!inst) {
- err = -ENOMEM;
- goto out_unlock;
- }
+ inst = kzalloc(sizeof(*inst), GFP_KERNEL_ACCOUNT);
+ if (!inst)
+ return ERR_PTR(-ENOMEM);
inst->queue_num = queue_num;
inst->peer_portid = portid;
@@ -198,9 +190,15 @@ instance_create(struct nfnl_queue_net *q, u_int16_t queue_num, u32 portid)
spin_lock_init(&inst->lock);
INIT_LIST_HEAD(&inst->queue_list);
+ spin_lock(&q->instances_lock);
+ if (instance_lookup(q, queue_num)) {
+ err = -EEXIST;
+ goto out_unlock;
+ }
+
if (!try_module_get(THIS_MODULE)) {
err = -EAGAIN;
- goto out_free;
+ goto out_unlock;
}
h = instance_hashfn(queue_num);
@@ -210,10 +208,9 @@ instance_create(struct nfnl_queue_net *q, u_int16_t queue_num, u32 portid)
return inst;
-out_free:
- kfree(inst);
out_unlock:
spin_unlock(&q->instances_lock);
+ kfree(inst);
return ERR_PTR(err);
}
@@ -1604,7 +1601,8 @@ static int nfqnl_recv_config(struct sk_buff *skb, const struct nfnl_info *info,
struct nfqnl_msg_config_cmd *cmd = NULL;
struct nfqnl_instance *queue;
__u32 flags = 0, mask = 0;
- int ret = 0;
+
+ WARN_ON_ONCE(!lockdep_nfnl_is_held(NFNL_SUBSYS_QUEUE));
if (nfqa[NFQA_CFG_CMD]) {
cmd = nla_data(nfqa[NFQA_CFG_CMD]);
@@ -1650,47 +1648,44 @@ static int nfqnl_recv_config(struct sk_buff *skb, const struct nfnl_info *info,
}
}
+ /* Lookup queue under RCU. After peer_portid check (or for new queue
+ * in BIND case), the queue is owned by the socket sending this message.
+ * A socket cannot simultaneously send a message and close, so while
+ * processing this CONFIG message, nfqnl_rcv_nl_event() (triggered by
+ * socket close) cannot destroy this queue. Safe to use without RCU.
+ */
rcu_read_lock();
queue = instance_lookup(q, queue_num);
if (queue && queue->peer_portid != NETLINK_CB(skb).portid) {
- ret = -EPERM;
- goto err_out_unlock;
+ rcu_read_unlock();
+ return -EPERM;
}
+ rcu_read_unlock();
if (cmd != NULL) {
switch (cmd->command) {
case NFQNL_CFG_CMD_BIND:
- if (queue) {
- ret = -EBUSY;
- goto err_out_unlock;
- }
- queue = instance_create(q, queue_num,
- NETLINK_CB(skb).portid);
- if (IS_ERR(queue)) {
- ret = PTR_ERR(queue);
- goto err_out_unlock;
- }
+ if (queue)
+ return -EBUSY;
+ queue = instance_create(q, queue_num, NETLINK_CB(skb).portid);
+ if (IS_ERR(queue))
+ return PTR_ERR(queue);
break;
case NFQNL_CFG_CMD_UNBIND:
- if (!queue) {
- ret = -ENODEV;
- goto err_out_unlock;
- }
+ if (!queue)
+ return -ENODEV;
instance_destroy(q, queue);
- goto err_out_unlock;
+ return 0;
case NFQNL_CFG_CMD_PF_BIND:
case NFQNL_CFG_CMD_PF_UNBIND:
break;
default:
- ret = -ENOTSUPP;
- goto err_out_unlock;
+ return -EOPNOTSUPP;
}
}
- if (!queue) {
- ret = -ENODEV;
- goto err_out_unlock;
- }
+ if (!queue)
+ return -ENODEV;
if (nfqa[NFQA_CFG_PARAMS]) {
struct nfqnl_msg_config_params *params =
@@ -1715,9 +1710,7 @@ static int nfqnl_recv_config(struct sk_buff *skb, const struct nfnl_info *info,
spin_unlock_bh(&queue->lock);
}
-err_out_unlock:
- rcu_read_unlock();
- return ret;
+ return 0;
}
static const struct nfnl_callback nfqnl_cb[NFQNL_MSG_MAX] = {
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.18] net: mana: hardening: Validate adapter_mtu from MANA_QUERY_DEV_CONFIG
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Erni Sri Satya Vennela, Jakub Kicinski, Sasha Levin, kys,
haiyangz, wei.liu, decui, longli, andrew+netdev, davem, edumazet,
pabeni, linux-hyperv, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
[ Upstream commit d7709812e13d06132ddae3d21540472ea5cb11c5 ]
As a part of MANA hardening for CVM, validate the adapter_mtu value
returned from the MANA_QUERY_DEV_CONFIG HWC command.
The adapter_mtu value is used to compute ndev->max_mtu via:
gc->adapter_mtu - ETH_HLEN. If hardware returns a bogus adapter_mtu
smaller than ETH_HLEN (e.g. 0), the unsigned subtraction wraps to a
huge value, silently allowing oversized MTU settings.
Add a validation check to reject adapter_mtu values below
ETH_MIN_MTU + ETH_HLEN, returning -EPROTO to fail the device
configuration early with a clear error message.
Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>
Link: https://patch.msgid.link/20260326173101.2010514-1-ernis@linux.microsoft.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
This confirms the integer underflow. Now let me complete the analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
**Step 1.1: Subject Line**
- Subsystem: `net: mana:` (Microsoft Azure Network Adapter driver)
- Action: "hardening: Validate" - input validation / defensive check
- Summary: Validates `adapter_mtu` from hardware config query to prevent
integer underflow
**Step 1.2: Tags**
- `Signed-off-by: Erni Sri Satya Vennela <ernis@linux.microsoft.com>` -
author, Microsoft employee, regular MANA contributor (9+ commits)
- `Link: https://patch.msgid.link/20260326173101.2010514-1-
ernis@linux.microsoft.com` - single patch (not part of a series,
1-of-1)
- `Signed-off-by: Jakub Kicinski <kuba@kernel.org>` - netdev maintainer
accepted the patch
- No Fixes: tag (expected for candidates under review)
- No Reported-by tag
- No Cc: stable tag
**Step 1.3: Body Text**
- Bug: `adapter_mtu` value from hardware can be bogus (< ETH_HLEN = 14).
The subtraction `gc->adapter_mtu - ETH_HLEN` used to compute
`ndev->max_mtu` wraps to a huge value (~4GB), silently allowing
oversized MTU settings.
- Context: Part of CVM (Confidential VM) hardening where the hypervisor
is less trusted.
- Fix: Reject values below `ETH_MIN_MTU + ETH_HLEN` (82 bytes) with
`-EPROTO`.
**Step 1.4: Hidden Bug Fix Detection**
- Though labeled "hardening," this IS a real bug fix: it prevents a
concrete integer underflow that leads to incorrect max_mtu. The bug
mechanism is clear and the consequences (allowing oversized MTU
settings) are real.
## PHASE 2: DIFF ANALYSIS
**Step 2.1: Inventory**
- Files: `drivers/net/ethernet/microsoft/mana/mana_en.c` (+8/-2 net, ~6
lines of logic)
- Function modified: `mana_query_device_cfg()`
- Scope: Single-file, single-function, surgical fix
**Step 2.2: Code Flow Change**
- Before: `resp.adapter_mtu` was accepted unconditionally when
msg_version >= GDMA_MESSAGE_V2
- After: Validates `resp.adapter_mtu >= ETH_MIN_MTU + ETH_HLEN` (82)
before accepting; returns `-EPROTO` on failure
- The else branch and brace additions are purely cosmetic (adding braces
to existing if/else)
**Step 2.3: Bug Mechanism**
- Category: Integer underflow / input validation bug
- Mechanism: `gc->adapter_mtu` (u16, could be 0) used in `ndev->max_mtu
= gc->adapter_mtu - ETH_HLEN`. If adapter_mtu < 14, the result wraps
to ~4GB as unsigned int.
- Confirmed via two usage sites:
- `mana_en.c:3349`: `ndev->max_mtu = gc->adapter_mtu - ETH_HLEN`
- `mana_bpf.c:242`: `ndev->max_mtu = gc->adapter_mtu - ETH_HLEN`
**Step 2.4: Fix Quality**
- Obviously correct: simple bounds check with a clear threshold
- Minimal: 6 lines of logic change
- No regression risk: only rejects values that would cause incorrect
behavior anyway
- Clean: well-contained, single function
## PHASE 3: GIT HISTORY INVESTIGATION
**Step 3.1: Blame**
- The `adapter_mtu` field assignment was introduced in commit
`80f6215b450eb8` ("net: mana: Add support for jumbo frame", Haiyang
Zhang, 2023-04-12)
- This commit was first included in `v6.4-rc1`
- The vulnerable code has been present since v6.4
**Step 3.2: No Fixes: tag to follow**
**Step 3.3: File History**
- The file has active development with multiple fixes applied. No
conflicting changes to the `mana_query_device_cfg()` function recently
aside from commit `290e5d3c49f687` which added GDMA_MESSAGE_V3
handling.
**Step 3.4: Author**
- Erni Sri Satya Vennela is a regular MANA contributor with 9+ commits
to the driver, all from `@linux.microsoft.com`. The author is part of
the Microsoft team maintaining this driver.
**Step 3.5: Dependencies**
- This is a standalone patch (1-of-1, not part of a series)
- Uses only existing constants (`ETH_MIN_MTU`, `ETH_HLEN`) which exist
in all kernel versions
- The GDMA_MESSAGE_V2 check already exists in stable trees since v6.4
## PHASE 4: MAILING LIST RESEARCH
**Step 4.1-4.5:** b4 dig failed to find the thread. Lore is behind an
anti-scraping wall. However, the patch was accepted by netdev maintainer
Jakub Kicinski (signed-off-by), which indicates it passed netdev review.
The Link tag confirms it was a single-patch submission.
## PHASE 5: CODE SEMANTIC ANALYSIS
**Step 5.1: Functions Modified**
- `mana_query_device_cfg()` - device configuration query during probe
**Step 5.2: Callers**
- Called from `mana_probe_port()` -> `mana_query_device_cfg()` during
device initialization
- This is the main probe path for all MANA network interfaces in Azure
VMs
**Step 5.3: Downstream Impact**
- `gc->adapter_mtu` is used in two places to compute `ndev->max_mtu`:
- `mana_en.c:3349` during probe
- `mana_bpf.c:242` when XDP is detached
- Both perform `gc->adapter_mtu - ETH_HLEN` without checking for
underflow
**Step 5.4: Reachability**
- This code is reached during every MANA device probe in Azure VMs -
very common path for Azure users
## PHASE 6: STABLE TREE ANALYSIS
**Step 6.1: Buggy Code in Stable Trees**
- `adapter_mtu` was added in v6.4-rc1 via commit `80f6215b450eb8`
- Present in stable trees: 6.6.y, 6.12.y, 7.0.y
- NOT present in: 6.1.y, 5.15.y, 5.10.y (pre-dates adapter_mtu feature)
**Step 6.2: Backport Complications**
- Note: the current 7.0 tree has `resp.hdr.response.msg_version` (from
commit `290e5d3c49f687`) while older stable trees may have
`resp.hdr.resp.msg_version`. The diff may need minor adjustment for
6.6.y.
- The validation logic itself is self-contained and trivially adaptable.
**Step 6.3: No related fixes already in stable.**
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
**Step 7.1: Subsystem**
- `drivers/net/ethernet/microsoft/mana/` - MANA network driver for Azure
VMs
- Criticality: IMPORTANT - widely used in Azure cloud infrastructure
(millions of VMs)
**Step 7.2: Activity**
- Actively maintained with regular fixes. The author and team are
Microsoft employees dedicated to this driver.
## PHASE 8: IMPACT AND RISK ASSESSMENT
**Step 8.1: Who is Affected**
- All Azure VM users running MANA driver (very large population)
- Especially CVM (Confidential VM) users where the hypervisor is less
trusted
**Step 8.2: Trigger Conditions**
- Triggered when hardware/hypervisor returns `adapter_mtu < 82` in the
config query response
- In CVM scenarios: malicious hypervisor could deliberately trigger this
- In non-CVM: unlikely but possible with firmware bugs
**Step 8.3: Failure Mode Severity**
- Integer underflow causes `max_mtu` to be set to ~4GB
- This silently allows setting huge MTU values that the hardware cannot
support
- Could lead to packet corruption, buffer overflows in TX path, or
device malfunction
- Severity: HIGH (potential for data corruption or security issue,
especially in CVM)
**Step 8.4: Risk-Benefit Ratio**
- BENEFIT: Prevents integer underflow and incorrect device
configuration. HIGH for CVM users, MEDIUM for regular Azure users.
- RISK: VERY LOW - only adds a bounds check on the initialization path.
Cannot cause regression because it only rejects values that would
cause broken behavior.
## PHASE 9: FINAL SYNTHESIS
**Step 9.1: Evidence Summary**
FOR backporting:
- Fixes a concrete integer underflow bug (adapter_mtu - ETH_HLEN wraps
to ~4GB)
- Small, surgical fix (6 lines of logic)
- Obviously correct bounds check
- No regression risk
- Accepted by netdev maintainer
- Author is regular driver contributor
- Affects widely-used Azure MANA driver
- Security-relevant in CVM environments
AGAINST backporting:
- Labeled as "hardening" rather than "fix"
- No user reports of this being triggered in practice
- Trigger requires malicious or buggy firmware
- May need minor adjustment for older stable trees (response field name)
**Step 9.2: Stable Rules Checklist**
1. Obviously correct and tested? **YES** - simple bounds check, accepted
by netdev maintainer
2. Fixes a real bug? **YES** - integer underflow leading to incorrect
max_mtu
3. Important issue? **YES** - incorrect MTU can cause device
malfunction; security issue in CVM
4. Small and contained? **YES** - 6 lines, single function, single file
5. No new features or APIs? **CORRECT** - no new features
6. Can apply to stable? **YES** - may need trivial adjustment for
response field name in 6.6.y
**Step 9.3: Exception Categories**
- Not a standard exception category, but fits the pattern of input
validation fixes that prevent integer overflow/underflow.
**Step 9.4: Decision**
The fix prevents a concrete integer underflow that causes `max_mtu` to
be set to ~4GB when hardware returns an invalid adapter_mtu. The fix is
minimal, obviously correct, and has zero regression risk. It is relevant
for Azure CVM security and defensive against firmware bugs.
## Verification
- [Phase 1] Parsed tags: Signed-off-by from author (Microsoft) and
netdev maintainer Jakub Kicinski; Link to single-patch submission
- [Phase 2] Diff analysis: +6 lines of validation in
`mana_query_device_cfg()`, checks `resp.adapter_mtu >= ETH_MIN_MTU +
ETH_HLEN` (82)
- [Phase 2] Integer underflow verified: adapter_mtu=0 ->
max_mtu=4294967282 (~4GB) via Python simulation
- [Phase 3] git blame: adapter_mtu code introduced in commit
`80f6215b450eb8` (v6.4-rc1, 2023-04-12)
- [Phase 3] git describe --contains: confirmed in v6.4-rc1
- [Phase 3] Author has 9+ commits to MANA driver, regular contributor
- [Phase 4] b4 dig failed to find thread (timeout); lore blocked by
anti-bot measures
- [Phase 5] Callers: `mana_query_device_cfg()` called from probe path;
`gc->adapter_mtu - ETH_HLEN` used at mana_en.c:3349 and mana_bpf.c:242
- [Phase 5] Both usage sites perform unsigned subtraction without bounds
check
- [Phase 6] Buggy code exists in stable trees 6.6.y+ (since v6.4-rc1)
- [Phase 6] Standalone fix, may need minor field name adjustment for
older trees
- [Phase 7] MANA driver widely used in Azure (IMPORTANT criticality)
- [Phase 8] Failure mode: max_mtu set to ~4GB, allowing oversized MTU;
severity HIGH
- [Phase 8] Risk: VERY LOW (only rejects clearly invalid values)
**YES**
drivers/net/ethernet/microsoft/mana/mana_en.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/microsoft/mana/mana_en.c b/drivers/net/ethernet/microsoft/mana/mana_en.c
index 09a53c9775455..7589ead7efdb6 100644
--- a/drivers/net/ethernet/microsoft/mana/mana_en.c
+++ b/drivers/net/ethernet/microsoft/mana/mana_en.c
@@ -1214,10 +1214,16 @@ static int mana_query_device_cfg(struct mana_context *ac, u32 proto_major_ver,
*max_num_vports = resp.max_num_vports;
- if (resp.hdr.response.msg_version >= GDMA_MESSAGE_V2)
+ if (resp.hdr.response.msg_version >= GDMA_MESSAGE_V2) {
+ if (resp.adapter_mtu < ETH_MIN_MTU + ETH_HLEN) {
+ dev_err(dev, "Adapter MTU too small: %u\n",
+ resp.adapter_mtu);
+ return -EPROTO;
+ }
gc->adapter_mtu = resp.adapter_mtu;
- else
+ } else {
gc->adapter_mtu = ETH_FRAME_LEN;
+ }
if (resp.hdr.response.msg_version >= GDMA_MESSAGE_V3)
*bm_hostmode = resp.bm_hostmode;
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] enic: add V2 SR-IOV VF device ID
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Satish Kharat, Jakub Kicinski, Sasha Levin, andrew+netdev, davem,
edumazet, pabeni, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Satish Kharat <satishkh@cisco.com>
[ Upstream commit 803a1b02027918450b58803190aa7cacb8056265 ]
Register the V2 VF PCI device ID (0x02b7) so the driver binds to V2
virtual functions created via sriov_configure. Update enic_is_sriov_vf()
to recognize V2 VFs alongside the existing V1 type.
Signed-off-by: Satish Kharat <satishkh@cisco.com>
Link: https://patch.msgid.link/20260401-enic-sriov-v2-prep-v4-2-d5834b2ef1b9@cisco.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed for a comprehensive analysis. Let
me compile the full assessment.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: Subject Line
- **Subsystem**: `enic` (Cisco VIC Ethernet NIC driver,
`drivers/net/ethernet/cisco/enic/`)
- **Action verb**: "add" — adding a new device ID
- **Summary**: Add V2 SR-IOV VF PCI device ID to the enic driver
### Step 1.2: Tags
- **Signed-off-by**: Satish Kharat `<satishkh@cisco.com>` (author, Cisco
employee — the hardware vendor)
- **Link**: `https://patch.msgid.link/20260401-enic-
sriov-v2-prep-v4-2-d5834b2ef1b9@cisco.com` — patch 2 of series "enic-
sriov-v2-prep", version 4
- **Signed-off-by**: Jakub Kicinski `<kuba@kernel.org>` (networking
subsystem maintainer)
- No Fixes: tag, no Reported-by:, no Cc: stable — expected for this
review pipeline.
### Step 1.3: Commit Body
The commit body states: Register the V2 VF PCI device ID (0x02b7) so the
driver binds to V2 virtual functions created via `sriov_configure`.
Update `enic_is_sriov_vf()` to recognize V2 VFs alongside the existing
V1 type. Without this change, V2 VFs exposed by the hardware will not be
claimed by the enic driver at all.
### Step 1.4: Hidden Bug Fix Detection
This is a **device ID addition** — a well-known exception category.
Without this ID, users with V2 VF hardware cannot use SR-IOV on their
Cisco VIC adapters. This is a hardware enablement fix.
Record: [Device ID addition for hardware that the driver already
supports] [Not disguised — clearly a device ID add]
---
## PHASE 2: DIFF ANALYSIS
### Step 2.1: Inventory
- **File changed**: `drivers/net/ethernet/cisco/enic/enic_main.c`
(single file)
- **Lines added**: 3 functional lines
1. `#define PCI_DEVICE_ID_CISCO_VIC_ENET_VF_V2 0x02b7`
2. `{ PCI_VDEVICE(CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF_V2) },` in
the PCI ID table
3. `|| enic->pdev->device == PCI_DEVICE_ID_CISCO_VIC_ENET_VF_V2` in
`enic_is_sriov_vf()`
- **Scope**: Single-file, surgical, 3-line addition
### Step 2.2: Code Flow
- **Before**: Driver only recognized PCI device 0x0071 as an SR-IOV VF.
V2 VFs (0x02b7) were unrecognized.
- **After**: Driver recognizes both 0x0071 (V1) and 0x02b7 (V2) as SR-
IOV VFs. V2 VFs get identical treatment as V1 VFs.
- `enic_is_sriov_vf()` is called in 6 places throughout the driver to
branch behavior for VFs (MTU handling, MAC address, station address,
netdev_ops selection). All behave correctly with V2 VFs after this
change.
### Step 2.3: Bug Mechanism
- **Category**: Hardware workaround / Device ID addition (category h)
- Without the ID in `enic_id_table`, the PCI core won't bind the enic
driver to V2 VFs at all
- Without the `enic_is_sriov_vf()` update, even if bound, V2 VFs would
get incorrect PF (physical function) code paths
### Step 2.4: Fix Quality
- Obviously correct: mirrors the existing V1 VF pattern exactly
- Minimal and surgical: 3 lines
- Zero regression risk: only affects devices with PCI ID 0x02b7
- No API changes, no lock changes, no memory management changes
---
## PHASE 3: GIT HISTORY
### Step 3.1: Blame
- The original V1 VF support (PCI ID 0x0071) was added in commit
`3a4adef5c0adbb` by Roopa Prabhu in January 2012, over 14 years ago.
- The `enic_is_sriov_vf()` function and PCI ID table entry have been
untouched since then.
- The enic driver itself dates to 2008 (commit `01f2e4ead2c512`).
### Step 3.2: Fixes Tag
- No Fixes: tag (expected for device ID additions).
### Step 3.3: File History
- Recent commits to `enic_main.c` are mostly cleanup/refactoring
(kmalloc conversion, timer rename, page pool API). No conflicting
changes around the PCI ID table or `enic_is_sriov_vf()`.
### Step 3.4: Author
- Satish Kharat is a Cisco employee listed in MAINTAINERS for enic
(commit `9b8eeccd7110d` updates enic maintainers). He is a regular
contributor and domain expert for this driver.
### Step 3.5: Dependencies
- This is patch 2 of the "enic-sriov-v2-prep" series. However, the diff
is **completely self-contained**: it only adds a `#define`, a table
entry, and an OR condition. None of these reference anything
introduced by patch 1 of the series.
- The code applies cleanly to the current v7.0 tree — the PCI ID table
and `enic_is_sriov_vf()` are unchanged from when this patch was
written.
Record: [Self-contained, no dependencies on other patches]
---
## PHASE 4: MAILING LIST
### Step 4.1-4.5
- b4 dig was unable to match directly (the commit isn't in this tree's
history). Lore.kernel.org returned anti-scraping pages.
- The Link tag shows this is **v4** of the series, meaning it went
through 4 rounds of review. Applied by Jakub Kicinski (net-next
maintainer).
- The earlier v2 series from the same author
(`v2_20260223_satishkh_net_ethernet_enic_add_vic_ids_and_link_modes`)
shows the author was actively contributing VIC subsystem ID and link
mode support around the same timeframe.
Record: [Patch went through v4 review, applied by net-next maintainer
Jakub Kicinski]
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1-5.4: Function Impact
`enic_is_sriov_vf()` is called in 6 locations:
1. **Line 365**: MTU change notification handling (VFs schedule work vs
warn)
2. **Line 1010**: MAC address setting (VFs accept zero MAC)
3. **Line 1736**: Open path (VFs skip station addr add)
4. **Line 1804**: Close path (VFs skip station addr del)
5. **Line 1864**: MTU change (VFs return -EOPNOTSUPP)
6. **Line 2831**: Probe path (VFs get `enic_netdev_dynamic_ops`)
All 6 call sites already handle VFs correctly — they just need the VF
detection to work for V2 devices. The change in `enic_is_sriov_vf()`
propagates the correct behavior automatically.
### Step 5.5: Similar Patterns
The original V1 VF ID addition (commit `3a4adef5c0adbb` from 2012)
followed the exact same pattern: define + table + function. This V2
addition mirrors it exactly.
---
## PHASE 6: STABLE TREE ANALYSIS
### Step 6.1: Code Existence in Stable
- Current HEAD is `v7.0`. The enic driver code is identical to mainline
at the branch point.
- The PCI ID table, `enic_is_sriov_vf()`, and all call sites exist
unchanged in this tree.
- This code has been present since 2012 (kernel 3.3+), so it exists in
ALL active stable trees.
### Step 6.2: Backport Complications
- The diff applies cleanly — no intermediate changes to the PCI ID table
or `enic_is_sriov_vf()`.
- No conflicts expected.
### Step 6.3: Related Fixes
- No other fixes for V2 VF support exist in stable.
---
## PHASE 7: SUBSYSTEM CONTEXT
### Step 7.1: Subsystem
- **Subsystem**: Network drivers / Cisco VIC Ethernet
- **Criticality**: IMPORTANT — Cisco VIC adapters are used in enterprise
data centers (UCS servers)
### Step 7.2: Activity
- The enic driver receives periodic updates. The maintainer (from Cisco)
is actively contributing.
---
## PHASE 8: IMPACT AND RISK
### Step 8.1: Affected Users
- Users with Cisco VIC adapters that create V2 SR-IOV virtual functions.
This is enterprise/data center hardware.
### Step 8.2: Trigger
- Any user enabling SR-IOV on a Cisco VIC that produces V2 VFs (PCI ID
0x02b7). Without this patch, VFs simply don't work.
### Step 8.3: Severity
- Without this patch: V2 VFs are **completely non-functional** (driver
won't bind). Severity: HIGH for affected users.
### Step 8.4: Risk-Benefit
- **Benefit**: HIGH — enables SR-IOV V2 VF functionality for Cisco VIC
users
- **Risk**: VERY LOW — 3 lines, only affects devices with PCI ID 0x02b7,
mirrors existing V1 pattern exactly
- **Ratio**: Excellent — high benefit, near-zero risk
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: Evidence Summary
**FOR backporting:**
- Classic PCI device ID addition — explicitly allowed exception in
stable rules
- Only 3 functional lines of code
- Self-contained, no dependencies
- Applies cleanly to v7.0 tree
- Author is Cisco engineer / enic maintainer
- Applied by net-next maintainer (Jakub Kicinski)
- Went through v4 review cycle
- Mirrors existing V1 VF pattern from 2012
- Enables hardware that is completely non-functional without this change
- Zero regression risk (only affects new PCI device ID)
**AGAINST backporting:**
- Part of a multi-patch series — but this patch is self-contained
- No Fixes: tag — expected for device ID additions
### Step 9.2: Stable Rules Checklist
1. Obviously correct and tested? **YES** — mirrors existing V1 pattern
exactly, v4 review, from vendor
2. Fixes a real bug? **YES** — V2 VFs don't work without this
3. Important issue? **YES** — complete hardware non-functionality
4. Small and contained? **YES** — 3 lines, 1 file
5. No new features or APIs? **YES** — just adds device ID to existing
driver
6. Can apply to stable? **YES** — clean apply expected
### Step 9.3: Exception Category
**PCI Device ID addition to existing driver** — this is a canonical
example of the exception category.
### Step 9.4: Decision
This is a textbook PCI device ID addition: 3 lines, single file, from
the hardware vendor, enables V2 SR-IOV VFs on Cisco VIC adapters. It
meets all stable criteria and falls into the explicit "new device IDs"
exception category.
---
## Verification
- [Phase 1] Parsed tags: Signed-off-by from Cisco author and net-next
maintainer; Link to v4 patch 2
- [Phase 2] Diff analysis: 3 lines — 1 define, 1 PCI table entry, 1 OR
condition in `enic_is_sriov_vf()`
- [Phase 3] git blame: Original VF support (0x0071) added by
`3a4adef5c0adbb` (2012, kernel 3.3); unchanged since
- [Phase 3] git show `3a4adef5c0adbb`: Confirmed identical pattern for
V1 VF
- [Phase 3] git log: No conflicting recent changes to PCI ID table or
`enic_is_sriov_vf()`
- [Phase 3] Author: Satish Kharat (Cisco), listed in MAINTAINERS update
commit `9b8eeccd7110d`
- [Phase 4] b4 dig: Could not match commit (not in tree's history); Lore
blocked by anti-scraping
- [Phase 4] Series context: v4 series "enic-sriov-v2-prep", applied by
Jakub Kicinski
- [Phase 5] grep `enic_is_sriov_vf`: 6 call sites — all branch VF/PF
behavior correctly; V2 VFs get same treatment
- [Phase 6] HEAD is v7.0; enic PCI table unchanged; clean apply
confirmed
- [Phase 8] Failure mode: V2 VFs completely non-functional (driver won't
bind), severity HIGH for affected users
- [Phase 8] Risk: Near-zero — new PCI ID only affects matching hardware
**YES**
drivers/net/ethernet/cisco/enic/enic_main.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/cisco/enic/enic_main.c b/drivers/net/ethernet/cisco/enic/enic_main.c
index e839081f9ee44..e16dfbcd2c229 100644
--- a/drivers/net/ethernet/cisco/enic/enic_main.c
+++ b/drivers/net/ethernet/cisco/enic/enic_main.c
@@ -66,12 +66,14 @@
#define PCI_DEVICE_ID_CISCO_VIC_ENET 0x0043 /* ethernet vnic */
#define PCI_DEVICE_ID_CISCO_VIC_ENET_DYN 0x0044 /* enet dynamic vnic */
#define PCI_DEVICE_ID_CISCO_VIC_ENET_VF 0x0071 /* enet SRIOV VF */
+#define PCI_DEVICE_ID_CISCO_VIC_ENET_VF_V2 0x02b7 /* enet SRIOV V2 VF */
/* Supported devices */
static const struct pci_device_id enic_id_table[] = {
{ PCI_VDEVICE(CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET) },
{ PCI_VDEVICE(CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_DYN) },
{ PCI_VDEVICE(CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF) },
+ { PCI_VDEVICE(CISCO, PCI_DEVICE_ID_CISCO_VIC_ENET_VF_V2) },
{ 0, } /* end of table */
};
@@ -307,7 +309,8 @@ int enic_sriov_enabled(struct enic *enic)
static int enic_is_sriov_vf(struct enic *enic)
{
- return enic->pdev->device == PCI_DEVICE_ID_CISCO_VIC_ENET_VF;
+ return enic->pdev->device == PCI_DEVICE_ID_CISCO_VIC_ENET_VF ||
+ enic->pdev->device == PCI_DEVICE_ID_CISCO_VIC_ENET_VF_V2;
}
int enic_is_valid_vf(struct enic *enic, int vf)
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.6] ipv6: move IFA_F_PERMANENT percpu allocation in process scope
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Paolo Abeni, David Ahern, Jakub Kicinski, Sasha Levin, davem,
edumazet, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Paolo Abeni <pabeni@redhat.com>
[ Upstream commit 8e6405f8218b3f412d36b772318e94d589513eba ]
Observed at boot time:
CPU: 43 UID: 0 PID: 3595 Comm: (t-daemon) Not tainted 6.12.0 #1
Call Trace:
<TASK>
dump_stack_lvl+0x4e/0x70
pcpu_alloc_noprof.cold+0x1f/0x4b
fib_nh_common_init+0x4c/0x110
fib6_nh_init+0x387/0x740
ip6_route_info_create+0x46d/0x640
addrconf_f6i_alloc+0x13b/0x180
addrconf_permanent_addr+0xd0/0x220
addrconf_notify+0x93/0x540
notifier_call_chain+0x5a/0xd0
__dev_notify_flags+0x5c/0xf0
dev_change_flags+0x54/0x70
do_setlink+0x36c/0xce0
rtnl_setlink+0x11f/0x1d0
rtnetlink_rcv_msg+0x142/0x3f0
netlink_rcv_skb+0x50/0x100
netlink_unicast+0x242/0x390
netlink_sendmsg+0x21b/0x470
__sys_sendto+0x1dc/0x1f0
__x64_sys_sendto+0x24/0x30
do_syscall_64+0x7d/0x160
entry_SYSCALL_64_after_hwframe+0x76/0x7e
RIP: 0033:0x7f5c3852f127
Code: 0c 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b8 0f 1f 00 f3 0f 1e fa 80 3d 85 ef 0c 00 00 41 89 ca 74 10 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 71 c3 55 48 83 ec 30 44 89 4c 24 2c 4c 89 44
RSP: 002b:00007ffe86caf4c8 EFLAGS: 00000202 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000556c5cd93210 RCX: 00007f5c3852f127
RDX: 0000000000000020 RSI: 0000556c5cd938b0 RDI: 0000000000000003
RBP: 00007ffe86caf5a0 R08: 00007ffe86caf4e0 R09: 0000000000000080
R10: 0000000000000000 R11: 0000000000000202 R12: 0000556c5cd932d0
R13: 00000000021d05d1 R14: 00000000021d05d1 R15: 0000000000000001
IFA_F_PERMANENT addresses require the allocation of a bunch of percpu
pointers, currently in atomic scope.
Similar to commit 51454ea42c1a ("ipv6: fix locking issues with loops
over idev->addr_list"), move fixup_permanent_addr() outside the
&idev->lock scope, and do the allocations with GFP_KERNEL. With such
change fixup_permanent_addr() is invoked with the BH enabled, and the
ifp lock acquired there needs the BH variant.
Note that we don't need to acquire a reference to the permanent
addresses before releasing the mentioned write lock, because
addrconf_permanent_addr() runs under RTNL and ifa removal always happens
under RTNL, too.
Also the PERMANENT flag is constant in the relevant scope, as it can be
cleared only by inet6_addr_modify() under the RTNL lock.
Reviewed-by: David Ahern <dsahern@kernel.org>
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Link: https://patch.msgid.link/46a7a030727e236af2dc7752994cd4f04f4a91d2.1775658924.git.pabeni@redhat.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed. Let me compile my analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: PARSE THE SUBJECT LINE
- **Subsystem**: ipv6 (networking)
- **Action verb**: "move" - restructuring allocation scope
- **Summary**: Move IFA_F_PERMANENT percpu allocation from atomic to
process (GFP_KERNEL) scope
- Record: [ipv6] [move] [Change percpu allocation from GFP_ATOMIC to
GFP_KERNEL by restructuring lock scope]
### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Reviewed-by**: David Ahern <dsahern@kernel.org> - former networking
subsystem maintainer, very authoritative
- **Signed-off-by**: Paolo Abeni <pabeni@redhat.com> - current net-next
maintainer, author
- **Link**: https://patch.msgid.link/46a7a030727e236af2dc7752994cd4f04f4
a91d2.1775658924.git.pabeni@redhat.com
- **Signed-off-by**: Jakub Kicinski <kuba@kernel.org> - committer,
net/net-next maintainer
- No Fixes: tag (expected for candidates)
- No Cc: stable (expected)
- Record: Reviewed by David Ahern, authored by Paolo Abeni (net-next co-
maintainer), committed by Jakub Kicinski. Applied to net-next (not
net).
### Step 1.3: ANALYZE THE COMMIT BODY TEXT
- **Bug described**: At boot time, `pcpu_alloc_noprof.cold` is triggered
during IPv6 permanent address route setup. This is the cold
(warning/failure) path of per-cpu allocation.
- **Symptom**: GFP_ATOMIC percpu allocation failure when setting up
permanent IPv6 addresses during NETDEV_UP handling. The call trace
shows: `addrconf_permanent_addr -> fixup_permanent_addr ->
addrconf_f6i_alloc -> ip6_route_info_create -> fib6_nh_init ->
fib_nh_common_init -> pcpu_alloc_noprof.cold`
- **Root cause**: `addrconf_permanent_addr()` holds `idev->lock` (write
spinlock with BH disabled) while calling `fixup_permanent_addr()`,
forcing GFP_ATOMIC for all allocations inside. Per-cpu allocations
with GFP_ATOMIC are unreliable, especially on systems with many CPUs.
- **Kernel version**: Observed on 6.12.0 with 43+ CPUs
- Record: Real boot-time allocation failure. IPv6 permanent address
setup fails when percpu allocation with GFP_ATOMIC fails, causing the
address to be dropped.
### Step 1.4: DETECT HIDDEN BUG FIXES
This IS a bug fix despite being described as "move". When GFP_ATOMIC
percpu allocation fails, `fixup_permanent_addr()` returns an error, and
`addrconf_permanent_addr()` then DROPS the IPv6 address
(`ipv6_del_addr`). Users lose permanent IPv6 addresses at boot.
- Record: Yes, this is a real bug fix. The "move" language hides the
fact that GFP_ATOMIC failures cause IPv6 addresses to be lost.
## PHASE 2: DIFF ANALYSIS
### Step 2.1: INVENTORY THE CHANGES
- **File**: `net/ipv6/addrconf.c` - 19 lines added, 12 removed (net +7)
- **Functions modified**: `fixup_permanent_addr()` and
`addrconf_permanent_addr()`
- **Scope**: Single-file, well-contained change in two related functions
- Record: Single file, ~31 lines total change, two functions in same
call chain.
### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Hunk 1** (`fixup_permanent_addr`):
- Before: GFP_ATOMIC for route allocation, plain spin_lock/unlock for
ifp->lock
- After: GFP_KERNEL for route allocation, spin_lock_bh/unlock_bh (needed
because BH is now enabled)
- GFP_ATOMIC -> GFP_KERNEL in both `addrconf_f6i_alloc()` and
`addrconf_prefix_route()` calls
**Hunk 2** (`addrconf_permanent_addr`):
- Before: Holds `idev->lock` throughout iteration and calls
`fixup_permanent_addr()` inside the lock
- After: Builds temporary list of PERMANENT addresses while holding
lock, releases lock, then iterates temporary list calling
`fixup_permanent_addr()` without lock held
- Uses existing `if_list_aux` infrastructure (same pattern as commit
51454ea42c1a)
- Adds ASSERT_RTNL() for safety
### Step 2.3: IDENTIFY THE BUG MECHANISM
**Category**: Allocation failure in atomic context / resource setup
failure
- The bug is that percpu allocations (via `alloc_percpu_gfp()` in
`fib_nh_common_init()`) with GFP_ATOMIC can fail, especially on high-
CPU-count systems
- When the allocation fails, the permanent IPv6 address is dropped
- The fix moves the work outside the spinlock so GFP_KERNEL can be used
- Record: Allocation failure bug. GFP_ATOMIC percpu allocation in
fib_nh_common_init fails -> route creation fails -> permanent IPv6
address dropped.
### Step 2.4: ASSESS THE FIX QUALITY
- **Obviously correct**: Yes - the if_list_aux pattern is proven
(already used in `addrconf_ifdown` and `dev_forward_change`)
- **Minimal/surgical**: Yes - single file, two functions, well-contained
- **Regression risk**: Low - the lock restructuring is safe per RTNL
protection. The spin_lock -> spin_lock_bh change is correct because BH
is now enabled.
- **Red flags**: None. The locking argument is well-explained in the
commit message (RTNL protects against concurrent ifa removal).
- Record: High quality fix. Proven pattern, correct BH handling, well-
documented safety argument.
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: BLAME THE CHANGED LINES
- `fixup_permanent_addr()` introduced by f1705ec197e7 (Feb 2016, "net:
ipv6: Make address flushing on ifdown optional") in v4.5
- The buggy GFP_ATOMIC has been present since this code was created
- `addrconf_permanent_addr()` also from the same commit
- Record: Buggy code introduced in v4.5 (f1705ec197e7, 2016). Present in
ALL stable trees.
### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present (expected).
### Step 3.3: CHECK FILE HISTORY
- fd63f185979b0 ("ipv6: prevent possible UaF in
addrconf_permanent_addr()") is a prerequisite - already in v7.0
- 51454ea42c1a ("ipv6: fix locking issues with loops over
idev->addr_list") introduced the if_list_aux pattern - in v5.19+
- Record: Two prerequisites identified, both present in v7.0.
### Step 3.4: CHECK THE AUTHOR
- Paolo Abeni is the net-next co-maintainer - maximum authority for
networking code
- David Ahern reviewed it - he's the original author of much of this
code
- Record: Author is subsystem co-maintainer. Reviewer is the original
code author.
### Step 3.5: CHECK FOR DEPENDENCIES
- Requires `if_list_aux` field in `inet6_ifaddr` (from commit
51454ea42c1a, v5.19+) - present in v7.0
- Requires fd63f185979b0 UaF fix (already in v7.0)
- Requires `d465bd07d16e3` gfp_flags passdown through
`ip6_route_info_create_nh()` - present in v7.0
- The diff applies cleanly against v7.0 (verified)
- Record: All dependencies satisfied in v7.0. Clean apply confirmed.
## PHASE 4: MAILING LIST RESEARCH
### Step 4.1: ORIGINAL PATCH DISCUSSION
- Found via b4 am: Applied to netdev/net-next.git (main) as commit
8e6405f8218b
- This is v2 of the patch (v1 was the initial UaF fix that became
fd63f185979b0)
- Applied by Jakub Kicinski
- Submitted to net-next, not net
- Record: v2 patch, applied to net-next. Upstream commit is
8e6405f8218b.
### Step 4.2: REVIEWERS
- Paolo Abeni (author, net-next co-maintainer)
- David Ahern (reviewer, original code author)
- Jakub Kicinski (committer, net maintainer)
- All key networking maintainers involved
- Record: Maximum authority review chain.
### Step 4.3: BUG REPORT
- The stack trace in the commit is from a real system (6.12.0, 43+ CPUs)
- `pcpu_alloc_noprof.cold` is the failure/warning path for percpu
allocations
- Record: Real-world observation on production system.
### Step 4.4: SERIES CONTEXT
- This is standalone (v2 of a single patch), not part of a multi-patch
series
- Record: Standalone fix.
### Step 4.5: STABLE DISCUSSION
- No specific stable discussion found
- Note: applied to net-next, not net, suggesting author didn't consider
it urgent
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1-5.4: FUNCTION ANALYSIS
- `addrconf_permanent_addr()` is called from `addrconf_notify()` on
`NETDEV_UP` events
- This is the boot-time path for restoring permanent IPv6 addresses when
interfaces come up
- Call chain: `addrconf_notify() -> addrconf_permanent_addr() ->
fixup_permanent_addr() -> addrconf_f6i_alloc() -> ... ->
fib_nh_common_init() -> alloc_percpu_gfp()`
- The allocation in `fib_nh_common_init()` is `alloc_percpu_gfp(struct
rtable __rcu *, gfp_flags)` - this allocates per-CPU pointers
- On high-CPU systems, percpu allocations are larger and more likely to
fail with GFP_ATOMIC
- This path runs on every NETDEV_UP event for every interface
- Record: Code is in a common boot path. Allocation failure causes
permanent address loss.
## PHASE 6: STABLE TREE ANALYSIS
### Step 6.1: BUGGY CODE IN STABLE TREES
- The buggy GFP_ATOMIC code exists since v4.5 (f1705ec197e7)
- Present in ALL active stable trees
- Record: Bug present in all stable trees from v4.5 onward.
### Step 6.2: BACKPORT COMPLICATIONS
- For 7.0: Clean apply (verified via `git diff v7.0 8e6405f8218b`)
- For 6.12 and older: Would need checking for gfp_flags passdown chain
- Record: Clean apply for 7.0.y. May need adjustment for older trees.
### Step 6.3: RELATED FIXES IN STABLE
- None found for this specific GFP_ATOMIC issue
- Record: No related fix already in stable.
## PHASE 7: SUBSYSTEM CONTEXT
### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem**: net/ipv6 (networking, IPv6 address configuration)
- **Criticality**: IMPORTANT - IPv6 connectivity affects many users,
especially on servers
- Record: IMPORTANT subsystem. IPv6 permanent address loss at boot
affects server connectivity.
### Step 7.2: SUBSYSTEM ACTIVITY
- `net/ipv6/addrconf.c` has 106+ commits between v6.6 and v7.0
- Actively maintained area
- Record: Very active subsystem.
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: WHO IS AFFECTED
- Systems with many CPUs (43+ shown in trace) using IPv6 permanent
addresses
- More likely on servers/enterprise systems
- Record: Affects multi-CPU systems with IPv6, primarily servers.
### Step 8.2: TRIGGER CONDITIONS
- Triggered at boot time during interface bring-up (NETDEV_UP)
- Also triggered whenever `rtnl_setlink` brings an interface up
- More likely under memory pressure or on high-CPU-count systems
- Record: Triggered at boot/interface-up. More common on high-CPU
systems.
### Step 8.3: FAILURE MODE SEVERITY
- When triggered: permanent IPv6 address is DROPPED from the interface
- This means IPv6 connectivity loss for that address
- Not a crash, but an operational failure (lost connectivity)
- Record: Severity HIGH - IPv6 address loss leads to connectivity
failure.
### Step 8.4: RISK-BENEFIT RATIO
- **Benefit**: Prevents IPv6 address loss on multi-CPU systems at boot
- **Risk**: Low - proven pattern (if_list_aux), well-reviewed, single
file
- Record: Benefit HIGH / Risk LOW = favorable ratio.
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: EVIDENCE COMPILATION
**FOR backporting:**
- Fixes real boot-time IPv6 address loss on multi-CPU systems
- Stack trace from a real 6.12.0 deployment
- Written by net-next co-maintainer, reviewed by original code author
- Uses proven if_list_aux pattern already in the same file
- Single file, ~31 lines, well-contained
- Bug present since v4.5 - affects all stable trees
- Clean apply against v7.0
**AGAINST backporting:**
- Applied to net-next, not net (author didn't consider it critical)
- No Fixes: tag or Cc: stable from author
- Structural change (lock restructuring), not a one-line fix
- Not a crash - "just" drops IPv6 addresses when allocation fails
**UNRESOLVED:**
- Exact failure rate on real systems unknown (depends on CPU count and
memory state)
- Could not access lore.kernel.org for full review discussion (Anubis
protection)
### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - proven pattern, reviewed by
original code author and subsystem maintainer
2. Fixes a real bug? **YES** - GFP_ATOMIC percpu allocation failure
causes IPv6 address loss
3. Important issue? **YES** - IPv6 connectivity loss at boot on multi-
CPU systems
4. Small and contained? **YES** - single file, ~31 lines, two functions
in same call chain
5. No new features or APIs? **YES** - pure internal restructuring
6. Can apply to stable? **YES** - clean apply to v7.0 verified
### Step 9.3: EXCEPTION CATEGORIES
Not an exception category - this is a standard bug fix.
### Step 9.4: DECISION
The fix addresses a real operational issue (IPv6 permanent address loss
at boot due to GFP_ATOMIC percpu allocation failure). While it was
routed to net-next rather than net, the bug has real-world impact on
multi-CPU systems. The fix is well-reviewed by the most authoritative
people for this code, uses a proven pattern, and applies cleanly to
v7.0.
## Verification
- [Phase 1] Parsed tags: Reviewed-by David Ahern, Signed-off-by Paolo
Abeni and Jakub Kicinski. No Fixes/Cc-stable (expected).
- [Phase 2] Diff analysis: GFP_ATOMIC -> GFP_KERNEL in
fixup_permanent_addr(), lock restructuring in
addrconf_permanent_addr() using proven if_list_aux pattern.
- [Phase 3] git blame: Code introduced by f1705ec197e7 (v4.5, 2016). Bug
present since v4.5.
- [Phase 3] git merge-base: 51454ea42c1a (if_list_aux) in v5.19+,
fd63f185979b0 (UaF fix) in v7.0, d465bd07d16e3 (gfp passdown) in v7.0.
- [Phase 3] git diff v7.0 8e6405f8218b: Clean apply confirmed.
- [Phase 4] b4 am: Found upstream commit 8e6405f8218b, applied to net-
next by Jakub Kicinski. v2 patch.
- [Phase 4] Mailing list thread: Confirmed patchwork-bot shows clean
application to netdev/net-next.git.
- [Phase 4] b4 dig -w on related commit: Confirmed all key networking
maintainers were involved.
- [Phase 5] Call chain: addrconf_notify -> addrconf_permanent_addr ->
fixup_permanent_addr -> addrconf_f6i_alloc -> ... ->
fib_nh_common_init -> alloc_percpu_gfp with GFP_ATOMIC fails.
- [Phase 5] fib_nh_common_init: Verified it does alloc_percpu_gfp() at
line 619-620 of fib_semantics.c.
- [Phase 6] v7.0: All dependencies present, clean apply verified.
- [Phase 8] Failure mode: IPv6 permanent address dropped (ipv6_del_addr
called) when allocation fails - HIGH severity.
- UNVERIFIED: Could not access lore.kernel.org review comments due to
Anubis bot protection. The full reviewer feedback on v1->v2 evolution
could not be examined.
**YES**
net/ipv6/addrconf.c | 31 +++++++++++++++++++------------
1 file changed, 19 insertions(+), 12 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index dd0b4d80e0f84..77c77e843c96c 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -3585,15 +3585,15 @@ static int fixup_permanent_addr(struct net *net,
struct fib6_info *f6i, *prev;
f6i = addrconf_f6i_alloc(net, idev, &ifp->addr, false,
- GFP_ATOMIC, NULL);
+ GFP_KERNEL, NULL);
if (IS_ERR(f6i))
return PTR_ERR(f6i);
/* ifp->rt can be accessed outside of rtnl */
- spin_lock(&ifp->lock);
+ spin_lock_bh(&ifp->lock);
prev = ifp->rt;
ifp->rt = f6i;
- spin_unlock(&ifp->lock);
+ spin_unlock_bh(&ifp->lock);
fib6_info_release(prev);
}
@@ -3601,7 +3601,7 @@ static int fixup_permanent_addr(struct net *net,
if (!(ifp->flags & IFA_F_NOPREFIXROUTE)) {
addrconf_prefix_route(&ifp->addr, ifp->prefix_len,
ifp->rt_priority, idev->dev, 0, 0,
- GFP_ATOMIC);
+ GFP_KERNEL);
}
if (ifp->state == INET6_IFADDR_STATE_PREDAD)
@@ -3612,29 +3612,36 @@ static int fixup_permanent_addr(struct net *net,
static void addrconf_permanent_addr(struct net *net, struct net_device *dev)
{
- struct inet6_ifaddr *ifp, *tmp;
+ struct inet6_ifaddr *ifp;
+ LIST_HEAD(tmp_addr_list);
struct inet6_dev *idev;
+ /* Mutual exclusion with other if_list_aux users. */
+ ASSERT_RTNL();
+
idev = __in6_dev_get(dev);
if (!idev)
return;
write_lock_bh(&idev->lock);
+ list_for_each_entry(ifp, &idev->addr_list, if_list) {
+ if (ifp->flags & IFA_F_PERMANENT)
+ list_add_tail(&ifp->if_list_aux, &tmp_addr_list);
+ }
+ write_unlock_bh(&idev->lock);
- list_for_each_entry_safe(ifp, tmp, &idev->addr_list, if_list) {
- if ((ifp->flags & IFA_F_PERMANENT) &&
- fixup_permanent_addr(net, idev, ifp) < 0) {
- write_unlock_bh(&idev->lock);
+ while (!list_empty(&tmp_addr_list)) {
+ ifp = list_first_entry(&tmp_addr_list,
+ struct inet6_ifaddr, if_list_aux);
+ list_del(&ifp->if_list_aux);
+ if (fixup_permanent_addr(net, idev, ifp) < 0) {
net_info_ratelimited("%s: Failed to add prefix route for address %pI6c; dropping\n",
idev->dev->name, &ifp->addr);
in6_ifa_hold(ifp);
ipv6_del_addr(ifp);
- write_lock_bh(&idev->lock);
}
}
-
- write_unlock_bh(&idev->lock);
}
static int addrconf_notify(struct notifier_block *this, unsigned long event,
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] netfilter: nfnetlink_log: initialize nfgenmsg in NLMSG_DONE terminator
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Xiang Mei, Weiming Shi, Florian Westphal, Sasha Levin, pablo,
davem, edumazet, kuba, pabeni, kaber, eric, netfilter-devel,
coreteam, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Xiang Mei <xmei5@asu.edu>
[ Upstream commit 1f3083aec8836213da441270cdb1ab612dd82cf4 ]
When batching multiple NFLOG messages (inst->qlen > 1), __nfulnl_send()
appends an NLMSG_DONE terminator with sizeof(struct nfgenmsg) payload via
nlmsg_put(), but never initializes the nfgenmsg bytes. The nlmsg_put()
helper only zeroes alignment padding after the payload, not the payload
itself, so four bytes of stale kernel heap data are leaked to userspace
in the NLMSG_DONE message body.
Use nfnl_msg_put() to build the NLMSG_DONE terminator, which initializes
the nfgenmsg payload via nfnl_fill_hdr(), consistent with how
__build_packet_message() already constructs NFULNL_MSG_PACKET headers.
Fixes: 29c5d4afba51 ("[NETFILTER]: nfnetlink_log: fix sending of multipart messages")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Signed-off-by: Xiang Mei <xmei5@asu.edu>
Signed-off-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
net/netfilter/nfnetlink_log.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/net/netfilter/nfnetlink_log.c b/net/netfilter/nfnetlink_log.c
index dcd2493a9a404..b1f3eda85989c 100644
--- a/net/netfilter/nfnetlink_log.c
+++ b/net/netfilter/nfnetlink_log.c
@@ -361,10 +361,10 @@ static void
__nfulnl_send(struct nfulnl_instance *inst)
{
if (inst->qlen > 1) {
- struct nlmsghdr *nlh = nlmsg_put(inst->skb, 0, 0,
- NLMSG_DONE,
- sizeof(struct nfgenmsg),
- 0);
+ struct nlmsghdr *nlh = nfnl_msg_put(inst->skb, 0, 0,
+ NLMSG_DONE, 0,
+ AF_UNSPEC, NFNETLINK_V0,
+ htons(inst->group_num));
if (WARN_ONCE(!nlh, "bad nlskb size: %u, tailroom %d\n",
inst->skb->len, skb_tailroom(inst->skb))) {
kfree_skb(inst->skb);
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] net: increase IP_TUNNEL_RECURSION_LIMIT to 5
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Chris J Arges, Jakub Kicinski, Sasha Levin, davem, dsahern,
edumazet, pabeni, bestswngs, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Chris J Arges <carges@cloudflare.com>
[ Upstream commit 77facb35227c421467cdb49268de433168c2dcef ]
In configurations with multiple tunnel layers and MPLS lwtunnel routing, a
single tunnel hop can increment the counter beyond this limit. This causes
packets to be dropped with the "Dead loop on virtual device" message even
when a routing loop doesn't exist.
Increase IP_TUNNEL_RECURSION_LIMIT from 4 to 5 to handle this use-case.
Fixes: 6f1a9140ecda ("net: add xmit recursion limit to tunnel xmit functions")
Link: https://lore.kernel.org/netdev/88deb91b-ef1b-403c-8eeb-0f971f27e34f@redhat.com/
Signed-off-by: Chris J Arges <carges@cloudflare.com>
Link: https://patch.msgid.link/20260402222401.3408368-1-carges@cloudflare.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
include/net/ip_tunnels.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/ip_tunnels.h b/include/net/ip_tunnels.h
index 80662f8120803..253ed3930f6ef 100644
--- a/include/net/ip_tunnels.h
+++ b/include/net/ip_tunnels.h
@@ -32,7 +32,7 @@
* recursion involves route lookups and full IP output, consuming much
* more stack per level, so a lower limit is needed.
*/
-#define IP_TUNNEL_RECURSION_LIMIT 4
+#define IP_TUNNEL_RECURSION_LIMIT 5
/* Keep error state on tunnel for 30 sec */
#define IPTUNNEL_ERR_TIMEO (30*HZ)
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-6.1] net: lan743x: fix SGMII detection on PCI1xxxx B0+ during warm reset
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Thangaraj Samynathan, Jakub Kicinski, Sasha Levin,
bryan.whitehead, UNGLinuxDriver, andrew+netdev, davem, edumazet,
pabeni, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Thangaraj Samynathan <thangaraj.s@microchip.com>
[ Upstream commit e783e40fb689381caca31e03d28c39e10c82e722 ]
A warm reset on boards using an EEPROM-only strap configuration (where
no MAC address is set in the image) can cause the driver to incorrectly
revert to RGMII mode. This occurs because the ENET_CONFIG_LOAD_STARTED
bit may not persist or behave as expected.
Update pci11x1x_strap_get_status() to use revision-specific validation:
- For PCI11x1x A0: Continue using the legacy check (config load started
or reset protection) to validate the SGMII strap.
- For PCI11x1x B0 and later: Use the newly available
STRAP_READ_USE_SGMII_EN_ bit in the upper strap register to validate
the lower SGMII_EN bit.
This ensures the SGMII interface is correctly identified even after a
warm reboot.
Signed-off-by: Thangaraj Samynathan <thangaraj.s@microchip.com>
Link: https://patch.msgid.link/20260318063228.17110-1-thangaraj.s@microchip.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the information needed. Let me compile the full analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: PARSE THE SUBJECT LINE
Record: [net: lan743x] [fix] SGMII detection on PCI1xxxx B0+ during warm
reset. The verb "fix" directly indicates a bug fix.
### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Signed-off-by**: Thangaraj Samynathan (Microchip employee - device
vendor)
- **Link**: https://patch.msgid.link/20260318063228.17110-1-
thangaraj.s@microchip.com
- **Signed-off-by**: Jakub Kicinski (netdev maintainer - accepted the
patch)
- No Fixes: tag (expected for candidates under review)
- No Cc: stable tag (expected)
- No Reported-by tag
Record: Patch from the device vendor (Microchip), accepted by the netdev
maintainer. No explicit stable nomination.
### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit describes a concrete bug: warm reset on boards with EEPROM-
only strap config (no MAC in image) causes incorrect revert to RGMII
mode. The root cause is that the `ENET_CONFIG_LOAD_STARTED` bit may not
persist. The fix uses revision-specific validation: A0 keeps legacy
check, B0+ uses `STRAP_READ_USE_SGMII_EN_` bit.
Record: Bug = SGMII interface misdetected as RGMII after warm reset.
Symptom = network interface uses wrong PHY mode. Root cause = config
load register bit doesn't persist across warm reset on B0+ with specific
strap configuration.
### Step 1.4: DETECT HIDDEN BUG FIXES
This is an explicit bug fix, not disguised.
---
## PHASE 2: DIFF ANALYSIS
### Step 2.1: INVENTORY THE CHANGES
- `lan743x_main.c`: +13/-4 lines
- `lan743x_main.h`: +1/-0 lines
- New helper function: `pci11x1x_is_a0()` (4 lines)
- Modified function: `pci11x1x_strap_get_status()`
- New define: `ID_REV_CHIP_REV_PCI11X1X_A0_`
- Scope: single-file surgical fix in a single driver
### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
**Before**: The condition checked `cfg_load &
GEN_SYS_LOAD_STARTED_REG_ETH_ || hw_cfg & HW_CFG_RST_PROTECT_`. If
either was set, it read the strap register and checked
`STRAP_READ_SGMII_EN_`. Otherwise, it fell through to FPGA check, which
for non-FPGA boards would set `is_sgmii_en = false`.
**After**: The condition now branches by revision:
- A0: Same legacy check (config load or reset protect)
- B0+: Checks `STRAP_READ_USE_SGMII_EN_` bit directly (the upper strap
register bit)
- Also, `strap = lan743x_csr_read()` is moved outside the conditional
(unconditionally read)
### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: Logic/correctness fix. The hardware register
(`ENET_CONFIG_LOAD_STARTED`) doesn't reliably persist on B0+ after warm
reset in EEPROM-only configurations. This causes the conditional to
fail, and the code falls through to the FPGA path which sets
`is_sgmii_en = false`, making the driver use RGMII mode incorrectly.
### Step 2.4: ASSESS THE FIX QUALITY
The fix is obviously correct: it restores the original check method
(`STRAP_READ_USE_SGMII_EN_`) for B0+ hardware while preserving legacy
behavior for A0. The new `pci11x1x_is_a0()` helper is trivial. Very low
regression risk - A0 behavior unchanged, B0+ gets a more reliable
detection method.
---
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: BLAME THE CHANGED LINES
Verified via `git blame`: The buggy conditional (lines 51-52) was
introduced by `46b777ad9a8c26` ("net: lan743x: Add support to SGMII 1G
and 2.5G", Jun 2022). The original code in `a46d9d37c4f4fa` (Feb 2022)
checked `STRAP_READ_USE_SGMII_EN_` directly, which was the correct
approach for B0+.
Record: Bug introduced by `46b777ad9a8c26` (v5.19/v6.0). Original
working code was in `a46d9d37c4f4fa` (v5.18).
### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag, but the bug was clearly introduced by `46b777ad9a8c26`.
This commit exists in stable trees v6.0+.
### Step 3.3: CHECK FILE HISTORY
The file has active development. The author (Thangaraj Samynathan) is a
Microchip employee and a regular contributor to the lan743x driver with
10+ commits.
### Step 3.4: AUTHOR CONTEXT
The author works at Microchip (the hardware vendor). They have deep
knowledge of this hardware.
### Step 3.5: DEPENDENCIES
The fix adds `ID_REV_CHIP_REV_PCI11X1X_A0_` define. The only nearby
dependency is `ID_REV_CHIP_REV_PCI11X1X_B0_` (added in `e4a58989f5c839`,
v6.10). For stable trees 6.1-6.9, the patch context would differ
slightly and need minor adaptation. For 6.12+, it should apply cleanly.
---
## PHASE 4: MAILING LIST AND EXTERNAL RESEARCH
### Step 4.1: ORIGINAL PATCH DISCUSSION
Found via `b4 am`: The patch was submitted as "[PATCH v1]" and had 2
messages in the thread. The v0->v1 changelog shows: "Added helpers to
check if the device revision is a0". This was a single-patch submission
(not part of a series).
### Step 4.2: REVIEWER CONTEXT
The patch was accepted by Jakub Kicinski (netdev maintainer) directly.
### Step 4.3-4.5: BUG REPORT / STABLE DISCUSSION
No public bug report linked. The fix comes directly from the hardware
vendor, suggesting it was found during internal testing.
---
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1-5.2: FUNCTION ANALYSIS
`pci11x1x_strap_get_status()` is called from `lan743x_hardware_init()`
(line 3506), which is the main hardware initialization path. It's called
once during device probe and determines whether SGMII or RGMII mode is
used.
### Step 5.3-5.4: IMPACT CHAIN
`is_sgmii_en` controls:
1. SGMII_CTL register configuration (lines 3511-3518) - enables/disables
SGMII
2. PHY interface mode selection (line 1357-1358) -
`PHY_INTERFACE_MODE_SGMII` vs `RGMII`
3. MDIO bus configuration (lines 3576-3595) - C45 vs C22 access
If `is_sgmii_en` is incorrectly set to `false` on SGMII hardware, the
network interface will not work.
---
## PHASE 6: CROSS-REFERENCING AND STABLE TREE ANALYSIS
### Step 6.1: BUGGY CODE IN STABLE TREES
The buggy code from `46b777ad9a8c26` exists in all stable trees from
v6.1+. The `ID_REV_CHIP_REV_PCI11X1X_B0_` prerequisite is in v6.10+, so
for 6.12+ the patch applies cleanly.
### Step 6.2: BACKPORT COMPLICATIONS
For 6.12+: should apply cleanly. For 6.1-6.9: minor context adjustment
needed (the `B0_` define line won't be present).
---
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: SUBSYSTEM CRITICALITY
Subsystem: Network driver (Ethernet) - IMPORTANT. The lan743x driver
supports Microchip PCI11010/PCI11414 Ethernet controllers used in
embedded and desktop systems.
---
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: AFFECTED USERS
Users with PCI1xxxx B0+ hardware using EEPROM-only strap configuration
(no MAC in image) who perform warm resets.
### Step 8.2: TRIGGER CONDITIONS
Warm reset on affected hardware. This is a normal, common operation.
### Step 8.3: FAILURE MODE SEVERITY
Network interface uses wrong PHY mode -> network doesn't work after warm
reboot. Severity: HIGH (complete loss of network connectivity).
### Step 8.4: RISK-BENEFIT RATIO
- **Benefit**: HIGH - fixes complete network failure on warm reset for
affected hardware
- **Risk**: VERY LOW - 13 lines added, surgical fix, chip revision-based
branching, no behavioral change for A0
---
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: EVIDENCE COMPILATION
**FOR backporting**:
- Fixes a real hardware bug: network failure after warm reset
- From the device vendor (Microchip) with deep hardware knowledge
- Small and surgical: ~16 lines total change
- Accepted by netdev maintainer
- Very low regression risk: preserves A0 behavior, fixes B0+ detection
- Buggy code exists in stable trees 6.1+
- Restores original proven detection method for B0+
**AGAINST backporting**:
- No Fixes: tag (expected)
- No explicit stable nomination
- Adds new defines (but these are trivial hardware register constants)
- Minor context conflict possible in older stable trees
### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - from hardware vendor,
accepted by maintainer
2. Fixes a real bug? **YES** - SGMII misdetection causes network failure
3. Important issue? **YES** - complete loss of network connectivity
4. Small and contained? **YES** - ~16 lines, 2 files, single function
5. No new features or APIs? **YES** - this is a bug fix, no new
functionality
6. Can apply to stable trees? **YES** for 6.12+; needs minor adaptation
for 6.1-6.9
### Step 9.3: EXCEPTION CATEGORIES
This is a hardware workaround (chip revision-specific fix) which is an
accepted stable category.
---
## Verification
- [Phase 1] Parsed tags: Signed-off-by from Microchip (vendor), accepted
by Jakub Kicinski (netdev maintainer)
- [Phase 2] Diff analysis: +13/-4 in .c, +1 in .h; adds
`pci11x1x_is_a0()` helper and revision-based conditional branching
- [Phase 3] git blame: buggy conditional introduced by `46b777ad9a8c26`
(v5.19/v6.0, Jun 2022)
- [Phase 3] git show `a46d9d37c4f4fa`: confirmed original code checked
`STRAP_READ_USE_SGMII_EN_` directly (the correct method for B0+)
- [Phase 3] git show `46b777ad9a8c26`: confirmed this commit replaced
the direct check with `cfg_load`/`hw_cfg` check, introducing the
regression
- [Phase 3] git tag: buggy code exists in v6.0+; prerequisite
`PCI11X1X_B0_` define exists in v6.10+
- [Phase 4] b4 am: found original submission, v1 single patch, 2
messages in thread
- [Phase 4] mbox read: changelog shows v0->v1 added the is_a0 helper
(review feedback addressed)
- [Phase 5] Grep callers: `pci11x1x_strap_get_status()` called from
`lan743x_hardware_init()` (line 3506)
- [Phase 5] Grep `is_sgmii_en`: controls PHY interface mode (line 1357),
SGMII_CTL register (line 3511), MDIO bus setup (line 3576)
- [Phase 6] Code exists in stable trees v6.1+; clean apply expected for
v6.12+
- [Phase 8] Failure mode: wrong PHY mode -> network failure; severity
HIGH
**YES**
drivers/net/ethernet/microchip/lan743x_main.c | 15 +++++++++++----
drivers/net/ethernet/microchip/lan743x_main.h | 1 +
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/drivers/net/ethernet/microchip/lan743x_main.c b/drivers/net/ethernet/microchip/lan743x_main.c
index f0b5dd752f084..b4cabde6625a2 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.c
+++ b/drivers/net/ethernet/microchip/lan743x_main.c
@@ -28,6 +28,12 @@
#define RFE_RD_FIFO_TH_3_DWORDS 0x3
+static bool pci11x1x_is_a0(struct lan743x_adapter *adapter)
+{
+ u32 dev_rev = adapter->csr.id_rev & ID_REV_CHIP_REV_MASK_;
+ return dev_rev == ID_REV_CHIP_REV_PCI11X1X_A0_;
+}
+
static void pci11x1x_strap_get_status(struct lan743x_adapter *adapter)
{
u32 chip_rev;
@@ -47,10 +53,11 @@ static void pci11x1x_strap_get_status(struct lan743x_adapter *adapter)
cfg_load = lan743x_csr_read(adapter, ETH_SYS_CONFIG_LOAD_STARTED_REG);
lan743x_hs_syslock_release(adapter);
hw_cfg = lan743x_csr_read(adapter, HW_CFG);
-
- if (cfg_load & GEN_SYS_LOAD_STARTED_REG_ETH_ ||
- hw_cfg & HW_CFG_RST_PROTECT_) {
- strap = lan743x_csr_read(adapter, STRAP_READ);
+ strap = lan743x_csr_read(adapter, STRAP_READ);
+ if ((pci11x1x_is_a0(adapter) &&
+ (cfg_load & GEN_SYS_LOAD_STARTED_REG_ETH_ ||
+ hw_cfg & HW_CFG_RST_PROTECT_)) ||
+ (strap & STRAP_READ_USE_SGMII_EN_)) {
if (strap & STRAP_READ_SGMII_EN_)
adapter->is_sgmii_en = true;
else
diff --git a/drivers/net/ethernet/microchip/lan743x_main.h b/drivers/net/ethernet/microchip/lan743x_main.h
index 02a28b7091630..160d94a7cee66 100644
--- a/drivers/net/ethernet/microchip/lan743x_main.h
+++ b/drivers/net/ethernet/microchip/lan743x_main.h
@@ -27,6 +27,7 @@
#define ID_REV_CHIP_REV_MASK_ (0x0000FFFF)
#define ID_REV_CHIP_REV_A0_ (0x00000000)
#define ID_REV_CHIP_REV_B0_ (0x00000010)
+#define ID_REV_CHIP_REV_PCI11X1X_A0_ (0x000000A0)
#define ID_REV_CHIP_REV_PCI11X1X_B0_ (0x000000B0)
#define FPGA_REV (0x04)
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 7.0-5.10] vmxnet3: Suppress page allocation warning for massive Rx Data ring
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Aaron Tomlin, Jijie Shao, Jakub Kicinski, Sasha Levin,
ronak.doshi, andrew+netdev, davem, edumazet, pabeni, netdev,
linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Aaron Tomlin <atomlin@atomlin.com>
[ Upstream commit c31770c49348fb019167fa95119f330597c99193 ]
The vmxnet3 driver supports an Rx Data ring (rx-mini) to optimise the
processing of small packets. The size of this ring's DMA-coherent memory
allocation is determined by the product of the primary Rx ring size and
the data ring descriptor size:
sz = rq->rx_ring[0].size * rq->data_ring.desc_size;
When a user configures the maximum supported parameters via ethtool
(rx_ring[0].size = 4096, data_ring.desc_size = 2048), the required
contiguous memory allocation reaches 8 MB (8,388,608 bytes).
In environments lacking Contiguous Memory Allocator (CMA),
dma_alloc_coherent() falls back to the standard zone buddy allocator. An
8 MB allocation translates to a page order of 11, which strictly exceeds
the default MAX_PAGE_ORDER (10) on most architectures.
Consequently, __alloc_pages_noprof() catches the oversize request and
triggers a loud kernel warning stack trace:
WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)
This warning is unnecessary and alarming to system administrators because
the vmxnet3 driver already handles this allocation failure gracefully.
If dma_alloc_coherent() returns NULL, the driver safely disables the
Rx Data ring (adapter->rxdataring_enabled = false) and falls back to
standard, streaming DMA packet processing.
To resolve this, append the __GFP_NOWARN flag to the dma_alloc_coherent()
gfp_mask. This instructs the page allocator to silently fail the
allocation if it exceeds order limits or memory is too fragmented,
preventing the spurious warning stack trace.
Furthermore, enhance the subsequent netdev_err() fallback message to
include the requested allocation size. This provides critical debugging
context to the administrator (e.g., revealing that an 8 MB allocation
was attempted and failed) without making hardcoded assumptions about
the state of the system's configurations.
Reviewed-by: Jijie Shao <shaojijie@huawei.com>
Signed-off-by: Aaron Tomlin <atomlin@atomlin.com>
Link: https://patch.msgid.link/20260226163121.4045808-1-atomlin@atomlin.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Now I have all the evidence needed for a comprehensive analysis.
---
## PHASE 1: COMMIT MESSAGE FORENSICS
### Step 1.1: PARSE THE SUBJECT LINE
Record: [vmxnet3] [Suppress] Suppress page allocation warning for
massive Rx Data ring allocation that exceeds MAX_PAGE_ORDER. The verb
"Suppress" indicates removing a spurious warning, not adding a new
feature.
### Step 1.2: PARSE ALL COMMIT MESSAGE TAGS
- **Reviewed-by:** Jijie Shao <shaojijie@huawei.com> - a networking
contributor (hns3 driver)
- **Signed-off-by:** Aaron Tomlin <atomlin@atomlin.com> - the author, a
kernel contributor (modules, tracing subsystems)
- **Link:**
https://patch.msgid.link/20260226163121.4045808-1-atomlin@atomlin.com
- **Signed-off-by:** Jakub Kicinski <kuba@kernel.org> - the net tree
maintainer, committed it
- No Fixes: tag (expected for candidates)
- No Reported-by: tag
- No Cc: stable tag
Record: Committed by the net maintainer (Jakub Kicinski). Reviewed by a
networking contributor.
### Step 1.3: ANALYZE THE COMMIT BODY TEXT
The commit explains in detail:
- When max ethtool parameters are set (rx_ring[0].size=4096,
data_ring.desc_size=2048), the DMA allocation is 8 MB
- 8 MB requires page order 11, which exceeds MAX_PAGE_ORDER (10)
- This triggers `WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)` in
page_alloc.c
- The driver already gracefully handles the failure (disables data ring
and falls back)
- The warning is "unnecessary and alarming to system administrators"
Record: Bug is a spurious WARN_ON_ONCE kernel stack trace when VMware
users configure max ring parameters. Symptom is an alarming stack trace
in dmesg. Driver handles the failure fine. Root cause: missing
`__GFP_NOWARN` flag.
### Step 1.4: DETECT HIDDEN BUG FIXES
This is a real bug fix disguised with "suppress" language. The
`WARN_ON_ONCE_GFP` macro at line 5226 of `mm/page_alloc.c` was
specifically designed to be suppressed by `__GFP_NOWARN`. The vmxnet3
driver was missing this flag, causing the allocator to emit a warning
the driver was designed to tolerate. This is a legitimate fix for an
incorrect warning.
Record: Yes, this is a real bug fix. The warning is spurious because the
driver handles the failure gracefully.
## PHASE 2: DIFF ANALYSIS
### Step 2.1: INVENTORY THE CHANGES
- **File:** `drivers/net/vmxnet3/vmxnet3_drv.c`
- **Lines changed:** 2 lines modified (net change: 0 added, 0 removed -
just modifications)
- **Function modified:** `vmxnet3_rq_create()`
- **Scope:** Single-file, surgical fix
Record: 1 file, 2 lines changed, in `vmxnet3_rq_create()`. Extremely
small scope.
### Step 2.2: UNDERSTAND THE CODE FLOW CHANGE
- **Line 2271:** `GFP_KERNEL` → `GFP_KERNEL | __GFP_NOWARN` for the data
ring DMA allocation
- **Line 2274:** `"rx data ring will be disabled\n"` → `"failed to
allocate %zu bytes, rx data ring will be disabled\n", sz` to include
the allocation size in the error message
Before: allocation failure triggers WARN_ON_ONCE + generic log message.
After: allocation failure is silent (no WARN) + informative log message
with size.
Record: Two hunks: (1) Add __GFP_NOWARN to suppress spurious warning;
(2) Improve error message with allocation size.
### Step 2.3: IDENTIFY THE BUG MECHANISM
Category: **Logic/correctness fix** - The allocator's `WARN_ON_ONCE_GFP`
macro at `mm/page_alloc.c:5226` is designed to suppress warnings when
`__GFP_NOWARN` is passed. The vmxnet3 driver was missing this flag for
an allocation that is expected to fail on systems without CMA, producing
a scary but meaningless kernel warning.
Record: Missing __GFP_NOWARN flag on an allocation expected to fail. The
WARN_ON_ONCE_GFP macro specifically checks for this flag (verified in
mm/internal.h:92-96).
### Step 2.4: ASSESS THE FIX QUALITY
- Obviously correct: `__GFP_NOWARN` is the standard kernel mechanism for
this exact purpose
- Minimal: 2 lines changed
- Regression risk: Zero - `__GFP_NOWARN` only affects the warning, not
allocation behavior
- Pattern precedent: Same fix applied to r8152 (5cc33f139e11b), gtp
(bd5cd35b782ab), netdevsim (83cf4213bafc4)
Record: Fix is trivially correct, minimal, and follows well-established
kernel patterns. No regression risk.
## PHASE 3: GIT HISTORY INVESTIGATION
### Step 3.1: BLAME THE CHANGED LINES
The affected code was introduced in commit `50a5ce3e7116a7` by
Shrikrishna Khare on 2016-06-16 ("vmxnet3: add receive data ring
support"). This was first included in v4.8-rc1, meaning the buggy code
has been present since kernel 4.8 (~2016).
Record: Buggy code from commit 50a5ce3e7116a7 (v4.8-rc1, June 2016).
Present in ALL active stable trees.
### Step 3.2: FOLLOW THE FIXES TAG
No Fixes: tag present (expected).
### Step 3.3: CHECK FILE HISTORY
84 commits to vmxnet3_drv.c since the buggy code was introduced. The
file is actively maintained. A closely related commit is `ffbe335b8d471`
("vmxnet3: disable rx data ring on dma allocation failure") which fixed
a BUG crash when the same allocation fails. This shows the allocation
failure path is a known problem area.
Record: Active file. The data ring allocation failure path has had real
bugs before (ffbe335b8d471 fixed a BUG/crash).
### Step 3.4: CHECK AUTHOR
Aaron Tomlin is a kernel contributor (primarily in modules, tracing
subsystems). Jakub Kicinski (net maintainer) committed this.
Record: Not a vmxnet3 maintainer, but committed by the net tree
maintainer.
### Step 3.5: DEPENDENCIES
No dependencies. This is a standalone 2-line change that only adds a GFP
flag and improves a log message. The code context exists in all stable
trees since v4.8.
Record: Fully standalone, no prerequisites.
## PHASE 4: MAILING LIST RESEARCH
### Step 4.1-4.5
Lore.kernel.org was unavailable (Anubis protection). However:
- The Link: tag confirms submission via netdev mailing list
- Jakub Kicinski (net maintainer) accepted and committed it
- Jijie Shao provided a Reviewed-by
Record: Unable to fetch lore discussion due to anti-bot protection.
UNVERIFIED: detailed mailing list discussion content. However, the
commit was accepted by the net maintainer.
## PHASE 5: CODE SEMANTIC ANALYSIS
### Step 5.1-5.4: FUNCTION ANALYSIS
`vmxnet3_rq_create()` is called from:
1. `vmxnet3_rq_create_all()` - called during adapter initialization
2. Directly at line 3472 during queue reset/resize
3. `vmxnet3_rq_create_all()` also called at line 3655 during MTU change
The affected allocation is on the normal path (not error-only),
triggered during device initialization and MTU changes. VMware vmxnet3
is ubiquitous in VMware virtual machines.
Record: The function is called during normal device initialization and
reconfiguration. Very common code path for VMware users.
### Step 5.5: SIMILAR PATTERNS
The vmxnet3 driver already uses `__GFP_NOWARN` in
`vmxnet3_pp_get_buff()` at line 1425 for page pool allocations. Multiple
other network drivers have applied the same fix pattern (r8152, gtp,
netdevsim).
Record: Pattern is already used elsewhere in vmxnet3 itself, and widely
across network drivers.
## PHASE 6: STABLE TREE ANALYSIS
### Step 6.1: BUGGY CODE IN STABLE
The buggy code (commit 50a5ce3e7116a7) has been present since v4.8. It
exists in ALL active stable trees (5.10, 5.15, 6.1, 6.6, 6.12, etc.).
Record: Code exists in all active stable trees.
### Step 6.2: BACKPORT COMPLICATIONS
The code at line 2271 in the current tree is still `GFP_KERNEL` (no
__GFP_NOWARN), and the context looks clean. The `%zu` format specifier
for size_t is standard. Should apply cleanly to all stable trees.
Record: Expected clean apply.
### Step 6.3: RELATED FIXES IN STABLE
No prior fix for this specific warning exists.
## PHASE 7: SUBSYSTEM AND MAINTAINER CONTEXT
### Step 7.1: SUBSYSTEM CRITICALITY
- **Subsystem:** drivers/net/vmxnet3 - VMware virtual network driver
- **Criticality:** IMPORTANT - vmxnet3 is the standard NIC in VMware
environments, which powers a vast number of enterprise servers
### Step 7.2: ACTIVITY
The subsystem is actively developed (v9 protocol support recently
added). 84 commits since the data ring feature.
## PHASE 8: IMPACT AND RISK ASSESSMENT
### Step 8.1: WHO IS AFFECTED
All VMware users running vmxnet3 who configure maximum ethtool ring
parameters. VMware is extremely widespread in enterprise.
### Step 8.2: TRIGGER CONDITIONS
Triggered when: (a) user sets ethtool `rx_ring[0].size=4096` and
`data_ring.desc_size=2048` (both maximum values), and (b) system lacks
CMA for large contiguous allocations. This is a realistic configuration
for performance-tuned VMs.
### Step 8.3: FAILURE MODE SEVERITY
The `WARN_ON_ONCE` produces a full kernel stack trace in dmesg that
looks like a kernel bug. While not a crash, it:
- Alarms system administrators
- Can trigger automated monitoring/alerting systems
- May generate unnecessary bug reports
- Severity: MEDIUM (no functional impact, but user-visible alarm)
### Step 8.4: RISK-BENEFIT RATIO
- **Benefit:** Eliminates spurious kernel warning in VMware
environments, improves log message quality
- **Risk:** Essentially zero - `__GFP_NOWARN` only suppresses the
warning, doesn't change allocation behavior
- **Size:** 2 lines, obviously correct
- **Ratio:** HIGH benefit / ZERO risk
## PHASE 9: FINAL SYNTHESIS
### Step 9.1: EVIDENCE COMPILATION
**FOR backporting:**
- Fixes a real user-visible issue (spurious WARN_ON_ONCE stack trace)
- Extremely small and obviously correct (2 lines)
- Zero regression risk
- Well-established pattern (r8152, gtp, netdevsim all did the same)
- vmxnet3 already uses `__GFP_NOWARN` elsewhere in the driver
- Buggy code has been present since v4.8, affects all stable trees
- VMware vmxnet3 is widely used in enterprise
- Accepted by net maintainer Jakub Kicinski
- Improved error message provides better diagnostic information
- Prior crash (ffbe335b8d471) shows this allocation failure path is a
real concern
**AGAINST backporting:**
- Not a crash/security/corruption fix (it's a warning suppression)
- No Fixes: tag or explicit stable nomination
- WARN_ON_ONCE only fires once per boot (limited repeated impact)
### Step 9.2: STABLE RULES CHECKLIST
1. Obviously correct and tested? **YES** - trivial `__GFP_NOWARN`
addition, standard pattern
2. Fixes a real bug? **YES** - spurious kernel warning that alarms
admins
3. Important issue? **MEDIUM** - not a crash, but affects many VMware
users
4. Small and contained? **YES** - 2 lines in 1 file
5. No new features? **YES** - no new features
6. Can apply to stable? **YES** - clean apply expected
### Step 9.3: EXCEPTION CATEGORIES
Not a standard exception category, but analogous to prior stable-
backported `__GFP_NOWARN` fixes.
### Step 9.4: DECISION
The fix is tiny, obviously correct, zero-risk, follows well-established
patterns, and eliminates a spurious kernel warning that can alarm VMware
administrators. While not a crash fix, the WARN_ON_ONCE stack trace is
user-visible and can trigger automated alerting systems. The bar is very
low for risk vs. benefit here.
## Verification
- [Phase 1] Parsed tags: Reviewed-by Jijie Shao, committed by Jakub
Kicinski (net maintainer)
- [Phase 2] Diff analysis: 2 lines changed in vmxnet3_rq_create(): adds
__GFP_NOWARN, improves log message
- [Phase 2] Verified WARN_ON_ONCE_GFP at mm/internal.h:92-96
specifically checks __GFP_NOWARN flag
- [Phase 2] Verified WARN_ON_ONCE_GFP at mm/page_alloc.c:5226 is
triggered when order > MAX_PAGE_ORDER
- [Phase 3] git blame: buggy code introduced in commit 50a5ce3e7116a7
(v4.8-rc1, 2016), present in all stable trees
- [Phase 3] git log: 84 commits to file since buggy code introduced;
active file
- [Phase 3] Related fix ffbe335b8d471 confirms the data ring allocation
failure path has had real bugs
- [Phase 4] UNVERIFIED: Full mailing list discussion (lore unavailable
due to anti-bot)
- [Phase 5] Traced callers: vmxnet3_rq_create() called from
vmxnet3_rq_create_all() during init, MTU change, and queue reset
- [Phase 5] Confirmed vmxnet3 already uses __GFP_NOWARN at line 1425
(vmxnet3_pp_get_buff)
- [Phase 5] Similar pattern in r8152 (5cc33f139e11b), gtp
(bd5cd35b782ab), netdevsim (83cf4213bafc4)
- [Phase 6] Code exists in all active stable trees (since v4.8)
- [Phase 6] Current tree still has GFP_KERNEL at line 2271 - clean apply
expected
- [Phase 8] Failure mode: spurious WARN_ON_ONCE stack trace, severity
MEDIUM
**YES**
drivers/net/vmxnet3/vmxnet3_drv.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c
index 0572f6a9bdb62..40522afc05320 100644
--- a/drivers/net/vmxnet3/vmxnet3_drv.c
+++ b/drivers/net/vmxnet3/vmxnet3_drv.c
@@ -2268,10 +2268,10 @@ vmxnet3_rq_create(struct vmxnet3_rx_queue *rq, struct vmxnet3_adapter *adapter)
rq->data_ring.base =
dma_alloc_coherent(&adapter->pdev->dev, sz,
&rq->data_ring.basePA,
- GFP_KERNEL);
+ GFP_KERNEL | __GFP_NOWARN);
if (!rq->data_ring.base) {
netdev_err(adapter->netdev,
- "rx data ring will be disabled\n");
+ "failed to allocate %zu bytes, rx data ring will be disabled\n", sz);
adapter->rxdataring_enabled = false;
}
} else {
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] xfrm: Wait for RCU readers during policy netns exit
From: Sasha Levin @ 2026-04-20 13:17 UTC (permalink / raw)
To: patches, stable
Cc: Steffen Klassert, Florian Westphal, Sasha Levin, davem, edumazet,
kuba, pabeni, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Steffen Klassert <steffen.klassert@secunet.com>
[ Upstream commit 069daad4f2ae9c5c108131995529d5f02392c446 ]
xfrm_policy_fini() frees the policy_bydst hash tables after flushing the
policy work items and deleting all policies, but it does not wait for
concurrent RCU readers to leave their read-side critical sections first.
The policy_bydst tables are published via rcu_assign_pointer() and are
looked up through rcu_dereference_check(), so netns teardown must also
wait for an RCU grace period before freeing the table memory.
Fix this by adding synchronize_rcu() before freeing the policy hash tables.
Fixes: e1e551bc5630 ("xfrm: policy: prepare policy_bydst hash for rcu lookups")
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
Reviewed-by: Florian Westphal <fw@strlen.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
net/xfrm/xfrm_policy.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/xfrm/xfrm_policy.c b/net/xfrm/xfrm_policy.c
index c32d34c441ee0..4526c9078b136 100644
--- a/net/xfrm/xfrm_policy.c
+++ b/net/xfrm/xfrm_policy.c
@@ -4290,6 +4290,8 @@ static void xfrm_policy_fini(struct net *net)
#endif
xfrm_policy_flush(net, XFRM_POLICY_TYPE_MAIN, false);
+ synchronize_rcu();
+
WARN_ON(!list_empty(&net->xfrm.policy_all));
for (dir = 0; dir < XFRM_POLICY_MAX; dir++) {
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] ixgbe: stop re-reading flash on every get_drvinfo for e610
From: Sasha Levin @ 2026-04-20 13:18 UTC (permalink / raw)
To: patches, stable
Cc: Aleksandr Loktionov, Jedrzej Jagielski, Simon Horman, Rinitha S,
Tony Nguyen, Sasha Levin, przemyslaw.kitszel, andrew+netdev,
davem, edumazet, kuba, pabeni, mateusz.polchlopek,
slawomirx.mrozowicz, stefan.wegrzyn, piotr.kwapulinski,
intel-wired-lan, netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
[ Upstream commit d8ae40dc20cbd7bb6e6b36a928e2db2296060ad2 ]
ixgbe_get_drvinfo() calls ixgbe_refresh_fw_version() on every ethtool
query for e610 adapters. That ends up in ixgbe_discover_flash_size(),
which bisects the full 16 MB NVM space issuing one ACI command per
step (~20 ms each, ~24 steps total = ~500 ms).
Profiling on an idle E610-XAT2 system with telegraf scraping ethtool
stats every 10 seconds:
kretprobe:ixgbe_get_drvinfo took 527603 us
kretprobe:ixgbe_get_drvinfo took 523978 us
kretprobe:ixgbe_get_drvinfo took 552975 us
kretprobe:ice_get_drvinfo took 3 us
kretprobe:igb_get_drvinfo took 2 us
kretprobe:i40e_get_drvinfo took 5 us
The half-second stall happens under the RTNL lock, causing visible
latency on ip-link and friends.
The FW version can only change after an EMPR reset. All flash data is
already populated at probe time and the cached adapter->eeprom_id is
what get_drvinfo should be returning. The only place that needs to
trigger a re-read is ixgbe_devlink_reload_empr_finish(), right after
the EMPR completes and new firmware is running. Additionally, refresh
the FW version in ixgbe_reinit_locked() so that any PF that undergoes a
reinit after an EMPR (e.g. triggered by another PF's devlink reload)
also picks up the new version in adapter->eeprom_id.
ixgbe_devlink_info_get() keeps its refresh call for explicit
"devlink dev info" queries, which is fine given those are user-initiated.
Fixes: c9e563cae19e ("ixgbe: add support for devlink reload")
Co-developed-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Signed-off-by: Jedrzej Jagielski <jedrzej.jagielski@intel.com>
Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com>
Reviewed-by: Simon Horman <horms@kernel.org>
Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
drivers/net/ethernet/intel/ixgbe/devlink/devlink.c | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe.h | 2 +-
drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c | 13 +++++++------
drivers/net/ethernet/intel/ixgbe/ixgbe_main.c | 10 ++++++++++
4 files changed, 19 insertions(+), 8 deletions(-)
diff --git a/drivers/net/ethernet/intel/ixgbe/devlink/devlink.c b/drivers/net/ethernet/intel/ixgbe/devlink/devlink.c
index d227f4d2a2d17..f32e640ef4ac0 100644
--- a/drivers/net/ethernet/intel/ixgbe/devlink/devlink.c
+++ b/drivers/net/ethernet/intel/ixgbe/devlink/devlink.c
@@ -474,7 +474,7 @@ static int ixgbe_devlink_reload_empr_finish(struct devlink *devlink,
adapter->flags2 &= ~(IXGBE_FLAG2_API_MISMATCH |
IXGBE_FLAG2_FW_ROLLBACK);
- return 0;
+ return ixgbe_refresh_fw_version(adapter);
}
static const struct devlink_ops ixgbe_devlink_ops = {
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe.h b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
index dce4936708eb4..047f04045585a 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe.h
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe.h
@@ -973,7 +973,7 @@ int ixgbe_init_interrupt_scheme(struct ixgbe_adapter *adapter);
bool ixgbe_wol_supported(struct ixgbe_adapter *adapter, u16 device_id,
u16 subdevice_id);
void ixgbe_set_fw_version_e610(struct ixgbe_adapter *adapter);
-void ixgbe_refresh_fw_version(struct ixgbe_adapter *adapter);
+int ixgbe_refresh_fw_version(struct ixgbe_adapter *adapter);
#ifdef CONFIG_PCI_IOV
void ixgbe_full_sync_mac_table(struct ixgbe_adapter *adapter);
#endif
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
index 2d660e9edb80a..0c8f310689776 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
@@ -1153,12 +1153,17 @@ static int ixgbe_set_eeprom(struct net_device *netdev,
return ret_val;
}
-void ixgbe_refresh_fw_version(struct ixgbe_adapter *adapter)
+int ixgbe_refresh_fw_version(struct ixgbe_adapter *adapter)
{
struct ixgbe_hw *hw = &adapter->hw;
+ int err;
+
+ err = ixgbe_get_flash_data(hw);
+ if (err)
+ return err;
- ixgbe_get_flash_data(hw);
ixgbe_set_fw_version_e610(adapter);
+ return 0;
}
static void ixgbe_get_drvinfo(struct net_device *netdev,
@@ -1166,10 +1171,6 @@ static void ixgbe_get_drvinfo(struct net_device *netdev,
{
struct ixgbe_adapter *adapter = ixgbe_from_netdev(netdev);
- /* need to refresh info for e610 in case fw reloads in runtime */
- if (adapter->hw.mac.type == ixgbe_mac_e610)
- ixgbe_refresh_fw_version(adapter);
-
strscpy(drvinfo->driver, ixgbe_driver_name, sizeof(drvinfo->driver));
strscpy(drvinfo->fw_version, adapter->eeprom_id,
diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
index 501216970e611..240f7cc3f213f 100644
--- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
+++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
@@ -6289,6 +6289,16 @@ void ixgbe_reinit_locked(struct ixgbe_adapter *adapter)
if (adapter->flags & IXGBE_FLAG_SRIOV_ENABLED)
msleep(2000);
ixgbe_up(adapter);
+
+ /* E610 has no FW event to notify all PFs of an EMPR reset, so
+ * refresh the FW version here to pick up any new FW version after
+ * a hardware reset (e.g. EMPR triggered by another PF's devlink
+ * reload). ixgbe_refresh_fw_version() updates both hw->flash and
+ * adapter->eeprom_id so ethtool -i reports the correct string.
+ */
+ if (adapter->hw.mac.type == ixgbe_mac_e610)
+ (void)ixgbe_refresh_fw_version(adapter);
+
clear_bit(__IXGBE_RESETTING, &adapter->state);
}
--
2.53.0
^ permalink raw reply related
* [PATCH AUTOSEL 6.18] devlink: Fix incorrect skb socket family dumping
From: Sasha Levin @ 2026-04-20 13:18 UTC (permalink / raw)
To: patches, stable
Cc: Li RongQing, Jakub Kicinski, Sasha Levin, jiri, davem, edumazet,
pabeni, przemyslaw.kitszel, anthony.l.nguyen, mateusz.polchlopek,
netdev, linux-kernel
In-Reply-To: <20260420132314.1023554-1-sashal@kernel.org>
From: Li RongQing <lirongqing@baidu.com>
[ Upstream commit 0006c6f1091bbeea88b8a88a6548b9fb2f803c74 ]
The devlink_fmsg_dump_skb function was incorrectly using the socket
type (sk->sk_type) instead of the socket family (sk->sk_family)
when filling the "family" field in the fast message dump.
This patch fixes this to properly display the socket family.
Fixes: 3dbfde7f6bc7b8 ("devlink: add devlink_fmsg_dump_skb() function")
Signed-off-by: Li RongQing <lirongqing@baidu.com>
Link: https://patch.msgid.link/20260407022730.2393-1-lirongqing@baidu.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
Error: Failed to generate final synthesis
net/devlink/health.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/devlink/health.c b/net/devlink/health.c
index 136a67c36a20d..0798c82096bdc 100644
--- a/net/devlink/health.c
+++ b/net/devlink/health.c
@@ -1327,7 +1327,7 @@ void devlink_fmsg_dump_skb(struct devlink_fmsg *fmsg, const struct sk_buff *skb)
if (sk) {
devlink_fmsg_pair_nest_start(fmsg, "sk");
devlink_fmsg_obj_nest_start(fmsg);
- devlink_fmsg_put(fmsg, "family", sk->sk_type);
+ devlink_fmsg_put(fmsg, "family", sk->sk_family);
devlink_fmsg_put(fmsg, "type", sk->sk_type);
devlink_fmsg_put(fmsg, "proto", sk->sk_protocol);
devlink_fmsg_obj_nest_end(fmsg);
--
2.53.0
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox