| Age | Commit message (Collapse) | Author |
|---|
|
The outsrc-set-info H2C used its last reserved byte for nothing. A
newer firmware version reuses that byte to carry whether BT shares
an SPDT switch with WL at the BB level, which the firmware needs to
pick the right RF constraint. Add a v7 variant of the struct with
the top bit of that byte named is_spdt_bb and the rest kept
reserved, a matching H2C sender, and dispatch fcxosi == 7 to it.
Also widen the gnt_set_be branch in the GNT H2C sender to cover
fcxosi == 7, since it shares the same GNT layout as v6, and add the
paired W2B/B2W scoreboard bits that let WL request and BT acknowledge
the LNA-backoff table for this fcxosi version.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-5-pkshih@realtek.com
|
|
The WL status debug dump only printed role, channel and link-mode
state for HW-band 0, even on chips where MLO support means both
bands carry an independent connection. Add an [MLO] line that
prints the operating mode, channel type, RF band and P2P-exist
state for each HW-band side by side, gated on the chip actually
supporting MLO so single-band chips keep the shorter dump.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-4-pkshih@realtek.com
|
|
The role info fields that distinguish HW-band 0 from HW-band 1 were
kept as separate scalar members with a "_hb1" suffix for the second
band, which forced every caller to branch on hw_band and duplicate
the same logic for each member. Convert link_mode, p2p_exist and
role_map in the role info, plus is_5g_hi_ch, go_client_exist,
noa_exist and bg_mode in the WL info, into RTW89_MAC_NUM-indexed
arrays so a single hw_band index addresses both bands.
This lets _update_wl_link_mode(), _update_wl_mlo_info(),
_modify_role_link_mode() and _update_wl_info() drop their
hw_band == RTW89_PHY_1 branches in favor of direct array indexing,
and removes the duplicated per-band assignments at every call site.
The firmware-facing H2C formats are unchanged; only the internal
representation moved from named pairs to an array. Add v11 of the
role info H2C structure and its sender so a later firmware version
bump has a destination to send to. And it should not sharing layout
with the existing v10 structure.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-3-pkshih@realtek.com
|
|
dm->tdd_bind.rf_band holds a bitmask built from BIT(BTC_BT_B2G) and
BIT(BTC_BT_B5G), but _set_rf_trx_para() compared it against the raw
band enum values RTW89_BAND_5G and RTW89_BAND_2G instead of their
BIT() form. Every other site in this file that reads tdd_bind.rf_band
wraps the enum with BIT() before comparing.
Because RTW89_BAND_5G equals 1 and BIT(BTC_BT_B2G) also equals 1, a
Wi-Fi/Bluetooth coexistence session bound to the 2.4 GHz band was
misclassified as BTC_WLINK_V0_5G. This incorrectly skipped the RF
Tx/Rx parameter adjustment for 2.4 GHz STA traffic and kept clearing
wl_stb_chg to 0, so chip->ops->btc_wl_s1_standby() never re-enabled
the Wi-Fi standby workaround for the Bluetooth Tx-to-Rx GNT switch on
RTL8852C, degrading Wi-Fi performance while coexisting with Bluetooth
on 2.4 GHz.
Compare rf_band against BIT(RTW89_BAND_5G) and BIT(RTW89_BAND_2G) to
match its actual bitmask representation.
Signed-off-by: Ching-Te Ku <ku920601@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261004034520.33695-2-pkshih@realtek.com
|
|
The 'imply' in Kconfig to weakly and implicitly select dependencies is
discouraged. Remove them to simply logic.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Closes: https://lore.kernel.org/linux-wireless/7cdc36a9-aadd-4636-8a29-847d89638c8d@app.fastmail.com/T/#t
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20261002065058.13535-1-pkshih@realtek.com
|
|
mm81x_yaps_hw_read_pkts() reads a full 4-byte delimiter and then
subtracts sizeof(delim) from bytes_remaining on every loop iteration,
guarded only by "bytes_remaining > 0". If 1-3 bytes are left in the
window, this reads past the end of the valid data and then subtracts
4 from a value smaller than 4, driving bytes_remaining negative.
A negative bytes_remaining then reaches the total_len > bytes_remaining
branch, where "bytes_remaining" is passed to memcpy() as the copy
length. Implicitly converted to size_t, a negative int becomes a
huge value, turning that memcpy() into a massive out-of-bounds copy.
Bail out of the split loop once fewer than sizeof(delim) bytes remain,
the same way the existing "end of stream" check bails on a zero
delimiter.
Fixes: b1906cea00b0 ("wifi: mm81x: add mm81x Wi-Fi HaLow driver")
Signed-off-by: Muhammad Bilal <meatuni001@gmail.com>
Link: https://patch.msgid.link/20260919192231.272078-1-meatuni001@gmail.com
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
|
|
Wrap the register writes of rtw89_phy_init_rf_nctl() with
rtw89_io_pack/unpack so they are batched into single bus transactions,
reducing API execution time.
8852C USB2.0 AMD B450 initialization time:
rtw89_phy_init_rf_nctl 5355 ms -> 10 ms
Signed-off-by: Johnson Tsai <wenjie.tsai@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-7-pkshih@realtek.com
|
|
Type 15 gain-table records now encode the FEM index in bits 31:16 and
the gain-table version in bits 15:0.
Signed-off-by: Eric Huang <echuang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-6-pkshih@realtek.com
|
|
To cancel some 6 GHz probe cases, it just depends on if a skb matches
some corresponding conditions. Because the decision has nothing to do
with vif, it's redundant to do the cancellation per vif, i.e., single
case will be cancelled multiple times. So, move it out of iteration.
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-5-pkshih@realtek.com
|
|
In rx path, there are skb of Wi-Fi and skb of PPDU. However, skb_ppdu was
used in some places for Wi-Fi skb. It was a bit confused. So, refine the
naming as follow-up. Call skb for skb of Wi-Fi, and call skb_ppdu for skb
of PPDU. Besides, call desc_ppdu for rx_desc_info of PPDU.
(No logic is changed.)
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-4-pkshih@realtek.com
|
|
The "diliver" should be "deliver", so fix them.
(No logic is changed.)
Signed-off-by: Zong-Zhe Yang <kevin_yang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-3-pkshih@realtek.com
|
|
When entering FWIPS, also send the H2C command related to MLO info, the
same as in LPS. Otherwise, the firmware cannot get enough information.
Signed-off-by: Chih-Kang Chang <gary.chang@realtek.com>
Signed-off-by: Ping-Ke Shih <pkshih@realtek.com>
Link: https://patch.msgid.link/20260930064524.39403-2-pkshih@realtek.com
|
|
mm81x_mac_check_fw_disabled_chans() iterates over n_channels entries of
the firmware response without validating the response length against
the array size. A firmware response with n_channels larger than
ARRAY_SIZE(mors_s1ghz_channels) reads past the end of the response
buffer. To fix, make sure we validate the length prior to use.
Assisted-by: LLM
Fixes: b1906cea00b0 ("wifi: mm81x: add mm81x Wi-Fi HaLow driver")
Signed-off-by: Aamir Ahmed <elb12345@hotmail.co.uk>
Link: https://patch.msgid.link/AS8P251MB00015A3FFF9F9A9628CB0BB0C8BE2@AS8P251MB0001.EURP251.PROD.OUTLOOK.COM
[slightly reword commit message]
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
|
|
Count the set bits through bit_pos with hweight16() and an inclusive
mask. Preserve the zero fallback and zero-based index.
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Link: https://patch.msgid.link/20260925195908.252810-3-ynorov@nvidia.com
[remove morsemicro prefix from commit message]
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
|
|
Replace the local nth_bit() helper with fns(), which provides the same
zero-based set-bit selection for rate capability masks.
Signed-off-by: Yury Norov <ynorov@nvidia.com>
Link: https://patch.msgid.link/20260925195908.252810-2-ynorov@nvidia.com
[remove morsemicro prefix from commit message]
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
|
|
Currently we only initialise and start the beaconing process when the
AP interface is first added. If the BSS alone is reconfigured and
beaconing is temporarily stopped, the subsequent call to re-enable
the beacon via BSS_CHANGED_BEACON_ENABLED is ignored and beaconing will
be permanently stopped until the interface is completely re-added.
To fix, move the beaconing start/stop to mm81x_mac_ops_bss_info_changed
and react accordingly to info->enable_beacon and just keep the per-vif
work item init in the add_interface callback.
Fixes: b1906cea00b0 ("wifi: mm81x: add mm81x Wi-Fi HaLow driver")
Signed-off-by: Samuele Yang <samuele.yang@morsemicro.com>
Link: https://patch.msgid.link/20260929033408.69266-1-samuele.yang@morsemicro.com
Signed-off-by: Lachlan Hodges <lachlan.hodges@morsemicro.com>
|
|
GadgetFS passes an excessively large user input len to kmalloc and kmalloc
gives a WARN (see below for details). Suppress it by passing __GFP_NOWARN
to kmalloc used by both ep_write_iter() and ep_read_iter(). Follow the
same method as commit 4f2629ea67e72 ("USB: usbfs: Don't WARN about
excessively large memory allocations").
kmalloc is used to allocate physically contiguous memory for kernel
allocations. For requests larger than KMALLOC_MAX_CACHE_SIZE, kmalloc
uses the page allocator and can only support up to KMALLOC_MAX_SIZE. For
request sizes bigger than KMALLOC_MAX_SIZE, the page allocator can emit a
WARN because kmalloc allocates an order greater than MAX_PAGE_ORDER.
Link: https://lore.kernel.org/DKTTMAS94IMH.2C6ERY0ZIVWVZ@nvidia.com
Fixes: b3c466ce5129 ("page allocator: do not sanity check order in the fast path")
Signed-off-by: Zi Yan <ziy@nvidia.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/all/6a820ebc.9ebadd4d.20b15e.001b.GAE@google.com/
Tested-by: syzbot+805630f1453e490427fa@syzkaller.appspotmail.com
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Acked-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: <stable@vger.kernel.org>
|
|
fault_create_debugfs_attr() has always taken an extra dentry reference on
the created directory (attr->dname = dget(dir)) so that fail_dump() could
print the name via %pd from any context. Nothing anywhere in the tree
ever calls dput() on attr->dname.
For callers with a matching teardown, that unmatched reference causes one
dentry plus its attached inode to leak per fault_create_debugfs_attr /
debugfs_remove_recursive cycle. simple_recursive_removal() drops
debugfs's own +1 ref on the child dentry, but the dget()'d ref keeps its
refcount at 1: the dentry ends up unhashed but pinned, and its inode is
never freed.
Boot-once callers (mm/failslab, block/blk-core, etc.) leak exactly once at
init and never destroy the tree, so the impact there is bounded. But
per-lifecycle callers (drivers/nvme, drivers/infiniband/hw/hfi1,
drivers/mmc, drivers/iommu/iommufd, drivers/media, drivers/misc,
drivers/gpu/drm/msm, drivers/crypto, net/sunrpc) leak on every
create/destroy cycle.
We observed this in production: an NVMe/RDMA host repeatedly reconnecting
to a target that rejected the CRTO Property Get went through ~50 nvme
controller create/destroy cycles per second, and dentry and inode_cache
grew by ~13k pinned objects per 240 s -- unrecoverable through
drop_caches. Byte math matched a per-cycle 1-dentry / 1-inode leak from
the "fault_inject" directory dentry.
Fix this by not holding any external reference in fault_attr. Embed the
directory name as a fixed-size char array (FAULT_ATTR_DNAME_LEN, 64 bytes)
inside struct fault_attr, copied by strscpy() at
fault_create_debugfs_attr() time. fail_dump() prints it via %s.
Advantages of an embedded array over kstrdup() + kfree() paired with a new
destroy API:
- Zero API footprint. No new export and no caller changes required:
callers already own their fault_attr's memory and free it when
they are done, and now that suffices.
- No allocation on the create path.
- fault_create_debugfs_attr() cannot fail from the name-copy step.
- No lifetime coupling between attr->dname and debugfs; the string
is valid for exactly as long as the containing struct.
The 64-byte length accommodates every in-tree caller with generous
headroom (the longest current name is "fail_dma_array_full", 19 chars).
The user-visible fail_dump() format changes from "name %pd" to "name %s",
but the printed content is identical -- %pd on the created directory
renders the same string that was passed in as @name.
drivers/infiniband/hw/hfi1/fault.c drops a now-invalid "attr.dname = NULL"
statement; the surrounding kzalloc() already zero-initialises the array.
Link: https://lore.kernel.org/20260821181527.3271414-1-mliang@purestorage.com
Fixes: 6adc4a22f20b ("fault-inject: add ratelimit option")
Signed-off-by: Michael Liang <mliang@purestorage.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Akinbou Mita <akinobu.mita@gmail.com>
Cc: Dennis Dalessandro <dennis.dalessandro@cornelisnetworks.com>
Cc: Jason Gunthorpe <jgg@ziepe.ca>
Cc: Leon Romanovsky <leon@kernel.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux
Tariq Toukan says:
====================
mlx5: Move data direct infrastructure to mlx5_core
Data direct support currently lives in mlx5_ib, which owns the data
direct PCI driver, device matching and resource management. To prepare
for data direct support in netdev, move this infrastructure to mlx5_core
and provide a common interface for its consumers.
The series first replaces the direct IB unbind callback with a blocking
notifier chain, allowing multiple consumers to receive unbind events.
It then separates consumer registration from initialization, consolidates
the per-device state and resources, and keeps IB-specific locking and MR
teardown in mlx5_ib.
With these preparations in place, the final patch moves the shared
implementation and PCI driver to mlx5_core. Data direct initialization
and resource creation run during core load, before consumers attach;
cleanup runs during core unload, after consumers detach.
The data direct PCI driver is also explicitly named "mlx5_dd", replacing
the previous "mlx5_ib" name derived from KBUILD_MODNAME.
This series prepares the shared infrastructure for netdev support.
The netdev consumer will follow in a separate series.
* 'mlx5-next' of git://git.kernel.org/pub/scm/linux/kernel/git/mellanox/linux:
mlx5: Move data direct implementation to mlx5_core
RDMA/mlx5: Pull data_direct resource creation in init phase
RDMA/mlx5: Consolidate data direct state into one object
RDMA/mlx5: Extract IB specific lock out of data direct
RDMA/mlx5: Add new registration stage for data direct users
RDMA/mlx5: Move and rename data direct resource functions
RDMA/mlx5: Give the data direct PCI driver a proper name
RDMA/mlx5: Make the data direct VUID query self-contained
RDMA/mlx5: Add mlx5_data_direct_supported() helper
RDMA/mlx5: Notify data direct users via a notifier chain on unbind
====================
Link: https://patch.msgid.link/20261004064921.213888-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
pfcp_encap_recv() allocates tun_dst with udp_tun_rx_dst() but only
attaches it to the skb after iptunnel_pull_header() has succeeded.
When iptunnel_pull_header() fails, the code jumps to the drop label,
which frees the skb but not tun_dst, so the metadata_dst is leaked.
iptunnel_pull_header() can fail for a GSO skb that is cloned, when
skb_unclone() cannot allocate a new header with GFP_ATOMIC.
The dst cannot simply be attached earlier, since skb_scrub_packet() in
iptunnel_pull_header() drops it for cross-netns devices. Release it
explicitly on the error paths instead. The !md check can never be true,
but route it through the same label for consistency.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, not seen in real life
Fixes: 6dd514f48110 ("pfcp: always set pfcp metadata")
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Link: https://patch.msgid.link/20260930124818.114224-2-yanhaishuang@cmss.chinamobile.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
pfcp_encap_recv() only makes sure that the UDP header and the 4 byte
PFCP header are in the linear area. When the S flag is set,
pfcp_session_recv() then reads the 8 byte SEID that follows, which is
not covered by the pskb_may_pull() check.
A short PFCP packet with the S flag set, or one whose session header
lies in a fragment, therefore makes pfcp_session_recv() read beyond the
end of the packet data, and whatever it finds there is stored in the
tunnel metadata that flower later classifies on.
Pull up to the end of the SEID before reading it, and drop packets
that are too short to contain it. Reload the header pointer afterwards
since pskb_may_pull() may reallocate the skb head.
Use offsetofend() rather than sizeof(struct pfcphdr_session): the
structure is not packed, so its size is 16 bytes because of the
alignment of the __be64 member, while the header on the wire is only 12
bytes, and valid session messages would be dropped.
Fixes: 6dd514f48110 ("pfcp: always set pfcp metadata")
Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Link: https://patch.msgid.link/20260930124818.114224-3-yanhaishuang@cmss.chinamobile.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When the revised suspend/resume sequence was introduced this led to an edge
case where the TX is left disabled in the following sequence.
1. phy link is down, so UMAC is held in reset and then network interface
is WoL enabled
2. Enter suspend, bcmgenet_wol_power_down_cfg() enables UMAC_RX since MAC
is in SW_RESET
4. Enter resume, UMAC_RX is left enabled. Since we only enable UMAC_TX
and UMAC_RX in SW_RESET. The UMAC_TX is never enabled again on link up.
The issue was hit in production and I verified the sequence keeps
the TX disabled in my standalone test. I tested on an internal
development board with bcm77122, but should be reproducible
on any genet HW that supports power management.
Fixes: 254f3239dd07 ("net: bcmgenet: revise suspend/resume")
Signed-off-by: Justin Chen <justin.chen@broadcom.com>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Link: https://patch.msgid.link/20260930230634.3132729-1-justin.chen@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
netif_stop_queue() in bcmasp_xmit() raced with netif_wake_queue() in
bcmasp_tx_poll(): a reclaim landing between the ring-full check and
the stop call left the queue stopped despite free descriptors,
hanging TX until timeout.
Switch to netif_txq_maybe_stop()/netif_txq_completed_wake() (the
lockless TX queue API, which also brings in BQL), replace
tx_spb_ring_full() with a live bcmasp_tx_avail() count.
This issue was discovered using LLM and is only theoretical.
Tested on a BCM74110 that no regressions were encountered.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, not seen in real life
Fixes: 490cb412007d ("net: bcmasp: Add support for ASP2.0 Ethernet controller")
Signed-off-by: Justin Chen <justin.chen@broadcom.com>
Reviewed-by: Nicolai Buchwitz <nb@tipi-net.de>
Reviewed-by: Florian Fainelli <florian.fainelli@broadcom.com>
Link: https://patch.msgid.link/20260929203400.1588868-1-justin.chen@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
If bnge_netdev_alloc() fails after storing the net_device pointer in
bd->netdev, it calls free_netdev() but leaves bd->netdev as a dangling
pointer.
Explicitly set bd->netdev to NULL on the error path to prevent potential
use-after-free or invalid pointer dereferences.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, not seen in real life
Fixes: 13a68c1ed754 ("bng_en: Add a network device")
Signed-off-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com>
Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com>
Reviewed-by: Rajashekar Hudumula <rajashekar.hudumula@broadcom.com>
Reviewed-by: Ramakrishna Koduri <ramakrishna.koduri@broadcom.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Link: https://patch.msgid.link/20261005121704.227866-5-bhargava.marreddy@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
IRQ affinity hints are advisory and not fatal to driver operations.
On uniprocessor builds (CONFIG_SMP=n), irq_set_affinity_hint() always
returns -EINVAL, which currently prevents ndo_open() from succeeding.
Log a warning and continue instead of failing open on affinity error.
Cc: stable+noautosel@kernel.org # LLM report + LLM fix, not seen in real life
Signed-off-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com>
Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com>
Reviewed-by: Rajashekar Hudumula <rajashekar.hudumula@broadcom.com>
Reviewed-by: Ramakrishna Koduri <ramakrishna.koduri@broadcom.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Link: https://patch.msgid.link/20261005121704.227866-4-bhargava.marreddy@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
If exactly aux_msix vectors are granted, probe continues with zero NQ
vectors. This leads to zero-sized allocations and out-of-bounds array
accesses during ring setup.
Require at least 'min' vectors beyond the aux reservation to ensure the
driver always has an NQ vector to work with.
Cc: stable+noautosel@kernel.org # fix to unlikely driver error path
Fixes: 18a975389fcc ("bng_en: Add irq allocation support")
Signed-off-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com>
Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com>
Reviewed-by: Rajashekar Hudumula <rajashekar.hudumula@broadcom.com>
Reviewed-by: Ramakrishna Koduri <ramakrishna.koduri@broadcom.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Link: https://patch.msgid.link/20261005121704.227866-3-bhargava.marreddy@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
bnge_alloc_core() previously jumped to a single error label that called
bnge_free_core() to unwind. However, bnge_free_core() assumes a fully
initialized state and dereferences rx/tx ring arrays unconditionally.
If ring allocations fail early, this causes a near-NULL dereference.
Introduce a standard goto ladder to unwind only the resources that were
successfully allocated, preventing NULL dereferences.
Cc: stable+noautosel@kernel.org # fix to unlikely driver error path
Fixes: 0259379037ca ("bng_en: Add initial support for RX and TX rings")
Signed-off-by: Bhargava Marreddy <bhargava.marreddy@broadcom.com>
Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com>
Reviewed-by: Rajashekar Hudumula <rajashekar.hudumula@broadcom.com>
Reviewed-by: Ramakrishna Koduri <ramakrishna.koduri@broadcom.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Link: https://patch.msgid.link/20261005121704.227866-2-bhargava.marreddy@broadcom.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Replacing or clearing a TUN eBPF program defers its destruction to
tun_prog_free(). In the device teardown path, tun_free_netdev() can queue
this callback as a private destructor. The rcu_barrier() in
netdev_run_todo() runs before private destructors, so it cannot drain the
new callback.
After the last file or persistent-device reference is released, tun can
therefore unload before the callback runs. Drain outstanding callbacks at
the end of module cleanup so they cannot execute from freed module text.
These issues were found by a static analysis method.
Cc: stable+noautosel@kernel.org # needs real net-admin (non-ns)
Fixes: 96f84061620c ("tun: add eBPF based queue selection method")
Signed-off-by: Jiale Yao <yaojiale02@163.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20261003093822.544964-1-yaojiale02@163.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can
Marc Kleine-Budde says:
====================
pull-request: can 2026-10-01
The first patch is by zjamg and restores the skb header initialization
lost during the v7.0 release cycle.
Oliver Hartkopp contributes a patch for the CAN net layer to fix the
unique skb identifier regression under RPS, introduced in the v7.0
release cycle, which causes lost packets.
The last patch is by Ji-Ze Hong and fixes a struct size mismatch in
the f81604 CAN driver, which results in a TX starvation.
* tag 'linux-can-fixes-for-7.3-20261001' of git://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can:
usb: f81604: fix struct f81604_int_data size mismatch
can: fix unique skb identifier regression under RPS
can: dev: init_can_skb(): restore skb header initialization
====================
Link: https://patch.msgid.link/20261001151905.1556270-1-mkl@pengutronix.de
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
This reverts commit ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx
speed on vport state modification").
mlx5_modify_vport_admin_state() and mlx5_esw_adj_vport_modify() query
the vport's current max_tx_speed before modifying its state, and
write that value back, to avoid resetting it to 0 as a side effect
of an unrelated admin-state change.
That's unnecessary: max_tx_speed is optional in MODIFY_VPORT_STATE -
FW skips writing it whenever it's 0, treating that as "not provided"
rather than "reset to zero". Leaving it unset already preserves FW's
current value, with no query needed.
Fixes: ad0ae7aefa7a ("net/mlx5: E-Switch, preserve max tx speed on vport state modification")
Signed-off-by: Or Har-Toov <ohartoov@nvidia.com>
Reviewed-by: Mark Bloch <mbloch@nvidia.com>
Signed-off-by: Tariq Toukan <tariqt@nvidia.com>
Link: https://patch.msgid.link/20261004083531.216988-1-tariqt@nvidia.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
qca8k_phy_eth_command() polls MASTER_CTRL over management Ethernet until
BUSY clears, but only bails out when the poll timed out and the last
poll request also failed. If every request succeeds while BUSY stays
set, the -ETIMEDOUT is dropped. A read then returns MASTER_CTRL data
from a transaction that has not completed, and
qca8k_internal_mdio_read() does not fall back to the MDIO bus.
A failed poll request does not stop the loop either.
qca8k_phy_eth_busy_wait() leaves the value unchanged on failure, so the
BUSY test then uses the previous value, or an uninitialized one if the
first request fails.
Stop polling when a request fails and return the poll error or timeout.
The poll-error path also leaked read_skb, which is only consumed when the
read request is sent; free it on this path.
The Sashiko review of v1 identified the dropped timeout. A userspace
model of the driver's functions reproduces it and the poll-error path
with scripted BUSY responses and failed poll requests; these cases pass
after this change.
The polling loop comes from commit 2cd548566384 ("net: dsa: qca8k: add
support for phy read/write with mgmt Ethernet").
Signed-off-by: Yongzhao Chen <yongzhao.derek@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20261003172405.342-4-yongzhao.derek@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
qca8k_mdio_write() and qca8k_mdio_read() take the common exit path when
selecting the page of QCA8K_MDIO_MASTER_CTRL fails. That path clears
MASTER_CTRL[31:16] with a raw write to phy 0x10, reg 0x1f, which only
addresses MASTER_CTRL while page 0 is selected. After a failed page
select that did not reach the switch, the previous page remains selected.
The write can then clear the upper half of an unrelated register at
page * 0x200 + 0x3c.
No MDIO master transaction has been started at that point, so there is
nothing to clean up. Unlock and return the error directly.
qca8k_set_page() also keeps the old cached page when the page write
fails. If the write did reach the switch, a later access to the cached
page skips the page select and reaches the wrong register. Invalidate
the cache on failure so that the next access selects the page again.
The Sashiko review of v1 identified the stray cleanup write. A userspace
model of the driver's functions reproduces both problems by injecting
page-select failures with and without a hardware page change; these cases
pass after this change.
The cleanup write comes from commit 759bafb8a322 ("net: dsa: qca8k: add
support for internal phy and internal mdio"), and the stale page cache
from commit ba5707ec58cf ("net: dsa: qca8k: handle qca8k_set_page
errors").
Signed-off-by: Yongzhao Chen <yongzhao.derek@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20261003172405.342-3-yongzhao.derek@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
qca8k_mii_write32() ignores errors from both 16-bit half-word writes.
Its callers (register writes and read-modify-write helpers) then return
the earlier successful page selection or read result, incorrectly
reporting success even when writing the switch register failed.
Propagate write errors from both the low and high half-words through the
regmap paths and internal MDIO master transactions. Attempt to clear
MASTER_EN even if a transaction fails, preserving the initial error, and
report a cleanup failure if the transaction itself succeeded. Preserve
the existing Ethernet-to-MDIO fallback order.
Propagate read errors through the internal and legacy MDIO bus callbacks
instead of masking them as 0xffff. Returning 0xffff causes PHY
read-modify-write callers to treat the failed read as valid register
data, which can corrupt unrelated bits on writeback.
Stop polling when reading the MDIO busy status fails, and return the
error immediately. Because the read helper clears its output on failure,
checking only the BUSY bit mistakes an unsuccessful read for transaction
completion.
Code inspection found these problems. Fault injection into a userspace
model of the driver's functions reproduces them; the corresponding cases
pass after this change.
qca8k_mii_write32() has not returned write errors since its introduction
in commit 6b93fb46480a ("net-next: dsa: add new driver for qca8xxx
family").
Signed-off-by: Yongzhao Chen <yongzhao.derek@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20261003172405.342-2-yongzhao.derek@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
tun sets IFF_DETACH_QUEUE in the flags returned by TUNGETIFF when the
queue is detached, since commit 3d407a80b62f ("tun: Report whether the
queue is attached or not"). tap does not, so userspace cannot tell a
detached macvtap or ipvtap queue from an attached one.
Cloud Hypervisor ran into this when checking queue state on macvtap.
Report the flag from q->enabled, as tun does. Unlike tun, tap accepts
TUNSETIFF on a bound fd, so ignore IFF_DETACH_QUEUE there to keep
writing the TUNGETIFF flags back working.
Signed-off-by: Umang Pokhriyal <umangpokhriyall@gmail.com>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Link: https://patch.msgid.link/20261004174739.36179-1-umangpokhriyall@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Sashiko reported that:
kernel_read_file_from_path() returns negative error for zero-sized
files, so we cannot have "sz == 0" return, remove it and use a
generic error message instead.
Link: https://lore.kernel.org/20260901051335.2202390-1-senozhatsky@chromium.org
Signed-off-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Haoqin Huang <haoqinhuang7@gmail.com>
|
|
Previously, the per-VMA locking could fail in the face of writers which
necessitate a fallback to mmap_lock. The new vma_start_read_unlocked()
will wait for writers instead of failing.
Use the new helper. Wait for writers. Remove the fallback to mmap_lock.
Link: https://lore.kernel.org/20260831203056.838265-5-surenb@google.com
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Todd Kjos <tkjos@android.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: Carlos Llamas <cmllamas@google.com>
Cc: David S. Miller <davem@davemloft.net>
Cc: David Ahern <dsahern@kernel.org>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: David Hildenbrand (Arm) <david@kernel.org>
|
|
tl;dr: lock_vma_under_rcu() is already a trylock. No need to do both it
and mmap_read_trylock().
Long Version:
== Background ==
Historically, binder used an mmap_read_trylock() in its shrinker code.
This ensures that reclaim is not blocked on an mmap_lock. Commit
95bc2d4a9020 ("binder: use per-vma lock in page reclaiming") added support
for the per-VMA lock, but left mmap_read_trylock() as a fallback.
This was presumably because the per-VMA locking can fail for several
reasons and most (all?) lock_vma_under_rcu() callers have a fallback to
mmap_read_trylock().
== Problem ==
The fallback is not worth the complexity here. lock_vma_under_rcu() is
essentially already a non-blocking trylock. The main reason it fails is
also the reason mmap_read_trylock() fails: something is holding
mmap_write_lock().
The only remedy for a collision with mmap_write_lock() is to wait, which
this code can not do. So the "fallback" after lock_vma_under_rcu()
failure is not really a fallback: it is really likely to just be retrying
in vain. That retry in an of itself isn't horrible. But it adds
complexity.
== Solution ==
Now that per-VMA locks are universally available, lock_vma_under_rcu()
will not persistently fail. Rely on it alone and simplify the code. The
removal of the fallback does not affect NOMMU case because binder driver
depends on CONFIG_MMU.
While at it we also make the handling of the cases where the original
binder VMA is gone consistent. There are two cases to consider when
Binder VMA is gone:
1. there is no VMA at that location anymore.
2. there is now another unrelated VMA at that location.
Before this change we handle case 1 by having the shrinker proceed to free
the page, and just skip the zap_vma_range() call. And we handle case 2 by
having the shrinker return LRU_SKIP. While either behavior is acceptable,
we need to handle them in a consistent way. Handle both cases by freeing
the page without touching the VMA (skipping the zap_vma_range()).
Full disclosure: I originally tried to do this with
lock_vma_under_rcu_wait(), but it did not fit well with the mmap_lock
trylock semantics. Claude caught this in a review and suggested the
approach in this path. It seemed sane to me. So, Suggesed-by: Claude, I
guess.
Link: https://lore.kernel.org/20260831203056.838265-3-surenb@google.com
Signed-off-by: Dave Hansen <dave.hansen@linux.intel.com>
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Acked-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Acked-by: Carlos Llamas <cmllamas@google.com>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Shakeel Butt <shakeel.butt@linux.dev>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Todd Kjos <tkjos@android.com>
Cc: Christian Brauner <christian@brauner.io>
Cc: David S. Miller <davem@davemloft.net>
Cc: David Ahern <dsahern@kernel.org>
Cc: Arve Hjønnevåg <arve@android.com>
Cc: David Hildenbrand (Arm) <david@kernel.org>
|
|
After commit 2e8ff2f51dde ("zram: use u32 for entry ac_time tracking"),
idle_store() computes the idle cutoff as:
cutoff = ktime_sub((u32)ktime_get_boottime_seconds(), age_sec);
Because the left operand is cast to u32, when age_sec exceeds the current
uptime the subtraction wraps modulo 2^32 and the huge result is
zero-extended into the s64 cutoff. mark_idle() then marks every entry as
idle instead of matching nothing. For instance, running
echo 86400 > /sys/block/zramX/idle
on a machine up for only two minutes marks all newly written pages idle
and hands them to idle writeback and recompression.
No slot can have been accessed before the system booted, so an age_sec
that reaches back past uptime cannot match any slot. Return early in that
case, without walking the table or taking any slot locks.
Track the cutoff as time64_t rather than ktime_t. Both cutoff and ac_time
are boot-time values in seconds, so a plain arithmetic comparison against
ac_time in mark_idle() is correct and no ktime helpers are needed.
Link: https://lore.kernel.org/20260828083149.45760-1-jiahao.kernel@gmail.com
Fixes: 2e8ff2f51dde ("zram: use u32 for entry ac_time tracking")
Signed-off-by: Hao Jia <jiahao1@lixiang.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Suggested-by: Sergey Senozhatsky <senozhatsky@chromium.org>
Cc: Brian Geffon <bgeffon@google.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Minchan Kim <minchan@kernel.org>
Cc: <stable@vger.kernel.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth
Luiz Augusto von Dentz says:
====================
bluetooth pull request for net:
Core:
- hci_sync: Fix command skb lifetime during scan setup
- hci_sock: Serialize dead-device detachment
- RFCOMM: free the skb when the DLC has no owner
- RFCOMM: connect the session socket without rfcomm_mutex
- RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown
- SCO: serialise sco_conn lifetime against sco_recv_scodata()
- ISO: Reject concurrent BIS listener setup
- ISO: Serialize concurrent connect calls
- MGMT: Fix status of pending commands flushed on power off
Driver:
- btintel_pcie: fix TX descriptor bounds check
- btintel_pcie: use managed IRQ teardown
- btintel_pcie: Add shared HW reset for clean start
* tag 'for-net-2026-10-05' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth:
Bluetooth: ISO: Serialize concurrent connect calls
Bluetooth: ISO: Reject concurrent BIS listener setup
Bluetooth: hci_sync: Fix command skb lifetime during scan setup
Bluetooth: hci_sock: Serialize dead-device detachment
Bluetooth: RFCOMM: Fix NULL tty_dev dereference in rfcomm_dev_shutdown
Bluetooth: btintel_pcie: use managed IRQ teardown
Bluetooth: MGMT: Fix status of pending commands flushed on power off
Bluetooth: btintel_pcie: Add shared HW reset for clean start
Bluetooth: RFCOMM: connect the session socket without rfcomm_mutex
Bluetooth: btintel_pcie: fix TX descriptor bounds check
Bluetooth: SCO: serialise sco_conn lifetime against sco_recv_scodata()
Bluetooth: RFCOMM: free the skb when the DLC has no owner
====================
Link: https://patch.msgid.link/20261005194436.3594085-1-luiz.dentz@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When phy_attach_direct() binds the generic driver itself and the bind
fails, the PHY is left with polling in place of its interrupt.
phy_probe() has already replaced phydev->irq with PHY_POLL by then. The
unwind does not go through phy_detach(), so the restore there does not
run, and a later attach finds a PHY that can only be polled.
Found on a Keenetic KN-1012 while adding the restore in phy_detach(),
as the other way out of the same bind cycle.
Save the interrupt number on entry and put it back on the error path.
The bus table is not the right source here. The same label is reached
when a second attach of a PHY already attached through the generic
driver fails, and there the field is live. The table also misses a
PHY_MAC_INTERRUPT that a MAC wrote into phydev->irq.
Tested on the KN-1012 with a 6.18 distribution kernel and an injected
failure of the generic probe: phydev->irq reads 15 afterwards, and -1
with only the restore in phy_detach().
Cc: stable+noautosel@kernel.org # never worked
Fixes: 6d9f66ac7fec ("net: phy: Fix PHY module checks and NULL deref in phy_attach_direct()")
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Link: https://patch.msgid.link/20261001130236.106059-5-f@lex.la
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
When a PHY's driver is a module that is not loaded yet when the MAC
connects, the PHY gets the generic driver first. phy_probe() then
replaces phydev->irq with PHY_POLL, because genphy has no interrupt
support. Nothing puts the number back, so after the real driver binds
the PHY is polled for the rest of the uptime.
Seen on a Keenetic KN-1012: the Airoha EN8811H behind an MT7531 port
has its driver on the root filesystem. Its devicetree interrupt maps to
irq 15, and after the real driver binds phydev->irq reads -1.
Restore the number when the PHY detaches. It comes from the bus table,
mdiobus->irq[], where the bus or the MAC driver recorded it. Do it only
when phy_attach_direct() bound the generic driver, since that is the
substitution being undone; otherwise the field belongs to whoever wrote
it. Do it before device_release_driver(), because after the release a
probing driver can write the same field.
The store is ordered before the release rather than locked against it:
device_release_driver() takes the device lock itself. A MAC that sets
phydev->irq before phy_start(), as phy.rst describes, is not affected,
since the restore runs on detach, between connections.
Tested on the KN-1012 with a 6.18 distribution kernel: phydev->irq
reads 15 after the real driver binds, and -1 without this patch.
Cc: stable+noautosel@kernel.org # never worked
Fixes: 00db8189d984 ("This patch adds a PHY Abstraction Layer to the Linux Kernel, enabling ethernet drivers to remain as ignorant as is reasonable of the connected PHY's design and operation details.")
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20261001130236.106059-4-f@lex.la
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The interrupt this driver maps for its PHY is written only into
phydev->irq, while the bus table mdiobus->irq[] keeps reading PHY_POLL
for the same address. That table is where phylib records what the bus
described - phy_device_create() seeds phydev->irq from it - so the
number lives only as long as nothing else writes that one field.
Copy the number into the table entry of the PHY this driver found, and
into no other. With an external PHY phy_mask is 0, so other PHYs on the
bus keep polling. The address is known only after the scan, so the
write to phydev->irq stays.
Found going through the drivers that keep a PHY interrupt outside the
bus table, so that the restore on detach later in this series has a
number to hand back here as well.
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20261001130236.106059-3-f@lex.la
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
The interrupt this driver maps for its PHY is written only into
phydev->irq, while the bus table mdiobus->irq[] keeps reading PHY_POLL
for the same address. That table is where phylib records what the bus
described - phy_device_create() seeds phydev->irq from it - so the
number lives only as long as nothing else writes that one field.
Copy the number into the table entry of the PHY this driver attaches,
and into no other. The chip has one PHY interrupt, and on 7801
phy_mask is 0, so other PHYs on the bus keep what the bus gave them.
The address is known only after the scan, so the write to phydev->irq
stays.
Found going through the drivers that keep a PHY interrupt outside the
bus table, so that the restore on detach later in this series has a
number to hand back here as well.
Signed-off-by: Aleksei Sviridkin <f@lex.la>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Link: https://patch.msgid.link/20261001130236.106059-2-f@lex.la
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
bc_transmit() sends the original skb through the last txable port.
When no port is txable, it returns false without consuming the skb, but
team_xmit() still returns NETDEV_TX_OK. AF_PACKET sends then retain the
skb and its socket write-memory charge.
A TX-enabled, link-down port keeps the broadcast transmit op installed.
Carrier can stay up through a second link-up, TX-disabled port or be
forced on by userspace. Free the original skb on the no-port path while
leaving the existing drop accounting intact.
Discovered by Sashiko during review of previous commit.
Cc: stable@vger.kernel.org
Fixes: 5fc889911a99 ("team: add broadcast mode")
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Link: https://patch.msgid.link/20261001182326.572045-3-bestswngs@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
A nonzero dev_queue_xmit() result does not return ownership of the skb.
When an override port's qdisc drops it, the queue override helper used to
try another port or the mode transmit op with the freed skb.
Return the handoff decision separately from transmit success. Select only
the first override port under RCU and stop after handing it the skb,
regardless of the lower transmit result. Keep the existing success and
drop accounting.
BUG: KASAN: slab-use-after-free in sk_skb_reason_drop
Write of size 4 by task poc/5040
sk_skb_reason_drop (net/core/skbuff.c:1240)
dev_kfree_skb_any_reason (net/core/dev.c:3470)
ab_transmit (drivers/net/team/team_mode_activebackup.c:49)
team_xmit (drivers/net/team/team_core.c:1849)
__dev_direct_xmit (net/core/dev.c:4934)
Freed by task 5040:
__tcf_kfree_skb_list (net/sched/sch_generic.c:43)
__dev_queue_xmit (net/core/dev.c:4831)
team_xmit (drivers/net/team/team_core.c:1846)
Kernel panic - not syncing: KASAN: panic_on_warn set ...
Cc: stable@vger.kernel.org
Fixes: 8ff5105a2b9d ("team: add support for queue override by setting queue_id for port")
Reported-by: <co+2cf741c3005abc20@bugs.sh>
Signed-off-by: Weiming Shi <bestswngs@gmail.com>
Link: https://patch.msgid.link/20261001182326.572045-2-bestswngs@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Currently the base non-PTP-capable lan969x variants don't forward any
Ethernet frames:
$ ip link set eth10 up
$ ip addr add 10.0.0.54/24 dev eth10
$ ping 10.0.0.1
PING 10.0.0.1 (10.0.0.1): 56 data bytes
--- 10.0.0.1 ping statistics ---
7 packets transmitted, 0 packets received, 100% packet loss
$ cat /proc/interrupts | grep fdma
20: 0 GIC-0 120 Level sparx5-fdma
$ ip -s link show dev eth10
RX: bytes packets errors dropped missed mcast
20828 102 0 0 0 72
TX: bytes packets errors dropped carrier collsns
0 0 0 0 0 0
Testing showed that starting the domain 0 TOD counter gets networking
working again, but start all three for consistency with the PTP variants.
Fixes: 207966787b71 ("net: sparx5: add feature support")
Suggested-by: Daniel Machon <daniel.machon@microchip.com>
Signed-off-by: Quentin Freimanis <quentin@q-lab.dev>
Reviewed-by: Daniel Machon <daniel.machon@microchip.com>
Link: https://patch.msgid.link/20261005052826.14251-1-quentin@q-lab.dev
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Rather surprisingly, opening /dev/zero read-only then mmap()'ing it
MAP_SHARED gets you true anonymous memory (albeit in a VMA with non-NULL
vma->vm_file).
This is a by-product of MAP_PRIVATE-/dev/zero being how anonymous memory
was mapped in Linux's distant past.
It happens because mmap_zero_prepare() gates on VMA_SHARED_BIT and when
mapping a read-only file MAP_SHARED, do_mmap() clears VMA_SHARED_BIT and
VMA_MAYWRITE_BIT.
The gating is incorrect - the (poorly named) VMA_MAYSHARE_BIT flag exists
explicitly to tell you if something was originally mapped MAP_SHARED.
So the fix is simple - gate on this instead.
This isn't exactly a common use case, but it's unexpected behaviour which
now causes an assert if CONFIG_DEBUG_VM is set.
While this bug has existed since the dawn of time for linux (or at least
since 2.6.12), it hasn't caused issues in the past, so while it's
incorrect behaviour, it doesn't seem necessary to backport that far.
The mapping is now accounted at mmap time and can fail with -ENOMEM under
strict overcommit, and read faults allocate folios. However this is
normal behaviour for a read-only shmem mapping.
Commit 93c0c8dc87f6 ("mm/rmap: use anon pgoff to track MAP_PRIVATE
file-backed anon folios") is the first patch at which the debug assert
fires, so target that instead.
Link: https://lore.kernel.org/20260924-fix-dev-zero-readonly-shared-v1-1-153c2111e323@kernel.org
Fixes: 93c0c8dc87f6 ("mm/rmap: use anon pgoff to track MAP_PRIVATE file-backed anon folios")
Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Reported-by: <syzbot+c181d3198e98f8aef8b9@syzkaller.appspotmail.com>
Closes: https://lore.kernel.org/linux-mm/6ab4ae75.80e1c6cc.1e8e5f.000d.GAE@google.com/
Acked-by: David Hildenbrand (Arm) <david@kernel.org>
Cc: Liam R. Howlett <liam@infradead.org>
Cc: Vlastimil Babka <vbabka@kernel.org>
Cc: Jann Horn <jannh@google.com>
Cc: Pedro Falcato <pfalcato@suse.de>
Cc: Mike Rapoport <rppt@kernel.org>
Cc: Suren Baghdasaryan <surenb@google.com>
Cc: Michal Hocko <mhocko@suse.com>
Cc: Arnd Bergmann <arnd@arndb.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Lance Yang <lance.yang@linux.dev>
|
|
Commit 309b905deee5 ("ipv6: convert CONFIG_IPV6 to built-in
only and clean up Kconfigs") started to call inet6_init() as
device_initcall().
It explains the reason as a race condition on IPv6 addrconf,
but this is not accurate.
The change initially used fs_initcall() but switched to
device_initcall() due to the null-ptr-deref stack trace in
the link below.
It happened because blackhole_netdev_init() uses device_initcall()
and blackhole_netdev was NULL when addrconf_init() called
ipv6_add_dev(blackhole_netdev).
Due to the order in Kbuild,
$ cat -n Kbuild | grep -E "(drivers|net)"
111 obj-y += drivers/
114 obj-$(CONFIG_NET) += net/
using device_initcall() for IPv6 allows built-in drivers to
be initialised earlier, which requires unnecessary NULL checks.
For the same ordering reason, IPv4 uses late_initcall() to
initialise blackhole_netdev.
Given loopback_net_ops is registered in net_dev_init() at
subsys_initcall(), blackhole_netdev_init() can be called
after that.
In addition, some places assume that IPv4 must be initialised
before IPv6. For example, mptcp_proto_v6_init() copies
mptcp_prot to mptcp_v6_prot, which would otherwise have NULL
mptcp_v6_prot.h.hashinfo.
Let's explicitly order blackhole_netdev_init() -> inet_init()
-> inet6_init() before device_initcall() with 3 different
initcall levels:
subsys_initcall : 4 : net_dev_init()
subsys_initcall_sync : 4s : blackhole_netdev_init()
fs_initcall : 5 : inet_init()
fs_initcall_sync : 5s : inet6_init()
device_initcall : 6 : built-in drivers
Note that both IPv4 and IPv6 can still use fs_initcall() thanks
to the order in net/Makefile, but explicit ordering would be
less error-prone.
$ cat -n net/Makefile | grep ipv
17 obj-$(CONFIG_INET) += ipv4/
22 obj-y += ipv6/
Link: https://lore.kernel.org/netdev/20260309074758.0ea95a18@kernel.org/
Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Tested-by: Chris J Arges <carges@cloudflare.com>
Reviewed-by: Fernando Fernandez Mancera <fmancera@suse.de>
Link: https://patch.msgid.link/20261001204752.2572265-2-kuniyu@google.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Commit 9e8db5913264 ("net: avoid false positives in untrusted gso
validation") added a '&& skb->network_header' check before flow-dissecting
GSO packets without VIRTIO_NET_HDR_F_NEEDS_CSUM in
__virtio_net_hdr_to_skb(), because some callers (such as tun_get_user(),
tun_xdp_one(), virtnet_receive_done(), and raw_verify_header()) called
virtio_net_hdr_*_to_skb() before initializing skb->network_header and
skb->dev.
Because __alloc_skb() and __build_skb_around() zero-initialize
skb->network_header to 0 (unlike mac_header and transport_header which
are initialized to ~0U), those four callers always had
skb->network_header == 0 and bypassed flow dissection in
__virtio_net_hdr_to_skb(). More generally, skb->network_header is an
offset from skb->head (where 0 is also a valid offset whenever
skb_headroom(skb) is 0), not a boolean flag.
Whenever the 'if (gso_type && skb->network_header)' branch was skipped,
the fallback 'else if (gso_type)' only pulled nh_min_len + thlen (40 bytes
for TCPv4) without dissecting the packet, without validating ip_proto or
n_proto, and without setting skb->transport_header.
If the packet has a malformed network header, it is not rejected and a
subsequent skb_probe_transport_header() also fails, leaving
skb->transport_header at ~0U (0xffff). Similarly, if an IPv4 packet
carries IP options (ihl > 5) or an IPv6 packet carries extension headers,
pulling only nh_min_len + thlen can leave the TCP header outside
skb->head. In both cases, tcp_hdrlen(skb) in skb_gso_transport_seglen()
reads out-of-bounds:
BUG: KASAN: slab-out-of-bounds in skb_gso_transport_seglen
Read of size 2 by task poc/133
skb_gso_transport_seglen (net/core/gso.c:155)
skb_gso_validate_mac_len (net/core/gso.c:270)
tbf_enqueue (net/sched/sch_tbf.c:260)
dev_qdisc_enqueue (net/core/dev.c:4227)
__dev_queue_xmit (net/core/dev.c:4884)
In addition, checking virtio_net_hdr_match_proto() only inside
'if (!skb->protocol)' before flow dissection both skipped validation when
skb->protocol was pre-set by the caller and rejected VLAN-tagged frames
whose outer L2 protocol is ETH_P_8021Q or ETH_P_8021AD.
Fix this by:
1. Initializing skb->dev and skb->network_header (plus skb->protocol for
IFF_TUN) before virtio_net_hdr_*_to_skb() in tun_get_user(),
tun_xdp_one(), virtnet_receive_done(), and raw_verify_header(). In
tun_get_user(), drop the redundant skb_reset_mac_header(skb) in the
IFF_TUN case since __virtio_net_hdr_to_skb() unconditionally resets
mac_header.
2. Removing '&& skb->network_header' and the unvalidated
'else if (gso_type)' fallback in __virtio_net_hdr_to_skb() so all GSO
packets without VIRTIO_NET_HDR_F_NEEDS_CSUM are flow-dissected, have
their transport header pulled into linear data, and have
skb->transport_header set.
3. Moving the virtio_net_hdr_match_proto() check to after
skb_flow_dissect_flow_keys_basic(), validating keys.basic.n_proto
against hdr_gso_type.
Fixes: 9e8db5913264 ("net: avoid false positives in untrusted gso validation")
Fixes: d5be7f632bad ("net: validate untrusted gso packets without csum offload")
Fixes: 924a9bc362a5 ("net: check if protocol extracted by virtio_net_hdr_set_proto is correct")
Reported-by: Weiming Shi <bestswngs@gmail.com>
Closes: https://lore.kernel.org/netdev/20260927163117.746432-2-bestswngs@gmail.com/
Signed-off-by: Eric Dumazet <edumazet@kernel.org>
Reviewed-by: Willem de Bruijn <willemb@google.com>
Cc: Michael S. Tsirkin <mst@redhat.com>
Link: https://patch.msgid.link/20261001191140.2818991-3-edumazet@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
|
|
Use KVec::zeroed() to create the message buffer in recv_msg() instead of
creating an empty vector and resizing it.
Signed-off-by: Thorsten Blum <blum@kernel.org>
Link: https://patch.msgid.link/20261006065437.58408-3-blum@kernel.org
[ Avoid the unnecessary turbofish syntax. - Danilo ]
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
|
