Some hwmon alarms fall back to STATUS_WORD summary bits when no
individual limit alarm is available. On PMBus 1.2 and newer devices,
pmbus_get_boolean() acknowledges these alarms with the same byte-data
write used for detailed status registers. For example, PB_STATUS_INPUT
is 0x2000, so it is truncated to zero when passed to
_pmbus_write_byte_data(). The resulting write cannot acknowledge the
input alarm.
PMBus 1.3 Part II, sections 10.2.4 and 10.2.5, excludes ordinary
STATUS_BYTE and STATUS_WORD summary bits from individual clearing.
Their summary bits clear when the underlying status bits clear, so
changing this to a word-data write would not fix the generic input
alarm either.
Use the existing page CLEAR_FAULTS path for generic STATUS_WORD
alarms, including devices whose status accessor uses STATUS_BYTE.
Keep individual byte writes for detailed status registers on PMBus
1.2 and newer devices. As with the existing older-device fallback,
CLEAR_FAULTS can clear other latched status; an active condition can
reassert its status.
Fixes: 35f165f089 ("hwmon: (pmbus) Clear pmbus fault/warning bits after read")
Cc: stable@vger.kernel.org
Assisted-by: LLM
Signed-off-by: Vishnu Razdan <vrazdan@openai.com>
Link: https://patch.msgid.link/20260824-vrazdan-pmbus-status-word-b4-v1-1-2606ecd0c029@openai.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
hwmon_notify_event() expects the channel number as its last argument,
taken into account with the type parameter that it is a humidity sensor
type. Given that this device only provides one humidity channel, 0 must
be passed. The custom construct to enumerate the channels makes wrong
assumptions by listing all types together (temperature and humidity).
Remove the custom channel enumeration and pass the right channel to
hwmon_notify_event() for hwmon_humidity_min_alarm and
hwmon_humidity_max_alarm.
Fixes: 3af350929e ("hwmon: Add support for Amphenol ChipCap 2")
Cc: stable@vger.kernel.org
Signed-off-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://patch.msgid.link/20260823-chipcap2_locks-v2-1-6a26c8e9e2fc@gmail.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Gustavo Luiz Duarte says:
====================
netconsole: validate a target's IP address configuration
This series adds two validations to the target configuration when the
user tries to enable it: first whether remote_ip was set, and second
whether local_ip and remote_ip address families match. Refuse to enable
the target if any of those validations fail.
These validations are already done for the target passed on the
command-line, so this aligns dynamic targets with the command-line
behavior.
The first two patches replace the per-target 'ipv6' flag with a
per-address 'family' field, which makes it easier to detect these error
conditions. Patches 3 and 4 implement the actual validations.
Patches 5-7 are follow-ups from previous reviews: move inet_addr from
netpoll.h into netconsole.c, show an unset address as an empty string
rather than "0.0.0.0", document local_ip auto-selection.
====================
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-0-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
An unset local_ip is auto-populated from the egress interface at enable
time, but any value the user writes, including 0.0.0.0, is used as-is.
This deviates from the behavior prior to "netconsole: use the address
family instead of the ipv6 flag", which interpreted 0.0.0.0 as unset.
Document this so the distinction between "unset" and "set to 0.0.0.0" is
clear.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-7-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The struct inet_addr lives in netpoll.h, but since commit a111639647
("netconsole: move local_ip/remote_ip/ipv6 to netconsole_target") the
only user is netconsole. Move the definition into netconsole.c
Suggested-by: Breno Leitao <leitao@debian.org>
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-6-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
An unset address (local_ip/remote_ip), now denoted by AF_UNSPEC,
currently shows "0.0.0.0" in configfs. Print an empty string instead,
which is more clear.
In netconsole_print_banner() we can be even more explicit about it, as
we don't have the risk of userspace trying to parse it.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-5-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The local_ip and remote_ip configfs attributes are written independently
and nothing stops a user from mixing ipv4 and ipv6. This leads to an
ipv4 address being zero-extended into an ipv6 header or an ipv6 address
being truncated to its first 4 bytes for an ipv4 header.
The command-line parser already refuses such a mismatch. This adds a
similar check when a dynamic target is being enabled.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-4-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The command-line path already requires a remote address, but if a user
creates a dynamic target and enables it without setting a remote
address, we currently try sending netconsole traffic to "0.0.0.0".
Refuse to enable a target if the remote address is unset.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-3-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Now that we have the address family in inet_addr, use that and remove
nt->ipv6.
We no longer need netcons_local_ip_unset() to check that all bytes are
zeroes, as that is now denoted by (family == AF_UNSPEC).
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-2-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
netconsole_target stores a single 'bool ipv6' to denote the target's
address family. This makes it hard to detect conditions like "no address
set" or ipv4/ipv6 mixup between local_ip and remote_ip.
Add a 'family' field to inet_addr so each address stores its own address
family: AF_UNSPEC while unset, else AF_INET or AF_INET6.
Nothing reads the new field yet. The next patch switches the users over
and removes the bool. No functional change.
Reviewed-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Gustavo Luiz Duarte <gustavold@gmail.com>
Link: https://patch.msgid.link/20260903-netcons_ipv6-v4-1-bdd183c844d3@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
When parsing a share-root relative native symlink, memcpy copies
smb_target+1 (skipping the leading separator) but uses
strlen(smb_target)+1 as the length, reading one byte past the
allocated buffer.
This fixes the following KASAN splat when accessing an SMB symlink
with a target of '\a\b':
BUG: KASAN: slab-out-of-bounds in smb2_parse_native_symlink+0x4f5/0xca0
Read of size 5 at addr ffff88800878fe21 by task netfsfuzz-execu/1
CPU: 1 UID: 0 PID: 1 Comm: netfsfuzz-execu Tainted: G N
7.2.0-11943-g2709dd5ae32f-dirty #1 PREEMPT(lazy)
Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX, arch_caps fix,
1996)
Call Trace:
<TASK>
dump_stack_lvl+0x7b/0xa0
print_report+0xd0/0x630
kasan_report+0xe5/0x120
kasan_check_range+0x105/0x1b0
__asan_memcpy+0x23/0x60
smb2_parse_native_symlink+0x4f5/0xca0
parse_reparse_point+0x68a/0x1530
reparse_info_to_fattr+0x752/0xa20
cifs_get_fattr+0x873/0x15b0
cifs_get_inode_info+0xc0/0x310
cifs_lookup+0x308/0xa70
__lookup_slow+0x122/0x2b0
lookup_slow+0x50/0x70
path_lookupat+0x525/0xaf0
filename_lookup+0x1f2/0x550
vfs_statx+0xd1/0x1a0
vfs_fstatat+0x65/0xc0
__do_sys_newfstatat+0x9a/0x120
do_syscall_64+0xdd/0x4a0
entry_SYSCALL_64_after_hwframe+0x77/0x7f
Reported-by: Yuanfu Xie <yuanfuxie@stu.pku.edu.cn>
Fixes: 723f4ef904 ("cifs: Fix parsing native symlinks relative to the export")
Suggested-by: Pali Rohar <pali@kernel.org>
Reviewed-by: Pali Rohar <pali@kernel.org>
Reviewed-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Paulo Alcantara <pc@manguebit.org>
Cc: Ronnie Sahlberg <ronniesahlberg@gmail.com>
Cc: Shyam Prasad N <sprasad@microsoft.com>
Cc: Tom Talpey <tom@talpey.com>
Cc: Bharath SM <bharathsm@microsoft.com>
Cc: stable@vger.kernel.org
KSZ8851 errata sheet DS80000716D-page 4 Module 3 [1] states that,
when issuing a software power-down (PMECR[1:0] = 10) followed by a
power-on (PMECR[1:0] = 00), the receiver circuit can fail to start
properly preventing communication. The Transmitter will still send
data, but no data will be received.
The errata sheet also includes a workaround, which states that,
it is recommended that the software power-down feature not be used.
Implement that workaround and drop the entry into software power-down
mode. The ks8851_write_mac_addr() calls entry into normal power-on
mode at the very beginning of the function, therefore dropping the
second call to enter software power-down mode is sufficient here.
The ks8851_net_stop() can only be called after ks8851_net_start()
was already called, and ks8851_net_start() also makes the MAC enter
normal power-on mode, therefore it is also fine to drop the call to
enter software power-down mode from ks8851_net_stop().
This will lead to a slight increase in power consumption, but it also
fixes a sporadic reliability problem on at least KSZ8851-16MLL, which
is where the problem was reported and this fix was tested.
[1] https://ww1.microchip.com/downloads/en/DeviceDoc/80000716D.pdf
Fixes: 3ba81f3ece ("net: Micrel KS8851 SPI network driver")
Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: Marek Vasut <marex@nabladev.com>
Link: https://patch.msgid.link/20260905130327.203851-1-marex@nabladev.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct sk_key does not exist; the type is struct mctp_sk_key.
Use it.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260905095150.42180-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
struct netdevice does not exist; the type is struct net_device.
Use it.
Signed-off-by: Karl Mehltretter <kmehltretter@gmail.com>
Reviewed-by: Randy Dunlap <rdunlap@infradead.org>
Link: https://patch.msgid.link/20260905095116.42147-1-kmehltretter@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Per the GSW145 data sheet, the FCONTX (bits 8:7) and FCONRX (bits 6:5)
flow-control fields of the PHY_ADDR_n register both encode 00 = AUTO,
01 = EN, 10 = reserved, 11 = DIS. GSWIP_MDIO_PHY_FCONTX_EN was 0x0100,
i.e. field value 10 (the reserved encoding), instead of 0x0080 (01 = EN);
FCONRX_EN is already 0x0020 (01). Enabling tx flow control therefore wrote
the reserved value.
Set FCONTX_EN to 0x0080. The register is shared by all supported parts.
Fixes: 14fceff477 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Signed-off-by: Jan Havran (Advantech Czech) <havran.jan@email.cz>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260907134818.16670-4-havran.jan@email.cz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Jan Havran says:
====================
net: dsa: lantiq_gswip: SGMII/2500BASE-X and flow-control fixes
This series fixes three issues in the lantiq_gswip / mxl-gsw1xx DSA driver
found while bringing up a MaxLinear GSW145 over SGMII on a Marvell
Armada 7040 board, with the switch CPU port running 2500BASE-X and the
user ports at 1000BASE-T.
Patch 1 reorders the SerDes NCO clock-rate setup ahead of the SGMII shell
reset. Without it, only the rate the switch was left at by the straps or
the boot loader links up; the other rate comes up but forwards no traffic.
Patch 2 adds the missing SPEED_2500 case to gswip_port_set_speed(); without
it the CPU port was forced to 10 Mbps at 2.5G link-up.
Tested on GSW145 hardware only. The register values are backed by the
public GSW145 data sheet and by the driver's own field encoding; the
xRX200/xRX300 data sheets are not public.
====================
Link: https://patch.msgid.link/20260907134818.16670-1-havran.jan@email.cz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The mxl-gsw1xx driver advertises 2500BASE-X on its SGMII port (via
supports_2500m and gsw1xx_phylink_get_caps()), but the shared
gswip_port_set_speed() has no SPEED_2500 case: at 2.5G every field keeps
its initializer, so mdio_phy = 0 pins the MDIO speed override to 10 Mbps
and no data passes.
At the MAC/MDIO level 2500BASE-X is identical to 1 Gbps (same wide GMII
datapath, same speed override); the rate itself is set in the PCS and
SerDes, not here. This matches the boot loader's PHY_ADDR_4 = 0x32A4 for
the 2.5G strap ("1 Gbps or above"), whose SPEED field is
GSWIP_MDIO_PHY_SPEED_G1 (the field has no encoding above G1). Share the
SPEED_1000 arm via a stacked case label. Its mii_cfg value is a no-op
for 2.5G: gswip_mii_mask_cfg() writes it only for the RGMII port
(mii_cfg[SGMII port] == -1), which cannot reach 2.5G anyway.
Cc: stable+noautosel@kernel.org # never worked
Signed-off-by: Jan Havran (Advantech Czech) <havran.jan@email.cz>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260907134818.16670-3-havran.jan@email.cz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
gsw1xx_pcs_config() releases the SGMII shell from reset via
gsw1xx_pcs_reset() and only afterwards programs NCO_CTRL to select the
SerDes clock rate (1G NCO1 vs 2.5G NCO2). The chip boot loader uses the
other order: NCO_CTRL -> RST_REQ -> SGMII_PHY_HWBU_CTRL (GSW145 data
sheet, section 3.2.8, table 13).
Program NCO_CTRL before gsw1xx_pcs_reset() to follow that order. On an
Armada 7040 board driving a GSW145 whose switch comes up at 2.5G (pin strap
PS_SUBTYPE_MD[2] = 1, pin LED42 / PS1 bit 14; GSW145 data sheet tables 23
and 25), a 1 Gbps SGMII link only carried traffic with this change. It
matters when the rate the switch is left at - by the straps or by the boot
loader - differs from the rate the driver selects, which is likely why it
has not been seen before.
Cc: stable+noautosel@kernel.org # never worked
Signed-off-by: Jan Havran (Advantech Czech) <havran.jan@email.cz>
Reviewed-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com>
Link: https://patch.msgid.link/20260907134818.16670-2-havran.jan@email.cz
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The LED core defines delay_on == 0 as steady off and delay_off == 0 as
steady on, which was treated as a blink in our LED driver. Fix it.
Fixes: 9af9a81682 ("net: dsa: motorcomm: Add LED support")
Signed-off-by: David Yang <mmyangfl@gmail.com>
Link: https://patch.msgid.link/20260904134752.635133-1-mmyangfl@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Drop repeated words reported by checkpatch.pl. Only touches
documentation text.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260907095446.27290-5-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix a typo in comments, found with scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260907095446.27290-4-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix typos in comments, found with scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260907095446.27290-3-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix typos in comments, found with scripts/checkpatch.pl using the
misspelling list in scripts/spelling.txt. Only touches comments, no code
changes.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reviewed-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Link: https://patch.msgid.link/20260907095446.27290-2-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In case iproute2 is older than version 5.11.0, released ~Feb 23, 2021,
the vrftable support is not available and the tests
contained in the following 2 test files
- srv6_end_dt4_l3vpn_test.sh
- srv6_end_dt6_l3vpn_test.sh
are failing in some kernel backports.
This is the result of one of those tests in an unsupported environment:
##########################################################################
TEST SECTION: SRv6 VPN connectivity test among hosts in the same tenant
##########################################################################
TEST: Hosts connectivity: hs-t100-1 -> hs-t100-2 (tenant 100) [FAIL]
TEST: Hosts connectivity: hs-t100-2 -> hs-t100-1 (tenant 100) [FAIL]
TEST: Hosts connectivity: hs-t200-3 -> hs-t200-4 (tenant 200) [FAIL]
TEST: Hosts connectivity: hs-t200-4 -> hs-t200-3 (tenant 200) [FAIL]
The test installs a route with the vrftable feature; if this feature is
not available, the approach taken is to skip the test rather than
failing it.
Signed-off-by: Alessio Faina <alessio.faina@canonical.com>
Reviewed-by: Andrea Mayer <andrea.mayer@uniroma2.it>
Link: https://patch.msgid.link/20260907100631.1923148-1-alessio.faina@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
fqdir_pre_exit() flushes the skbs from incomplete queues without
changing their completion state. A fragment which found a queue before
high_thresh was cleared can then acquire the queue lock and reuse stale
reassembly metadata. A queue concurrently killed after fqdir->dead is
set can instead become INET_FRAG_COMPLETE|INET_FRAG_HASH_DEAD while
still holding its old skbs; skipping it because it is complete leaves
those references behind until asynchronous fqdir teardown.
For IPv6, stale metadata can make ip6_frag_reasm() use the old
nhoffset with a new skb and access memory out of bounds. The resulting
heap corruption can be leveraged for local privilege escalation when
unprivileged network namespaces are available. Unflushed fragments can
also keep conntrack references alive after the conntrack per-net
cleanup point.
Kill each incomplete queue, then flush every queue still owned by the
dying rhashtable. HASH_DEAD identifies that ownership, while complete
queues without it are already owned by another destroy path and must be
left alone. Releasing a timer reference removed by inet_frag_kill() is
deferred to inet_frag_putn(), after the queue lock is dropped.
KASAN report:
BUG: KASAN: slab-out-of-bounds in ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2))
Write of size 1 at addr ff110001039c6e00 by task poc/771
Call Trace:
? ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2))
ipv6_frag_rcv (net/ipv6/reassembly.c:289 (discriminator 2) net/ipv6/reassembly.c:229 (discriminator 2) net/ipv6/reassembly.c:391 (discriminator 2))
ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:479 (discriminator 5))
ip6_input_finish (net/ipv6/ip6_input.c:534)
ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3))
packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142)
__x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880)
The buggy address belongs to the object at ff110001039c6b40
which belongs to the cache skbuff_small_head of size 704
The buggy address is located 0 bytes to the right of
allocated 704-byte region [ff110001039c6b40, ff110001039c6e00)
BUG: KASAN: slab-out-of-bounds in ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1))
Read of size 1 at addr ff110001039c6e08 by task poc/771
Call Trace:
? ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1))
ip6_protocol_deliver_rcu (net/ipv6/ip6_input.c:423 (discriminator 1))
ip6_input_finish (net/ipv6/ip6_input.c:534)
ipv6_rcv (include/net/dst.h:480 (discriminator 3) net/ipv6/ip6_input.c:119 (discriminator 3) net/ipv6/ip6_input.c:109 (discriminator 3) include/linux/netfilter.h:325 (discriminator 3) include/linux/netfilter.h:319 (discriminator 3) net/ipv6/ip6_input.c:351 (discriminator 3))
packet_sendmsg (net/packet/af_packet.c:3110 net/packet/af_packet.c:3142)
__x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880)
packet_sendmsg (net/packet/af_packet.c:2959 net/packet/af_packet.c:3053 net/packet/af_packet.c:3142)
__x64_sys_sendmmsg (net/socket.c:2883 net/socket.c:2880 net/socket.c:2880)
The buggy address belongs to the object at ff110001039c6b40
which belongs to the cache skbuff_small_head of size 704
The buggy address is located 8 bytes to the right of
allocated 704-byte region [ff110001039c6b40, ff110001039c6e00)
Fixes: 006a5035b4 ("inet: frags: flush pending skbs in fqdir_pre_exit()")
Cc: stable@vger.kernel.org
Reported-by: Kimi Security Team <bug-report@moonshot.ai>
Tested-by: Weiming Shi <shiweiming@moonshot.ai>
Reviewed-by: Eric Dumazet <edumazet@google.com>
Signed-off-by: Yilin Zhang <yilinzhang@moonshot.ai>
Link: https://patch.msgid.link/20260904162800.1095662-1-yilinzhang@moonshot.ai
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
If WDT was running at boot, the hardware timeout might be set to values
other than the final software timeout.
To be consistent, set the hardware timeout to match the final software
timeout (i.e., after watchdog_init_timeout()) if WDT was running.
Fixes: ffd264bd15 ("watchdog: msc313e: Check if the WDT was running at boot")
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260828161348.13212-8-tzungbi@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
readw() returns a u16. Left shifting a u16 by 16 bits yields undefined
behavior.
Cast to u32 explicitly before the shift.
Fixes: ffd264bd15 ("watchdog: msc313e: Check if the WDT was running at boot")
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260828161348.13212-7-tzungbi@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
If the hardware watchdog was started by the bootloader and the device is
suspended before userspace opens it, the ping worker (from watchdog
core) is frozen and the active hardware timer continues running. This
leads to a spurious system reset.
Check both watchdog_active() and watchdog_hw_running() when deciding
whether to start or stop the watchdog during suspend and resume.
Additionally, call watchdog_stop_ping_on_suspend() to ensure the ping
worker be correctly paused and restarted during suspend and resume.
Fixes: ffd264bd15 ("watchdog: msc313e: Check if the WDT was running at boot")
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260828161348.13212-6-tzungbi@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
msc313e_wdt_probe() reads from hardware registers without ensuring the
required clock is enabled. Furthermore, if the bootloader leaves the
watchdog running, msc313e_wdt_probe() sets WDOG_HW_RUNNING without
increasing the clock's reference count.
While the clock is currently supplied as a fixed clock by the device
tree (`xtal_div2` in arch/arm/boot/dts/sigmastar/mstar-v7.dtsi) which
masks the physical issue, this still violates the API usage.
Call clk_prepare_enable() before reading WDT registers. If the WDT is
running, leave the clock enabled so the CCF reference counter is
balanced.
Fixes: ffd264bd15 ("watchdog: msc313e: Check if the WDT was running at boot")
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260828161348.13212-5-tzungbi@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
msc313e_wdt_settimeout() unconditionally calls msc313e_wdt_start() which
introduces two severe bugs:
1. If the watchdog is already active, calling start() again will
increase the reference count of the clock again. However stop() is
only called once, the reference count is unbalance.
2. If the watchdog is stopped, calling settimeout() will start
the hardware timer accidentally.
Factor out the register-writing logic into a helper function. Only call
it in settimeout() if the watchdog is running. Otherwise, simply update
`wdev->timeout`.
Fixes: e9800b7994 ("watchdog: Add Mstar MSC313e WDT driver")
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://patch.msgid.link/20260828161348.13212-4-tzungbi@kernel.org
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Jakub Kicinski says:
====================
dpll: fix lies in the Netlink spec
Clashiko started accumulating pre-existing issues in specs so I did
a scan of the families. This set fixes issues discovered in dpll.
====================
Link: https://patch.msgid.link/20260904191023.3869690-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
get_maintainer.pl on Documentation/netlink/specs/dpll.yaml returns only
the YNL and NETWORKING [GENERAL] entries, so a change to the DPLL uAPI
description does not CC any of the DPLL maintainers. Ten other families
(binder, dev-energymodel, ethtool, handshake, mptcp_pm, ovpn, psp,
team, wireguard, rt-*) already list their spec explicitly.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260904191023.3869690-5-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The op doc promises "dump request with target dpll - list all the pins
registered with a given dpll device" and "do request with target dpll
and target pin". Neither exists. pin-get uses attribute-set: pin, so
the id in both requests is DPLL_A_PIN_ID, not a device id; there is no
reachable "target dpll" attribute at all (DPLL_A_PIN_PARENT_ID is in
neither list). dpll_nl_pin_get_dumpit() does not look at the request,
it walks dpll_pin_xa from ctx->idx and emits every registered,
available pin, and there is no dump start callback to consume an id
either.
So the generated dpll_pin_get_dump() sends an id, gets the full list
back and reports no error. Drop the id from the dump request and the
two targeting claims from the doc.
Present since commit 3badff3a25 ("dpll: spec: Add Netlink spec in
YAML").
Same caveat as for pin-set: sending DPLL_A_PIN_ID in a pin-get dump now
fails validation instead of being ignored.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260904191023.3869690-4-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
pin-set advertises top level direction, prio and state, so the
generated policy accepts them and the generated user space API grows
setters for them. dpll_pin_set_from_nlattr() has cases only for
FREQUENCY, PHASE_ADJUST, PARENT_DEVICE, PARENT_PIN, ESYNC_FREQUENCY and
REFERENCE_SYNC - the request succeeds, does nothing and produces no
extack. The three values are only actionable inside the parent-device
nest, where dpll_pin_parent_device_set() handles them next to
DPLL_A_PIN_PARENT_ID, which is what makes them meaningful: a pin can be
registered with more than one device.
Never implemented - "git log -S 'case DPLL_A_PIN_PRIO'" on
dpll_netlink.c comes up empty - the spec has advertised them since
commit 3badff3a25 ("dpll: spec: Add Netlink spec in YAML").
Note that this does change what the kernel accepts: sending one of the
three now fails validation instead of being ignored.
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260904191023.3869690-3-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
dpll_device_get_one() calls dpll_msg_add_clock_quality_level(), which
puts DPLL_A_CLOCK_QUALITY_LEVEL into every device-get reply, dump entry
and device-*-ntf of a device whose driver implements
clock_quality_level_get() - mlx5 does. The &dev-attrs anchor lists 12
attributes and not this one, so struct dpll_device_get_rsp has no field
for it, dpll_device_get_rsp_parse() drops it and dpll.rst does not
document it.
The attribute itself is correctly declared in the dpll attribute set,
only the reply list was missing an entry. Missing since commit
a1afb959ad ("dpll: add clock quality level attribute and op").
Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev>
Link: https://patch.msgid.link/20260904191023.3869690-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
"max" is the exclusive upper bound of enum handshake_handler_class, not
a class a handler can ask for, but the spec lists it as a plain entry.
_init_checks() derives the policy limit from the highest entry, so the
generated policy came out as NLA_POLICY_MAX(NLA_U32, 2) and
handshake_nl_accept_doit() takes class 2 all the way into
handshake_req_next(), which walks hn_requests under hn_lock before
returning -EAGAIN instead of the -EINVAL a bad class deserves.
render-max is how YNL spells this, and unlike a hand written limit it
stays correct when a second handler class is added.
It does change what HANDSHAKE_HANDLER_CLASS_MAX means - the highest
valid class rather than one past it, as in every other Netlink/YNL
family - with the count left as __HANDSHAKE_HANDLER_CLASS_MAX.
The constant is uAPI, but I could not find any user space user,
this constant seems to have been added for kernel's benefit.
I think the risk of changing this is worth taking, having MAX
with different semantics than the rest of Netlink is very confusing.
Acked-by: Chuck Lever <cel@kernel.org>
Reviewed-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Link: https://patch.msgid.link/20260904190410.3864660-2-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
include/linux/key.h has "typedef int32_t key_serial_t" and commit
160f404495 ("handshake: Fix sign of key_serial_t fields") converted
x509.cert and x509.privkey to s32, but accept.peer-identity,
accept.keyring and done.remote-auth were left as u32 - the same
quantity typed both ways inside one family, and a generated user space
struct with __s32 cert next to __u32 keyring. All three come from
key_serial_t storage in net/handshake/tlshd.c (treq->th_peerid[],
treq->th_keyring), and special keyrings are legitimately negative
(KEY_SPEC_PROCESS_KEYRING is -2).
NLA_U32 and NLA_S32 have the same length and no range check here, so
the only wire effect is how the value is printed.
Acked-by: Chuck Lever <cel@kernel.org>
Reviewed-by: Asbjørn Sloth Tønnesen <ast@fiberby.net>
Link: https://patch.msgid.link/20260904190410.3864660-1-kuba@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Matthieu Baerts says:
====================
selftests: net: use KHDR_INCLUDES in CFLAGS
KHDR_INCLUDES is typically used to include headers from the kernel
source directory instead of only relying on the ones from the host: they
can be missing or outdated. See the issue reported in [1] where users
have to set USERCFLAGS instead, which shouldn't be needed.
The kselftest doc [2] recommends assigning KHDR_INCLUDES to CFLAGS in a
target Makefile. lib.mk will set KHDR_INCLUDES to "-isystem
$(top_srcdir)/usr/include" if the user didn't set it, e.g. if the kernel
was built in a different build directory.
Other net targets have KHDR_INCLUDES added to their CFLAGS.
Link: https://lore.kernel.org/275ba183-49fd-45b1-881d-0f362b4c74c0@ovn.org [1]
Link: https://docs.kernel.org/dev-tools/kselftest.html#contributing-new-tests-details [2]
====================
Link: https://patch.msgid.link/20260904-net-sft-nf-khdr_includes-v1-0-92455af428e9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KHDR_INCLUDES is typically used to include headers from the kernel
source directory instead of only relying on the ones from the host: they
can be missing or outdated.
The kselftest doc recommends assigning KHDR_INCLUDES to CFLAGS in a
target Makefile. lib.mk will set KHDR_INCLUDES to "-isystem
$(top_srcdir)/usr/include" if the user didn't set it, e.g. if the kernel
was built in a different build directory.
Other net targets have KHDR_INCLUDES added to their CFLAGS.
Link: https://docs.kernel.org/dev-tools/kselftest.html#contributing-new-tests-details
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
Link: https://patch.msgid.link/20260904-net-sft-nf-khdr_includes-v1-2-92455af428e9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
KHDR_INCLUDES is typically used to include headers from the kernel
source directory instead of only relying on the ones from the host: they
can be missing or outdated.
The kselftest doc recommends assigning KHDR_INCLUDES to CFLAGS in a
target Makefile. lib.mk will set KHDR_INCLUDES to "-isystem
$(top_srcdir)/usr/include" if the user didn't set it, e.g. if the kernel
was built in a different build directory.
Other net targets have KHDR_INCLUDES added to their CFLAGS.
Link: https://docs.kernel.org/dev-tools/kselftest.html#contributing-new-tests-details
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Reviewed-by: Ilya Maximets <i.maximets@ovn.org>
Link: https://patch.msgid.link/20260904-net-sft-nf-khdr_includes-v1-1-92455af428e9@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The test requires at least two CPUs to exercise the distribution of
connections between per-CPU listeners. It currently enforces this
prerequisite with an assertion, causing all test cases to fail on
single-vCPU systems even though no kernel functionality was tested.
Report the unsupported environment as a skip instead. Check the
prerequisite before setting up the network namespace so skipped tests do
not make unnecessary system changes.
Link: https://bugs.launchpad.net/ubuntu-kernel-tests/+bug/2023546
Signed-off-by: Kuba Pawlak <kuba.pawlak@canonical.com>
Link: https://patch.msgid.link/20260904140334.562593-1-kuba.pawlak@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Drop the second 'to', reported by checkpatch.pl as a possible repeated
word. Only touches a comment, no code changes.
Signed-off-by: Hemanth Selam <hemanth.selam@gmail.com>
Link: https://patch.msgid.link/20260907063804.26581-1-hemanth.selam@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Per the watchdog API, a pretimeout value of 0 disables the feature.
However, watchdog_hrtimer_pretimeout_start() fails to verify if the
pretimeout is non-zero before arming the timer.
This omission inadvertently starts the software pretimeout timer,
which could result in the pretimeout handler executing incorrectly
when the watchdog timeout is reached.
Fix this by adding a check for wdd->pretimeout before calling
hrtimer_start(), ensuring the disabled state is respected.
Fixes: 7b7d2fdc8c ("watchdog: Add hrtimer-based pretimeout feature")
Signed-off-by: David Arcari <darcari@redhat.com>
Link: https://patch.msgid.link/20260903182029.936030-1-darcari@redhat.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Andrei Gherzan says:
====================
netdevsim: fix IPsec debugfs byte order
The netdevsim IPsec debugfs file (used by selftests/net/rtnetlink.sh's
ipsec_offload subtest) prints the SA salt and key in host CPU byte
order instead of network byte order, because nsim_sa.key[]/salt are
typed as plain u32 and printed directly with "%08x". This makes the
reported values differ between little-endian and big-endian hosts for
the same underlying key material, and breaks the selftest on
big-endian (e.g. s390x), which hardcodes the little-endian output.
A driver-side fix was proposed in 2022 but stalled in review: keeping
the fields as plain u32 meant sparse could not validate the added
ntohl()/be32_to_cpu() conversions.
https://lore.kernel.org/20220308135106.890270-1-kleber.souza@canonical.com
====================
Link: https://patch.msgid.link/20260908140325.13367-1-andrei.gherzan@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The previous patch ("netdevsim: print IPsec salt/key in network byte
order") makes the netdevsim IPsec debugfs file print salt/key in
network byte order on every host, instead of host CPU byte order.
Update the expected output of kci_test_ipsec_offload() to match: the
values change from the little-endian-only representation to the new,
endianness-independent one. No other changes are needed since the
output is now the same on every architecture.
This depends on the previous driver patch: applied on its own, this
change would regress the test on little-endian hosts (which still
print the old host-order value), though it happens to have no effect
on big-endian hosts (whose old host-order output already matched).
Reported-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Link: https://lore.kernel.org/netdev/20220308135106.890270-1-kleber.souza@canonical.com/
Signed-off-by: Andrei Gherzan <andrei.gherzan@canonical.com>
Link: https://patch.msgid.link/20260908140325.13367-3-andrei.gherzan@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
nsim_sa.key[] and nsim_sa.salt hold raw key material in network byte
order, but are typed as plain u32 and printed with "%08x" in the
debugfs read handler. This prints host-endian, so output differs
between little- and big-endian hosts for the same key:
little-endian: salt=0x61626364 key=0x34333231 38373635 32313039 36353433
big-endian: salt=0x64636261 key=0x31323334 35363738 39303132 33343536
This breaks selftests/net/rtnetlink.sh's ipsec_offload subtest on
big-endian (e.g. s390x), which hardcodes the little-endian output.
Retype key[]/salt to __be32, matching ipaddr[], and convert with
be32_to_cpu() before printing. Output is now network-order on every
host, independent of endianness.
A similar fix was proposed in 2022 but kept the u32 typing, so sparse
couldn't validate the added ntohl() calls and it stalled in review.
Retyping first avoids that problem. `make C=2` on netdevsim reports
the same zero warnings as before this change.
Selftest update follows in the next patch.
Cc: stable+noautosel@kernel.org # never worked
Reported-by: Kleber Sacilotto de Souza <kleber.souza@canonical.com>
Link: https://lore.kernel.org/netdev/20220308135106.890270-1-kleber.souza@canonical.com/
Signed-off-by: Andrei Gherzan <andrei.gherzan@canonical.com>
Link: https://patch.msgid.link/20260908140325.13367-2-andrei.gherzan@canonical.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Matthieu Baerts says:
====================
mptcp: misc fixes for v7.3-rc1
Here are various unrelated fixes:
- Patch 1: Do not reschedule the RTX timer for sockets that fell back to
TCP. A fix for v5.7.
- Patch 2: Avoid copying thmac which will not be used and could be
uninitialised. A fix for v5.7.
- Patch 3: Re-set the request backup flag when SYN cookies are used. A
fix for v5.9.
- Patch 4: Drop pending ADD_ADDR when removing ID0, and avoid a WARN. A
fix for v5.13.
- Patch 5: Handle invalid suboptions where the checksum is requested in
the MP_CAPABLE 4th ACK with data, but not added in the option. A fix
for v5.14.
- Patch 6: Prevent a race between mptcp_disconnect() and the retransmit
timer. A fix for v5.17.
- Patch 7: Fix a use-after-free in the selftests that could lead to
false positive. A fix for v5.17.
- Patch 8: Limit new addresses with the userspace PM to avoid an address
ID overflow. A fix for v5.19.
- Patch 9: Reset the ADD_ADDR retransmission counter when the timer is
reused. A fix for v5.19.
- Patch 10: Remove unneeded and confusing READ_ONCE() annotations. A fix
for v6.13.
- Patches 11-12: Get nstat counters for the current test, not since the
creation of the netns. A fix for v6.19.
- Patch 13: Fix an uninit-value in mptcp_write_data_fin for a corner
case now that only a part of the tcp_out_options struct is reset. A
fix for v7.1.
- Patches 14-15: Two follow-up patches addressing minor comments
discovered after the human review. A fix for v7.3-rc1.
====================
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-0-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Pruning is expansive and destructive, do it only when we expect
to accept the skb triggering the cleanup.
Fixes: e468d37118 ("mptcp: implemented OoO queue pruning")
Cc: stable@vger.kernel.org
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20260908-net-mptcp-misc-fixes-7-3-rc1-v2-15-df1de70348b6@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
