Sync update - #52
Merged
Merged
Conversation
Validate ALIGN(tlv_len, 4) against remaining parser length before consuming bytes from the firmware image. This avoids length underflow on malformed TLVs. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260717173215.393c286488f9.Ia39144dc3ca334325ee4eacb7420901e2446fc23@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Validate ALIGN(tlv_len, 4) before advancing through external debug TLVs to prevent parser length underflow. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260717173215.e08d6550c6ec.Iad64190a7d5cded553aff41973120396aef1b557@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Check tbl_rev bounds before BIT(tbl_rev) to avoid undefined shifts when firmware reports an invalid revision value. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260717173215.52a01f841f2a.Ic0131eaac31d9ff71b169138d9b0865cb39b44a9@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Validate revision is below 32 before BIT(revision) in PPAG parsing. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260717173215.d116dd2efdc1.I3c6cae5cb9d0acc2d94544bc755b0754a91b10ba@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
Reject firmware section TLVs that are shorter than the offset field before subtracting sizeof(offset) from the section size. This prevents size underflow for malformed TLVs. Assisted-by: GitHubCopilot:GPT-5.3-Codex Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com> Link: https://patch.msgid.link/20260717173215.17b040b27edc.I6b32d1e9ad707417e2e604f08a63582456209372@changeid Signed-off-by: Miri Korenblit <miriam.rachel.korenblit@intel.com>
MAX34451 and ADPM chips do not support standard PMBus VIN/IIN limit registers, manufacturer specific min/max registers, or undercurrent or undertemperature fault limits. STATUS_BYTE and STATUS_OTHER are also not available. Accessing these non-existent registers during driver initialization triggers a CML error and asserts ALERT. Handled by blocking these functions during read/write. Fixes: 7a001db ("hwmon: (pmbus/max34440) Add support for MAX34451.") Fixes: 629cf8f ("hwmon: (pmbus/max34440) Add support for ADPM12160") Fixes: 2e0b52f ("hwmon: (pmbus/max34440): add support adpm12200") Fixes: 479bfeb ("hwmon: (pmbus/max34440): add support adpm12250") Signed-off-by: Alexis Czezar Torreno <alexisczezar.torreno@analog.com> Link: https://lore.kernel.org/r/20260716-max34451_fixes-v1-1-a941b27eaecb@analog.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Do not assume there are only bank 0 and bank 1 available, just use '!=' for bank comparison. Fixes: d0ddfd2 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20260711074217.554656-1-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Take INITIAL_JIFFIES into account when setting up next update time. Fixes: d0ddfd2 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20260712110650.1240071-2-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Add missing return value check in the setup function. Fixes: d0ddfd2 ("hwmon: (asus-ec-sensors) add driver for ASUS EC") Signed-off-by: Eugene Shalygin <eugene.shalygin@gmail.com> Link: https://lore.kernel.org/r/20260712130602.1256700-2-eugene.shalygin@gmail.com Signed-off-by: Guenter Roeck <linux@roeck-us.net>
JBL Quantum650 Wireless (0ecb:2125) requires the same workaround that was used for JBL Quantum610 and Quantum810 for limiting the sample rate. Without it, the capture (microphone) stream fails to work. Setting the QUIRK_FLAG_FIXED_RATE flag, as done for the sibling models, makes both playback and capture work correctly. Signed-off-by: Daniel C. Ribeiro <dcoutinho.96@gmail.com> Link: https://patch.msgid.link/20260719090037.40149-1-dcoutinho.96@gmail.com Signed-off-by: Takashi Iwai <tiwai@suse.de>
parse_dfs_referrals() validates that the response contains the fixed referral entry array and, on for-next, the per-referral string offsets. However, the response also contains a PathConsumed value that is later used for DFS path parsing. If a malformed response provides a PathConsumed value larger than the search name, later DFS parsing can advance beyond the end of the path. Validate PathConsumed against the search name length before storing it in the parsed referral. Fixes: 4ecce92 ("CIFS: move DFS response parsing out of SMB1 code") Reviewed-by: Paulo Alcantara (Red Hat) <pc@manguebit.org> Signed-off-by: Yichong Chen <chenyichong@uniontech.com> Signed-off-by: Steve French <stfrench@microsoft.com>
…lldir cifs_filldir() copies the entry name out of an SMB1 TRANS2_FIND_FIRST / FIND_NEXT response using a length (de.namelen) supplied by the server. The kmalloc'd SMB response buffer is bounded, but nothing checks that de.name + de.namelen still lies inside that buffer before the eventual filldir64() -> verify_dirent_name() -> memchr() reads namelen bytes. A hostile SMB1 server that returns an oversized FileNameLength in a directory entry therefore causes memchr() to read past the end of the response slab buffer. Reachable from any user who can list a directory on a CIFS mount served by an attacker-controlled server (getdents64() on the mounted directory): BUG: KASAN: slab-out-of-bounds in memchr+0x71/0x80 Read of size 1 at addr ffff88800e0640cc by task poc/115 Call Trace: dump_stack_lvl+0x64/0x80 print_report+0xce/0x620 kasan_report+0xec/0x120 memchr+0x71/0x80 filldir64+0x4c/0x6a0 cifs_filldir.constprop.0+0x9bb/0x1e00 cifs_readdir+0x2101/0x3380 iterate_dir+0x19c/0x520 __x64_sys_getdents64+0x126/0x210 do_syscall_64+0x107/0x5a0 entry_SYSCALL_64_after_hwframe+0x77/0x7f Pass the end-of-response pointer down to cifs_filldir() and reject entries whose name would extend past that boundary. This bug was discovered by Artiphishell's vTriage pipeline, which generated a userspace reproducer (an emulated hostile SMB1 server plus a getdents64() client) that reliably triggers the KASAN report on an unpatched kernel. The fix below was drafted with the Claude coding assistant; a userspace reproducer is available on request. Assisted-by: Claude:claude-opus-4-7 Signed-off-by: Jay Vadayath <jay@artiphishell.com> Signed-off-by: Steve French <stfrench@microsoft.com>
The userspace-driven timer (utimer) TRIGGER ioctl calls snd_timer_interrupt() directly with no serialization, so two threads triggering the same utimer can run snd_timer_interrupt() on one snd_timer concurrently. snd_timer_process_callbacks() drops timer->lock around each instance callback and marks the in-flight callback with the single SNDRV_TIMER_IFLG_CALLBACK bit; snd_timer_close_locked() waits on that bit to drain an in-flight callback before freeing the instance. The bit cannot represent two concurrent callbacks: when a second interrupt re-queues an instance whose callback is still running, both run at once, the first to finish clears the bit, and the close-path drain then frees the instance (and its callback_data) while the other callback is still live - a use-after-free reachable by any user able to open /dev/snd/timer, both via a user timer instance and via a sequencer queue timer bound to the utimer. snd_timer_interrupt() sets IFLG_CALLBACK before dropping timer->lock, so a concurrent interrupt already observes it under the lock. Skip re-queuing an instance (and its slaves) to the ack/sack list while its callback is in flight; the accumulated pticks are delivered on the next tick, so no event is lost. Fixes: 3774591 ("ALSA: timer: Introduce virtual userspace-driven timers") Cc: stable@vger.kernel.org Suggested-by: Takashi Iwai <tiwai@suse.de> Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei <norbert@doyensec.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/6F9B6501-8E65-4265-B02C-7EFB240D1664@doyensec.com
snd_timer_close_locked() drains the closing instance's own in-flight callback (IFLG_CALLBACK) before freeing it, but not its slaves'. When a master instance is closed, remove_slave_links() clears each slave's ->timer; the slave's own close then reads timer == NULL and takes the branch that skips the drain entirely (snd_timer_stop_slave() also no-ops on a NULL timer). So a slave whose callback is still running when the master is closed is freed underneath the live callback, leading to use-after-free. Drain the slaves too before remove_slave_links() severs them. snd_timer_stop() has already taken this instance off the active list, so no new slave callback can be queued. Take the slaves off the ack list so a pending one can't fire either, then wait for any that is already in flight. Fixes: 3774591 ("ALSA: timer: Introduce virtual userspace-driven timers") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-4-8 Signed-off-by: Norbert Szetei <norbert@doyensec.com> Signed-off-by: Takashi Iwai <tiwai@suse.de> Link: https://patch.msgid.link/D26598EB-DBF7-4D76-9F71-8E4BD59822D4@doyensec.com
ovpn_peer_release_p2p() is called when an OVPN UDP socket is being destroyed. It checks the currently published P2P peer and releases it only if that peer still uses the socket being destroyed. A peer replacement can publish a new peer before the old UDP socket is destroyed. When the old socket destruction path runs afterwards, ovpn_peer_release_p2p() observes the new peer through ovpn->peer. Since the new peer uses a different socket, the function takes the socket mismatch branch. That branch still calls ovpn_peer_put(peer). At this point, however, peer is the currently published replacement peer, not the peer associated with the socket being destroyed. Dropping its reference can free it while ovpn->peer still points to it, leading to later use-after-free accesses from the peer and socket cleanup paths. KASAN reports this as a slab-use-after-free on the kmalloc-1k ovpn_peer object. In the reproducer, the object is allocated from ovpn_peer_new() via ovpn_nl_peer_new_doit(), and freed through ovpn_peer_release_rcu() from RCU callback processing. Observed access sites include ovpn_peer_remove(), ovpn_socket_release(), ovpn_nl_peer_del_notify(), and unlock_ovpn(). Fix this by returning from the socket mismatch branch without putting the peer. Fixes: f6226ae ("ovpn: introduce the ovpn_socket object") Signed-off-by: Qing Ming <a0yami@mailbox.org> Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
When either the TCP RX or TX error path calls ovpn_peer_hold() followed
by schedule_work(&peer->tcp.defer_del_work), and the work item is already
pending from the other path, schedule_work() returns false and the work
runs only once. Since ovpn_tcp_peer_del_work() calls ovpn_peer_put()
exactly once, the extra reference taken by the losing path is never
dropped, leaking the peer object.
The race window:
CPU0 (strparser/RX error): CPU1 (tcp_tx_work/TX error):
ovpn_peer_hold() <- refcnt+1 ovpn_peer_hold() <- refcnt+2
schedule_work() <- queued schedule_work() <- NO-OP
(work already pending)
ovpn_tcp_peer_del_work runs:
ovpn_peer_del()
ovpn_peer_put() <- refcnt+1
<- peer never freed
Fix by checking the return value of schedule_work() in both paths and
calling ovpn_peer_put() to drop the extra reference if the work was
already pending. ovpn_peer_hold() is kept unconditional in the TX path
as it cannot fail at that point.
Fixes: a6a5e87 ("ovpn: avoid sleep in atomic context in TCP RX error path")
Cc: stable@vger.kernel.org
Signed-off-by: Pavitra Jha <jhapavitra98@gmail.com>
Reviewed-by: Sabrina Dubroca <sd@queasysnail.net>
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
ovpn_peer_keepalive_send() passes its peer reference to ovpn_xmit_special(), which ultimately drops it. The keepalive scheduler currently queues the work first and takes the reference only after schedule_work() reports that the work was queued. Once schedule_work() queues the item, another CPU may run the worker before the caller gets to ovpn_peer_hold(). In that case the worker can consume a reference that was not acquired for it, corrupting the peer lifetime accounting. Take the peer reference before queueing the work and drop it again when the work was already pending. Fixes: 3ecfd93 ("ovpn: implement keepalive mechanism") Cc: stable@vger.kernel.org Signed-off-by: Shuvam Pandey <shuvampandey1@gmail.com> Reviewed-by: Sabrina Dubroca <sd@queasysnail.net> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
The ovpn_parse_remote() function has two memory management issues: 1. When both 'host' and 'vpnip' are non-NULL, the first getaddrinfo() allocation is leaked because 'result' is overwritten by the second getaddrinfo() call without freeing the first allocation. 2. When both 'host' and 'vpnip' are NULL, 'result' is an uninitialized stack variable passed to freeaddrinfo(), which is undefined behavior. Fix by initializing 'result' to NULL and calling freeaddrinfo() after the first getaddrinfo() result is consumed. Fixes: 959bc33 ("testing/selftests: add test tool and scripts for ovpn module") Signed-off-by: longlong yan <yanlonglong@kylinos.cn> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
unlock_ovpn() iterates over the release_list using llist_for_each_entry() and drops the peer reference inside the loop body via ovpn_peer_put(). If this drops the last reference, the peer is eventually freed. However, llist_for_each_entry() reads peer->release_entry.next in the loop advance expression, which runs after the body. By that time the peer may have already been freed, resulting in a use after free when advancing to the next list entry. Fix this by using llist_for_each_entry_safe(), which caches the next pointer before executing the loop body. Fixes: 80747ca ("ovpn: introduce the ovpn_peer object") Signed-off-by: Marco Baffo <marco@mandelbit.com> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
Replace ktime_get_real_seconds() with the monotonic ktime_get_boottime_seconds() to ensure the keepalive mechanism is robust against system clock modifications. Right now, the driver uses ktime_get_real_seconds() to track peer timeouts, relying on the system wall-clock. An administrative time adjustment or an NTP sync that steps the clock forward can cause `now' to instantly exceed `last_recv + timeout'. When this occurs, the driver artificially expires healthy peers. Depending on the OpenVPN user-space configuration, this triggers a premature tunnel restart (if --keepalive or --ping-restart is used) or a complete disconnection of the client (if --ping-exit is used). Fixes: 3ecfd93 ("ovpn: implement keepalive mechanism") Signed-off-by: Marco Baffo <marco@mandelbit.com> Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
The OCC poll response parser walks a counted list of sensor data blocks. It used the static backing-array capacity as the parse boundary, but a transport response makes only data_length bytes current and valid. A truncated response can therefore make the parser consume a block header or block extent outside the current response. Use data_length as the parent boundary, prove the fixed poll header and each current block header before reading them, and prove the complete block before advancing. Keep parsed sensor metadata local until the complete response has passed validation, then publish it. Propagate malformed-response errors before publishing the OCC as active. Fixes: aa195fe ("hwmon (occ): Parse OCC poll response") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Link: https://lore.kernel.org/r/20260720115826.14813-1-pengpeng@iscas.ac.cn Signed-off-by: Guenter Roeck <linux@roeck-us.net>
cifs client and ksmbd server were missing the git branch info in the MAINTAINERS file. They just were showing the git tree. Signed-off-by: Steve French <stfrench@microsoft.com>
The firmware on the Lunnen Ground 14 marks pin 0x1b as unused even though the internal speakers are connected to it. As a result, the speakers are not detected. Add a pin configuration quirk for PCI subsystem ID 2782:a212 to configure pin 0x1b as an internal speaker. The pin configuration was tested on a Lunnen Ground 14 (DMI product LL4FA) with an ALC269VC codec. The internal speakers and microphone work as expected. Cc: stable@vger.kernel.org Signed-off-by: Nikita Maksimov <nickstogramm@yandex.ru> Link: https://patch.msgid.link/20260720180214.73770-1-nickstogramm@yandex.ru Signed-off-by: Takashi Iwai <tiwai@suse.de>
Add a codec SSID quirk for Samsung ELECTRONICS 750XBE/730XBE using HDA_CODEC_QUIRK() instead of SND_PCI_QUIRK(), because the alsa-info report from this device does not expose a PCI subsystem ID, only the HDA codec subsystem ID (0x144d:0xc824) is available. This applies ALC298_FIXUP_SAMSUNG_HEADPHONE_VERY_QUIET to fix sound being very low and distorted on the headphone jack of this system. Reported-by: Caio Ramos <caioramos97@gmail.com> Link: https://bugzilla.kernel.org/show_bug.cgi?id=208663 Signed-off-by: Zhang Heng <zhangheng@kylinos.cn> Link: https://patch.msgid.link/20260720123702.799474-1-zhangheng@kylinos.cn Signed-off-by: Takashi Iwai <tiwai@suse.de>
tas2563_save_calibration() assigns cali_data.total_sz before it reads the per-device calibration data from EFI, but its error paths return without clearing it again. cali_data.cali_reg_array is left all zero, because the function returns before the register addresses are assigned. On the first playback tasdev_load_calibrated_data() does if (!data || !cali_data->total_sz) return; which passes, since total_sz is still non-zero. It then issues five 4-byte bulk writes to p->r0_reg, p->r0_low_reg, p->invr0_reg, p->pow_reg and p->tlimit_reg, all of which are 0. Register 0 decodes to book 0 / page 0 / register 0x00, so the auto-incrementing block write zeroes registers 0x00 to 0x03. Register 0x03 is PB_CFG1, which holds AMP_LEVEL, so the amplifier gain is set to its minimum and the speaker stays silent. This is reproducible on a Lenovo Yoga 7 14ARB7 (two TAS2563 on I2C, ACPI INT8866) whose factory calibration was never written to UEFI, so the EFI read fails with EFI_NOT_FOUND. The two woofers driven by the amplifiers are silent while the tweeters driven directly by the ALC287 play. Reading the amplifier registers over i2c shows PWR_CTL = 0x00 (active) and the TDM slots correctly programmed by the RCA profile, but PB_CFG1 = 0x00. With this change PB_CFG1 keeps its power-on default of 0x20 and both woofers play. tas2781_save_calibration() in tas2781_hda.c already clears total_sz on failure; do the same for the TAS2563 variant. Signed-off-by: Philipp Oster <philippdev5396@outlook.de> Link: https://patch.msgid.link/20260720-tas2781-calfix-v1-1-3a5fa6ad90bc@outlook.de Signed-off-by: Takashi Iwai <tiwai@suse.de>
The hci_sync conversion moved class-of-device and EIR generation from an
HCI request built under hdev->lock to asynchronous command sync work.
The worker holds hdev->req_lock, but that lock does not serialize access
to hdev->uuids against add_uuid() and remove_uuid(), which update the
list under hdev->lock.
The following interleaving can therefore occur:
CPU0 (command sync work) CPU1 (management socket)
fetch uuid from the list
list_del(&uuid->list)
kfree(uuid)
read uuid->size
KASAN reports the resulting use-after-free:
BUG: KASAN: slab-use-after-free in eir_create+0xb8f/0xee0
Read of size 1 at addr ffff88810dbd8620 by task kworker/u17:0/87
Workqueue: hci0 hci_cmd_sync_work
Call Trace:
eir_create+0xb8f/0xee0
hci_update_eir_sync+0x1c0/0x330
hci_cmd_sync_work+0x13c/0x290
process_one_work+0x63a/0x1070
worker_thread+0x45b/0xd10
Allocated by task 86:
__kasan_kmalloc+0x8f/0xa0
add_uuid+0x18a/0x4b0
hci_sock_sendmsg+0x1033/0x1ea0
Freed by task 92:
__kasan_slab_free+0x43/0x70
kfree+0x131/0x3c0
remove_uuid+0x25e/0x560
hci_sock_sendmsg+0x1033/0x1ea0
Hold hdev->lock while generating and committing the class-of-device and
EIR snapshots. Release it before sending an HCI command, so controller
waits do not happen under the device lock. This protects all UUID list
walks in these paths and restores the serialization lost in the command
sync conversion.
Fixes: 161510c ("Bluetooth: hci_sync: Make use of hci_cmd_sync_queue set 1")
Cc: stable@vger.kernel.org
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
rfcomm_tty_set_termios() tests dlc->session without rfcomm_mutex and
later passes the pointer to rfcomm_send_rpn(). The latter dereferences
both session->initiator and session->sock. Meanwhile, krfcommd can
unlink the DLC and free the session while holding rfcomm_mutex.
The race can proceed as follows:
TTY ioctl task krfcommd
-------------- --------
load dlc->session
enter rfcomm_send_rpn()
lock rfcomm_mutex
clear dlc->session
free session
unlock rfcomm_mutex
read session->initiator
KASAN reported:
BUG: KASAN: slab-use-after-free in rfcomm_send_rpn+0x297/0x2a0
Read of size 4 at addr ffff88810012a850 by task poc/92
Call Trace:
rfcomm_send_rpn+0x297/0x2a0
rfcomm_tty_set_termios+0x50d/0x850
tty_set_termios+0x596/0x950
set_termios+0x46a/0x6e0
tty_mode_ioctl+0x152/0xbd0
tty_ioctl+0x915/0x1240
__x64_sys_ioctl+0x134/0x1c0
Allocated by task 92:
rfcomm_session_add+0x9e/0x2e0
rfcomm_dlc_open+0x8b1/0xe00
rfcomm_dev_activate+0x85/0x1a0
rfcomm_tty_open+0x90/0x280
Freed by task 68:
kfree+0x131/0x3c0
rfcomm_session_del+0x119/0x180
rfcomm_run+0x737/0x4710
Add rfcomm_dlc_send_rpn(), which holds rfcomm_mutex while it verifies
that the DLC is still attached and sends the RPN frame. Have the TTY
path use the helper and drop its unlocked session check. This keeps the
session valid through both the frame construction and socket send.
Fixes: 3a5e903 ("[Bluetooth]: Implement RFCOMM remote port negotiation")
Cc: stable@vger.kernel.org
Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com>
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
btusb_recv_event_realtek() reads the event code at data[0] and the Realtek subevent code at data[2] before deciding whether to consume a vendor event as a coredump. For example, the two-byte event ff 00 contains a complete vendor-event header declaring zero parameters. The old classifier still reads a nonexistent third byte and can misclassify the event as a coredump if the adjacent byte is 0x34. Require the HCI event header and first parameter to be present before inspecting the Realtek subevent code. Short events continue through the normal HCI receive path, which owns their protocol validation. Fixes: 044014c ("Bluetooth: btrtl: Add Realtek devcoredump support") Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Return the correct error code, not the value written to the register. Fixes: a219912 ("net: phy: marvell: implement config_inband() method") Signed-off-by: Michael Walle <mwalle@kernel.org> Reviewed-by: Maxime Chevallier <maxime.chevallier@bootlin.com> Link: https://patch.msgid.link/20260706120637.1947685-1-mwalle@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The IPv6 addresses used for the tun_vnet_udptnl fixture currently fall in the 2002::/16 prefix, which is reserved for the 6to4 transition mechanism (RFC 3056). On systems where the sit module is loaded, the kernel automatically claims 2002::/16 as a 6to4 tunnel prefix. When the test assigns a 2002:: address to a TUN interface, sit registers a competing local route for the same address. This ambiguity breaks the GENEVE decapsulation path: packets injected via the TUN fd are not delivered to the test socket, causing the IPv6-outer gtgso send_gso_packet variants to fail. Replace all four IPv6 test addresses with addresses from the fd00:db8::/32 range, which is part of the ULA space (fc00::/7, RFC 4193) and carries no special kernel semantics. Fixes: 24e59f2 ("selftest: tun: Add helpers for GSO over UDP tunnel") Signed-off-by: Ricardo B. Marlière <rbm@suse.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20260706-b4-net_tun_addr-v1-1-3d3cb2473560@suse.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The pf->txtime_txqs bitmap tracks which Tx queues have ETF (Earliest TxTime First) offload enabled. This bitmap is indexed by queue number and is set by ice_offload_txtime(), which only operates on PF VSI queues. However, ice_is_txtime_ena() does not check the VSI type before consulting the bitmap. When ETF offload is enabled on PF Tx queue 0, bit 0 is set in pf->txtime_txqs. During a subsequent PCI reset rebuild, the CTRL VSI's Tx queue 0 is reconfigured and ice_is_txtime_ena() is called for that ring. Since it only checks pf->txtime_txqs by queue index without distinguishing VSI type, it finds bit 0 set and returns true, matching the PF VSI's ETF queue, not the CTRL VSI's. This causes ice_vsi_cfg_txq() to spuriously allocate a tstamp_ring for the CTRL VSI ring. Since CTRL VSI rings have no associated netdev, ice_clean_tx_ring() takes an early return at the !netdev check before reaching ice_free_tx_tstamp_ring(), leaking the allocation. Each PCI reset leaks one 64-byte tstamp_ring. Fix this by restricting ice_is_txtime_ena() to return true only for PF VSI rings, since txtime_txqs is only meaningful for PF VSI queues. Fixes: ccde82e ("ice: add E830 Earliest TxTime First Offload support") Signed-off-by: Paul Greenwalt <paul.greenwalt@intel.com> Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Tested-by: Rinitha S <sx.rinitha@intel.com> (A Contingent worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260717185340.3595286-11-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
set_bit(rslt->ptype, prof->ptypes) operates on a DECLARE_BITMAP of ICE_FLOW_PTYPE_MAX (1024) bits. Nothing prevents a malicious VF from providing ptype >= 1024 through VIRTCHNL, resulting in a write past the end of the bitmap and a kernel page fault. Reproduced with a custom kernel module injecting a crafted VIRTCHNL_OP_ADD_RSS_CFG on E810-C QSFP (8086:1592), FW 4.91 0x800214af 1.3909.0, ICE COMMS DDP 1.3.53.0, kernel 7.1.0-rc1. crash_parser: ice_parser_profile_init @ ffffffffc0d61b60 crash_parser: setting ptype=0xffff (max valid=1023) crash_parser: calling ice_parser_profile_init -- expect OOB crash! BUG: kernel NULL pointer dereference, address: 0000000000000000 Oops: Oops: 0002 [#1] SMP NOPTI CPU: 56 UID: 0 PID: 165011 Comm: insmod Kdump: loaded Tainted: G S U OE 7.1.0-rc1 #1 Hardware name: Intel Corporation S2600BPB/S2600BPB RIP: 0010:ice_parser_profile_init+0x2d/0x1d0 [ice] Call Trace: <TASK> ? __pfx_ice_parser_profile_init+0x10/0x10 [ice] crash_init+0x127/0xff0 [crash_parser] do_one_initcall+0x45/0x310 do_init_module+0x64/0x270 init_module_from_file+0xcc/0xf0 idempotent_init_module+0x17b/0x280 __x64_sys_finit_module+0x6e/0xe0 Bail out early with -EINVAL when ptype is out of range. Fixes: e312b3a ("ice: add API for parser profile initialization") Cc: stable@vger.kernel.org Signed-off-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Marcin Szycik <marcin.szycik@linux.intel.com> Tested-by: Rafal Romanowski <rafal.romanowski@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260717185340.3595286-12-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Set adapter->max_vports only after successful allocation of vports, netdevs and vport_config buffers. This fixes possible crashes on reset or rmmod, following failed allocation on init [ 305.981402] idpf 0000:83:00.0: enabling device (0100 -> 0102) [ 305.994464] idpf 0000:83:00.0: Device HW Reset initiated [ 320.416872] BUG: kernel NULL pointer dereference, address: 0000000000000000 [ 320.416918] #PF: supervisor read access in kernel mode [ 320.416942] #PF: error_code(0x0000) - not-present page [ 320.416963] PGD 2099657067 P4D 0 [ 320.416983] Oops: Oops: 0000 [#1] SMP NOPTI ... [ 320.417093] RIP: 0010:idpf_remove+0x118/0x200 [idpf] [ 320.417130] Code: 8b bb 98 09 00 00 e8 17 0f 5b e5 48 8b bb e8 08 00 00 e8 0b 0f 5b e5 66 83 bb 28 06 00 00 00 48 8b bb 20 06 00 00 74 49 31 ed <48> 8b 04 ef 48 85 c0 74 2f 48 8b 78 20 e8 66 58 91 e5 48 8b 83 20 [ 320.417183] RSP: 0018:ff7322212903fdb8 EFLAGS: 00010246 [ 320.417205] RAX: 0000000000000000 RBX: ff4463de40300000 RCX: ff7322212903fd4c [ 320.417228] RDX: 0000000000000001 RSI: ffffffffa7f7d100 RDI: 0000000000000000 [ 320.417250] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000 [ 320.417272] R10: 0000000000000001 R11: ff4463de3a638f58 R12: ff4463be89ac7000 [ 320.417294] R13: ff4463be89ac7198 R14: ff4463be94fc7198 R15: ffffffffc0f10f20 [ 320.417317] FS: 00007f963c0e6740(0000) GS:ff4463fdd65d8000(0000) knlGS:0000000000000000 [ 320.417342] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 320.417362] CR2: 0000000000000000 CR3: 00000020ba674002 CR4: 0000000000773ef0 [ 320.417385] PKRU: 55555554 [ 320.417398] Call Trace: [ 320.417412] <TASK> [ 320.417429] pci_device_remove+0x42/0xb0 [ 320.417459] device_release_driver_internal+0x1a9/0x210 [ 320.417492] driver_detach+0x4b/0x90 [ 320.417516] bus_remove_driver+0x70/0x100 [ 320.417539] pci_unregister_driver+0x2e/0xb0 [ 320.417564] __do_sys_delete_module.constprop.0+0x190/0x2f0 [ 320.417592] ? kmem_cache_free+0x31e/0x550 [ 320.417619] ? lockdep_hardirqs_on_prepare+0xde/0x190 [ 320.417644] ? do_syscall_64+0x38/0x6b0 [ 320.417665] do_syscall_64+0xc8/0x6b0 [ 320.417683] ? clear_bhb_loop+0x30/0x80 [ 320.417706] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 320.417727] RIP: 0033:0x7f963bb30beb Fixes: 0fe4546 ("idpf: add create vport and netdev configuration") Reviewed-by: Madhu Chittim <madhu.chittim@intel.com> Signed-off-by: Emil Tantilov <emil.s.tantilov@intel.com> Reviewed-by: Aleksandr Loktionov <aleksandr.loktionov@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Samuel Salin <Samuel.salin@intel.com> Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Link: https://patch.msgid.link/20260717185340.3595286-13-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2026-07-17 (ice, idpf) [part] For ice: Vincent Chen fixes issue preventing VF creation when switchdev is not enabled in the configuration. Marcin corrects iteration value for profile association that was truncating profiles. Karol bypasses, unnecessary, waiting on sideband queue PTP writes which can cause failures with phc_ctl program. Sergey adds READ_ONCE() to access of PHC time to prevent torn read on 32-bit systems. Paul adds a check for uninitialized PTP state before attempting to rebuild it and restricts check of TxTime to be for PF VSI only. Alex adds bounds check on PTYPE to prevent possible out-of-bounds write. For idpf: Emil defers setting of adapter max_vports value to prevent inadvertent use if interim allocation errors are encountered. ==================== Link: https://patch.msgid.link/20260717185340.3595286-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sl_realloc_bufs() replaces rbuff and updates buffsize while holding
sl->lock. slip_receive_buf() reads those fields and writes through rbuff
without holding the lock.
An MTU change can therefore race with receive processing. An MTU shrink
can expose the new smaller rbuff with the old larger bound, causing an
out-of-bounds write. A receive callback which already loaded the old
rbuff can instead continue writing after that buffer has been freed.
Serialize receive processing with sl_realloc_bufs() by holding sl->lock
while consuming each receive batch.
Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
Cc: stable@vger.kernel.org
Signed-off-by: Sungmin Kang <726ksm@gmail.com>
Link: https://patch.msgid.link/20260718073631.1674-1-726ksm@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…ents
Since the call to __ip6_del_rt_siblings has been converted under
rcu read lock and it only has one call point
we should no longer block or yield.
Our stack trace from the syzbot reproducer looks as follows:
__ip6_del_rt_siblings
rtnl_notify (Here we pass gfp_any() -> GFP_KERNEL)
nlmsg_notify
nlmsg_multicast
nlmsg_multicast_filtered
netlink_broadcast_filtered (GFP_KERNEL passed from earlier)
netlink_broadcast_filtered can yield if GFP_KERNEL
is passed, which we do not want to happen.
Fix this by changing the allocation flag of rtnl_notify.
Also change the flag passed to nlmsg_new. Even though it
is not related to the syzbot generated bug it still falls
under the same requirements.
Reported-by: syzbot+84d4a405ed798b40c96d@syzkaller.appspotmail.com
Closes: https://syzkaller.appspot.com/bug?extid=84d4a405ed798b40c96d
Fixes: bd11ff4 ("ipv6: Get rid of RTNL for SIOCDELRT and RTM_DELROUTE.")
Signed-off-by: Nikola Z. Ivanov <zlatistiv@gmail.com>
Reviewed-by: Ido Schimmel <idosch@nvidia.com>
Link: https://patch.msgid.link/20260719105759.558050-1-zlatistiv@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
rds_tcp_exit_net() frees the per-netns RDS TCP listen socket via rds_tcp_kill_sock() before unregistering the per-netns sysctl table. Since rds_tcp_skbuf_handler() derives the netns from rtn->rds_tcp_listen_sock->sk, a concurrent sysctl write can race with netns teardown and dereference the freed socket/sk. KASAN reports the race as: BUG: KASAN: slab-use-after-free in rds_tcp_skbuf_handler+0x2aa/0x2e0 rds_tcp_skbuf_handler net/rds/tcp.c:721 proc_sys_call_handler fs/proc/proc_sysctl.c vfs_write fs/read_write.c __x64_sys_pwrite64 fs/read_write.c Fix this by unregistering the RDS TCP sysctl table before calling rds_tcp_kill_sock(). unregister_net_sysctl_table() prevents new sysctl handlers from starting and waits for in-flight handlers to finish, so the listen socket can then be released safely. The fix was tested against the linked reproducer. Fixes: 7f5611c ("rds: sysctl: rds_tcp_{rcv,snd}buf: avoid using current->nsproxy") Reported-by: AutonomousCodeSecurity@microsoft.com Link: https://lore.kernel.org/all/20260719203718.9680-1-blbllhy@gmail.com Reviewed-by: Allison Henderson <achender@kernel.org> Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com> Link: https://patch.msgid.link/20260719210357.10179-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The NETC timer does not support function level reset, so TMR_OFF_L/H registers are not cleared by pcie_flr(). If TMR_OFF was set to a non-zero value in a previous binding, it will persist across driver rebind and cause inaccurate PTP time. There is also a hardware issue: after a warm reset or soft reset, TMR_OFF_L/H registers appear to be cleared to zero, but the timer clock domain internally retains the stale value. When the timer is re-enabled, TMR_CUR_TIME continues to track the old offset until TMR_OFF is written explicitly. This can cause incorrect PTP timestamps and even PTP clock synchronization failures. Per the recommendation from the IP team, explicitly write 0 to TMR_OFF in netc_timer_init() to flush the internally cached value and ensure TMR_CUR_TIME follows the freshly initialized counter. Fixes: 87a201d ("ptp: netc: add NETC V4 Timer PTP driver support") Signed-off-by: Clark Wang <xiaoning.wang@nxp.com> Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Reviewed-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260720012508.23227-1-wei.fang@oss.nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mctp_device_init() handles errors from rtnl_af_register() and rtnl_register_many(), but ignores the return value of register_netdevice_notifier(). If notifier registration fails, init can still return success while the module is only partially initialized. Check the notifier registration error and fail module init early. Fixes: 583be98 ("mctp: Add device handling and netlink interface") Signed-off-by: Minhong He <heminhong@kylinos.cn> Link: https://patch.msgid.link/20260720072518.112614-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Derive the hardware QoS channel from opt->parent instead of opt->handle in airoha_tc_setup_qdisc_ets(). The ETS qdisc handle is either user-specified or auto-allocated by qdisc_alloc_handle() and bears no relation to the HTB leaf classid that identifies the hardware channel. HTB derives the channel from TC_H_MIN(opt->classid), and ETS is always attached as a child of an HTB leaf, so its opt->parent matches that classid. Using opt->handle instead can cause two ETS qdiscs on different HTB leaves to collide on the same hardware channel, corrupting scheduler configuration and stats. Fixes: 20bf7d0 ("net: airoha: Add sched ETS offload support") Reviewed-by: Simon Horman <horms@kernel.org> Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org> Link: https://patch.msgid.link/20260720-airoha-ets-handle-fix-v2-1-6f7129ddc06f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…next Antonio Quartulli says: ==================== Included fixes: * ensure keepalive timestamps are computed using monotonic source * avoid UAF in unlock_ovpn() when iterating over release_list * fix memleak in selftest tool * ensure reference to peer is acquired before scheduling worker (which may drop the not-yet-taken ref) * fix refcount leak in case of concurrent TX and RX TCP error * fix potential refcount unbalance in case of sock release in P2P mode * tag 'ovpn-net-20260720' of https://github.com/OpenVPN/ovpn-net-next: ovpn: use monotonic clock for peer keepalive timeouts ovpn: fix use after free in unlock_ovpn() selftests/net: ovpn: fix getaddrinfo memory leak in ovpn_parse_remote() ovpn: hold peer before scheduling keepalive work ovpn: fix peer refcount leak in TCP error paths ovpn: avoid putting unrelated P2P peer on socket release ==================== Link: https://patch.msgid.link/20260720144131.3657121-1-antonio@openvpn.net Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In tipc_recvmsg(), the copy length is computed as: copy = min_t(int, dlen - offset, buflen); buflen is size_t but min_t(int, ...) casts it to int. When buflen exceeds INT_MAX (e.g. 0xFFFFFFFF via io_uring provided buffers), it wraps negative, wins the comparison, and the negative copy length propagates to simple_copy_to_iter() where int-to-size_t promotion makes it SIZE_MAX, triggering a WARN_ON. tipc_recvstream() has the same pattern. Kernel panic - not syncing: kernel: panic_on_warn set ... RIP: 0010:simple_copy_to_iter+0x9e/0xd0 (net/core/datagram.c:521) Call Trace: __skb_datagram_iter+0x123/0x8b0 (net/core/datagram.c:402) skb_copy_datagram_iter+0x77/0x1a0 (net/core/datagram.c:534) tipc_recvmsg+0x3d7/0xe80 (net/tipc/socket.c:1934) io_recvmsg+0x47e/0xda0 Fix by changing min_t(int, ...) to min_t(size_t, ...) in both functions. The result is always <= (dlen - offset), which is bounded by TIPC maximum message size (0x1ffff bytes), so the implicit narrowing on assignment to int copy is always safe. Fixes: e9f8b10 ("tipc: refactor function tipc_sk_recvmsg()") Fixes: ec8a09f ("tipc: refactor function tipc_sk_recv_stream()") Reported-by: AutonomousCodeSecurity@microsoft.com Signed-off-by: Cen Zhang (Microsoft) <blbllhy@gmail.com> Reviewed-by: Tung Nguyen <tung.quang.nguyen@est.tech> Link: https://patch.msgid.link/20260720214103.47732-1-blbllhy@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Firmware requires more than 16 bits to address TX ring IDs for its internal QP management. Widen the associated HSI ring ID fields to 32 bits. The values firmware assigns remain within 24 bits, bounded by the hardware doorbell XID field. The fw_ring_id field belongs to bnge_ring_struct, a common struct shared by all ring types, so widening it to u32 applies uniformly across TX, RX, CP, and NQ rings but firmware assigns values within 16-bit range for all ring types except TX, which requires the wider field. Note that, Thor Ultra hardware has not yet been deployed and no firmware has been released to field, so backward compatibility is not a concern. Fixes: 42d1c54 ("bnge/bng_re: Add a new HSI") Signed-off-by: Vikas Gupta <vikas.gupta@broadcom.com> Reviewed-by: Siva Reddy Kallam <siva.kallam@broadcom.com> Reviewed-by: Dharmender Garg <dharmender.garg@broadcom.com> Reviewed-by: Yendapally Reddy Dhananjaya Reddy <yendapally.reddy@broadcom.com> Link: https://patch.msgid.link/20260721063731.2622500-1-vikas.gupta@broadcom.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
pep_get_sb() doesn't consider that pskb_may_pull() might have relocated the skb data, and continue to access the older pointer, causing UAF. Reproduced under KASAN: BUG: KASAN: slab-use-after-free in pep_get_sb+0x234/0x3b0 Read of size 1 at addr ff11000105510f50 by task repro/157 pep_get_sb+0x234/0x3b0 pipe_handler_do_rcv+0x5f7/0xa10 pep_do_rcv+0x203/0x410 __sk_receive_skb+0x471/0x4a0 phonet_rcv+0x5b3/0x6c0 __netif_receive_skb+0xcc/0x1d0 Refetch the header with skb_header_pointer() after pskb_may_pull(), so the possibly stale pointer is no longer dereferenced. There are better ways to solve this, but, this is the less instrusive one. Fixes: 9641458 ("Phonet: Pipe End Point for Phonet Pipes protocol") Cc: stable@vger.kernel.org Signed-off-by: Breno Leitao <leitao@debian.org> Link: https://patch.msgid.link/20260721-phonet_get_sb_uaf-v1-1-95fd7881cc4e@debian.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…it() phonet_device_init() registers a netdevice notifier before calling phonet_netlink_register(), but does not check whether notifier registration succeeded. On failure, netlink setup still proceeds and init may return success without the notifier in place. Also, the existing phonet_netlink_register() failure path called phonet_device_exit(), which runs rtnl_unregister_all() even though rtnl_register_many() already unwound any partial registration. Calling the full exit helper on a partial init is not correct. Check each registration error, including proc_create_net(), and unwind only the steps that have succeeded so far, in reverse order. Signed-off-by: Minhong He <heminhong@kylinos.cn> Link: https://patch.msgid.link/20260721093956.162617-1-heminhong@kylinos.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
sctp_process_asconf() caches the transport the ASCONF chunk is processed
against in asconf->transport (== chunk->transport, set once in sctp_rcv()).
For an ASCONF located through its Address Parameter by
__sctp_rcv_asconf_lookup(), that cached transport corresponds to the
Address Parameter, which need not be the packet's source address.
sctp_process_asconf_param() rejects a DEL-IP for the packet source address
(ADDIP D8, SCTP_ERROR_DEL_SRC_IP), but nothing protects asconf->transport.
A single ASCONF can therefore carry, in order:
[Address Parameter L] [DEL-IP L] [DEL-IP 0.0.0.0]
where L differs from the source. The DEL-IP for L passes the D8 check and
calls sctp_assoc_rm_peer() on the transport that asconf->transport still
points at, freeing it (RCU-deferred). The following wildcard DEL-IP then
reuses the now-dangling asconf->transport in sctp_assoc_set_primary() and
sctp_assoc_del_nonprimary_peers(): set_primary() dereferences the freed
transport (->ipaddr, ->state) and plants the dangling pointer into
asoc->peer.primary_path / active_path, and del_nonprimary_peers(), keeping
only the pointer that is no longer on the list, removes every real
transport, leaving the association with a transport_count of 0 and
primary_path/active_path pointing at freed memory.
Reject a DEL-IP that targets the transport the ASCONF is being processed
against, mirroring the existing source-address guard, so the wildcard
branch can never reuse a freed transport.
Fixes: 42e30bf ("[SCTP]: Handle the wildcard ADD-IP Address parameter")
Cc: stable@kernel.org
Signed-off-by: Jun Yang <junvyyang@tencent.com>
Acked-by: Xin Long <lucien.xin@gmail.com>
Link: https://patch.msgid.link/tencent_73762ED1DF08CC9D5F5F61954B01350CFE0A@qq.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mac802154_scan_worker() captures the scanning sub-interface under RCU and then keeps dereferencing sdata->dev after rcu_read_unlock() and outside the rtnl -- in the failure traces, in mac802154_transmit_beacon_req() (skb->dev = sdata->dev), and in the end_scan cleanup. Nothing keeps that netdev alive across the worker iteration. A concurrent DEL_INTERFACE or PHY removal can unregister the interface once the worker drops the rtnl between its two drv_set_channel() sections. unregister_netdevice() frees the netdev asynchronously from netdev_run_todo() with the rtnl already dropped, so neither holding the rtnl nor the per-PHY IEEE802154_IS_SCANNING flag prevents a stale worker iteration from dereferencing the freed netdev -- a KASAN slab-use-after-free, reachable by racing TRIGGER_SCAN against DEL_INTERFACE (both CAP_NET_ADMIN). Pin the netdev with netdev_hold() while the RCU read lock is still held, and release it at every worker exit. Fixes: 57588c7 ("mac802154: Handle passive scanning") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Hashimov <security@auditcode.ai> Link: https://patch.msgid.link/20260721211228.34578-1-security@auditcode.ai Signed-off-by: Jakub Kicinski <kuba@kernel.org>
mptcp_pm_allow_new_subflow() increments extra_subflows before __mptcp_finish_join() on the passive MP_JOIN path. In case of race conditions, the subflow is dropped without calling mptcp_close_ssk(), so the counter is not rolled back. Call mptcp_pm_close_subflow() when the join completion fails to decrement the subflows counter. Fixes: 10f6d46 ("mptcp: fix race between MP_JOIN and close") Cc: stable@vger.kernel.org Signed-off-by: Chenguang Zhao <zhaochenguang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-1-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In mptcp_pm_userspace_get_local_id(), the address entry is looked up under spinlock, but its id is read after dropping the lock. A concurrent deletion can free the entry between the unlock and the read, leading to UAF. The race window is narrow. It was reproduced only with a locally constructed stress test that repeatedly overlaps an MP_JOIN SYN with a MPTCP_PM_CMD_SUBFLOW_DESTROY request. However, the KASAN report below confirms that the race is reachable: [ 666.319376] BUG: KASAN: slab-use-after-free in mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319386] Read of size 1 at addr ffff888124845610 by task swapper/0/0 ... [ 666.319401] Call Trace: [ 666.319405] <IRQ> [ 666.319408] dump_stack_lvl+0x53/0x70 [ 666.319412] print_address_description.constprop.0+0x2c/0x3b0 [ 666.319418] print_report+0xbe/0x2b0 [ 666.319421] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319423] kasan_report+0xce/0x100 [ 666.319426] ? mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319429] mptcp_userspace_pm_get_local_id+0x1dc/0x1f0 [ 666.319433] mptcp_pm_get_local_id+0x371/0x440 ... [ 666.319821] Allocated by task 45539: [ 666.319844] kasan_save_stack+0x33/0x60 [ 666.319855] kasan_save_track+0x14/0x30 [ 666.319858] __kasan_kmalloc+0x8f/0xa0 [ 666.319863] __kmalloc_noprof+0x1e7/0x520 [ 666.319867] sock_kmalloc+0xdf/0x130 [ 666.319885] sock_kmemdup+0x1b/0x40 [ 666.319888] mptcp_userspace_pm_append_new_local_addr+0x261/0x500 [ 666.319910] mptcp_pm_nl_announce_doit+0x16a/0x610 ... [ 666.319967] Freed by task 45560: [ 666.319988] kasan_save_stack+0x33/0x60 [ 666.319991] kasan_save_track+0x14/0x30 [ 666.319994] kasan_save_free_info+0x3b/0x60 [ 666.319998] __kasan_slab_free+0x43/0x70 [ 666.320000] kfree+0x166/0x440 [ 666.320003] sock_kfree_s+0x1d/0x50 [ 666.320007] mptcp_userspace_pm_delete_local_addr.isra.0+0x157/0x200 [ 666.320011] mptcp_pm_nl_subflow_destroy_doit+0x51d/0xea0 Fix by copying the id into a local variable while still holding the lock, and use -1 as a "not found" sentinel. Fixes: f012d79 ("mptcp: check addrs list in userspace_pm_get_local_id") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Tested-by: Xuanqiang Luo <luoxuanqiang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-2-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The backlog list is updated by mptcp_data_ready() under mptcp_data_lock(). The cleanup of backlog references to a closing subflow, however, was performed in mptcp_close_ssk(), before __mptcp_close_ssk() acquires the ssk lock, and while holding neither the ssk lock nor mptcp_data_lock(). Because that traversal ran without mptcp_data_lock(), concurrent softirq RX processing on another CPU (subflow_data_ready() -> mptcp_data_ready() -> __mptcp_add_backlog(), under mptcp_data_lock()) could add a backlog entry referencing the ssk while the cleanup loop was in progress. Such an entry could be missed by the cleanup, or the concurrent list update could corrupt the traversal, leaving skb->sk pointing at the ssk after it is freed. A later mptcp_backlog_purge() then dereferences the stale pointer, triggering a warning in inet_sock_destruct() (ssk->sk_rmem_alloc != 0) followed by a use-after-free in mptcp_backlog_purge(). Fix this by moving the backlog cleanup into __mptcp_close_ssk(), after subflow->closing is set to 1 and while the ssk lock is still held, serialized under mptcp_data_lock(). The cleanup runs only on the push path (MPTCP_CF_PUSH), where backlog references accumulate; on other teardown paths the caller already handles cleanup. With subflow->closing set and mptcp_data_lock() held across the purge, any concurrent mptcp_data_ready() either completes its enqueue before the purge runs and is caught, or observes closing=1 and bails out. Once mptcp_data_unlock() is reached, no new skb referencing the ssk can be enqueued, so the cleanup is exhaustive. Remove the unprotected traversal from mptcp_close_ssk() entirely. Fixes: ee458a3 ("mptcp: introduce mptcp-level backlog") Cc: stable@vger.kernel.org Suggested-by: Paolo Abeni <pabeni@redhat.com> Reported-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Closes: multipath-tcp/mptcp_net-next#621 Signed-off-by: Kalpan Jani <kalpan.jani@mpiricsoftware.com> Acked-by: Paolo Abeni <pabeni@redhat.com> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-3-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In make_connection(), the variable "port" is used but never defined. This leads to an empty argument being passed to wait_local_port_listen(), causing "printf: : invalid number" errors: # INFO: Init # 01 Created network namespaces ns1, ns2 [ OK ] # INFO: Make connections # ./../lib.sh: line 651: printf: : invalid number # 02 Established IPv4 MPTCP Connection ns2 => ns1 [ OK ] # INFO: Connection info: 10.0.1.2:59516 -> 10.0.1.1:50002 # ./../lib.sh: line 651: printf: : invalid number # 03 Established IPv6 MPTCP Connection ns2 => ns1 [ OK ] Fix it by using the correctly defined variable "app_port", which holds the appropriate port number for the connection. Fixes: 39348f5 ("selftests: mptcp: wait for port instead of sleep") Cc: stable@vger.kernel.org Signed-off-by: Geliang Tang <tanggeliang@kylinos.cn> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-4-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The 0-day bot managed to find kernel configs that cause build failures, e.g. when using the StrongARM SA1100 target (ARMv4). On such legacy ARM architecture, all structures are apparently aligned to 32 bits, causing build issue here. Indeed, on such architecture, 'flags' size is not equivalent to sizeof(u16) as expected, but to sizeof(u32). Instead, use memset(). It was not used before to ensure a simple clear operation was used by the compiler. But at the end, it shouldn't matter, and the compiler should optimise this to the same operation with or without memset() when -O above 0 is used. So let's switch to memset() to fix this issue, and reduce this complexity. Fixes: 5e93954 ("mptcp: fix uninit-value in mptcp_established_options") Cc: stable@vger.kernel.org Suggested-by: Frank Ranner <frank.ranner@intel.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202605312026.Srgsz7Tp-lkp@intel.com/ Closes: https://lore.kernel.org/oe-kbuild-all/202607031100.upQfRZTM-lkp@intel.com/ Reviewed-by: Mat Martineau <martineau@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-5-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Matthieu Baerts says: ==================== mptcp: misc fixes for v7.2-rc5 Here are various unrelated fixes: - Patch 1: decrement extra subflows counter in case of errors with passive MP_JOIN. A fix for v5.7. - Patch 2: fix use-after-free in userspace_pm_get_local_id. A fix for v5.19. - Patch 3: fix stale skb->sk reference on subflow close, in case of concurrent read operation. A fix for v6.19. - Patch 4: wait on the correct port in the userspace_pm.sh selftest. A fix for v6.19. - Patch 5: fix a BUILD_BUG_ON on legacy ARM config. A fix for v7.1. ==================== Link: https://patch.msgid.link/20260722-net-mptcp-misc-fixes-7-2-rc5-v1-0-6fb595bc86ef@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() open code the NET_DM_ATTR_PAYLOAD attribute to avoid zeroing the packet payload before overwriting it with skb_copy_bits(). skb_put() reserves nla_total_size(payload_len), i.e. the header plus the NLA_ALIGN() padding, but only payload_len bytes are copied in. When payload_len is not a multiple of 4 the 1-3 padding bytes are never initialized and are leaked to user space inside the netlink message. KMSAN confirms the leak for the software path when the packet payload length is not 4-byte aligned: BUG: KMSAN: kernel-infoleak in _copy_to_iter _copy_to_iter __skb_datagram_iter skb_copy_datagram_iter netlink_recvmsg sock_recvmsg __sys_recvfrom Uninit was created at: kmem_cache_alloc_node_noprof __alloc_skb net_dm_packet_work Bytes 173-175 of 176 are uninitialized Use __nla_reserve(), which sets up the attribute header and zeroes the padding, instead of open coding the attribute construction. Fixes: ca30707 ("drop_monitor: Add packet alert mode") Fixes: 5e58109 ("drop_monitor: Add support for packet alert mode for hardware drops") Suggested-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr> Link: https://patch.msgid.link/20260722122817.5548-1-yhlee@isslab.korea.ac.kr Signed-off-by: Jakub Kicinski <kuba@kernel.org>
net_dm_packet_report_fill() and net_dm_hw_packet_report_fill() use nla_put_u64_64bit() to append 64-bit attributes (NET_DM_ATTR_PC and NET_DM_ATTR_TIMESTAMP). On 32-bit architectures without CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS, nla_put_u64_64bit() may append a 4-byte NET_DM_ATTR_PAD attribute for 64-bit alignment. However, net_dm_packet_report_size() and net_dm_hw_packet_report_size() used nla_total_size(sizeof(u64)) instead of nla_total_size_64bit(sizeof(u64)), budgeting 12 bytes instead of up to 16 bytes. This under-estimation of SKB size can lead to an skb_over_panic() when __nla_reserve() or skb_put() is subsequently called. Fix this by using nla_total_size_64bit(sizeof(u64)) in both size calculations. Fixes: ca30707 ("drop_monitor: Add packet alert mode") Fixes: 5e58109 ("drop_monitor: Add support for packet alert mode for hardware drops") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260722141743.3266924-2-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In net_dm_packet_trace_kfree_skb_hit() and net_dm_hw_trap_packet_probe(), u64_stats_update_begin() / u64_stats_inc() / u64_stats_update_end() were called after spin_unlock_irqrestore(&...drop_queue.lock, flags), when local IRQs had already been re-enabled. Tracepoint probes can execute in IRQ or softirq context. On 32-bit architectures, u64_stats_update_begin() disables preemption but not interrupts, relying on seqcount writes. If a nested interrupt occurs on the same CPU during the 64-bit stats update, the reentrant seqcount update can corrupt the seqcount state or stats value. Fix this by performing the 64-bit per-CPU stats update before releasing drop_queue.lock via spin_unlock_irqrestore(), ensuring local interrupts remain disabled during the u64_stats update. Fixes: e9feb58 ("drop_monitor: Expose tail drop counter") Fixes: 5e58109 ("drop_monitor: Add support for packet alert mode for hardware drops") Signed-off-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20260722141743.3266924-3-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Eric Dumazet says: ==================== drop_monitor: take care of 32bit kernels This series fixes two drop_monitor issues on 32-bit architectures: - Patch 1 uses nla_total_size_64bit() for PC and TIMESTAMP attributes to account for alignment padding added by nla_put_u64_64bit(), avoiding potential skb_over_panic() crashes. - Patch 2 moves u64_stats updates before spin_unlock_irqrestore(), ensuring local interrupts are disabled to prevent seqcount corruption from nested interrupts in probe context. ==================== Link: https://patch.msgid.link/20260722141743.3266924-1-edumazet@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…git/netdev/net
Pull networking fixes from Jakub Kicinski:
"Lots of fixes, double the count even for the 'new normal'. Largely due
to my time off followed by a networking conference which distracted
most maintainers (less so the AI generators).
Including fixes from Bluetooth and WiFi.
Current release - regressions:
- wifi: mt76: fix MAC address for non OF pcie cards
Current release - new code bugs:
- mptcp: fix BUILD_BUG_ON on legacy ARM config
- wifi: cfg80211: guard optional PMSR nominal time
Previous releases - regressions:
- qrtr: ns: raise node count limit to 512, we arbitrarily picked
256 as a limit, turns out it was too low for real world deployments
- vhost-net: fix TX stall when vhost owns virtio-net header
- eth: amd-xgbe: fix MAC_AUTO_SW handling in CL37 AN
- wifi: ath12k: fix low MLO RX throughput on WCN7850
Previous releases - always broken:
- number of random AI fixes for SCTP, RDS and TIPC protocols
- more AI-looking fixes for WiFi drivers
- number of fixes for missing pointer reloading after skb pull
- reject BPF redirect use from qdisc qevent block
- tcp: initialize standalone TCP-AO response padding
- vsock/virtio: collapse receive queue under memory pressure to avoid
client OOMing the host with tiny messages
- ipv4: icmp: fill flow parameters in icmp_route_lookup decoy lookup,
make sure the ICMP response routing follows the routing policy
- gro: fix double aggregation of flush-marked skbs
- ovpn: fix various refcount bugs
- tls: device: push pending open record on splice EOF
- eth: mlx5:
- use sender devcom for MPV master-up
- fix MCIA register buffer overflow on 32 dword reads"
* tag 'net-7.2-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net: (234 commits)
drop_monitor: perform u64_stats updates under IRQ-disabled section
drop_monitor: fix size calculations for 64-bit attributes
net: drop_monitor: fix info leak in NET_DM_ATTR_PAYLOAD
mptcp: fix BUILD_BUG_ON on legacy ARM config
selftests: mptcp: userspace_pm: fix undefined variable port
mptcp: fix stale skb->sk reference on subflow close
mptcp: pm: userspace: fix use-after-free in get_local_id
mptcp: decrement subflows counter on failed passive join
mac802154: hold an interface reference across the scan worker
sctp: don't free the ASCONF's own transport in DEL-IP processing
phonet: check register_netdevice_notifier() error in phonet_device_init()
phonet: pep: fix use-after-free in pep_get_sb()
bnge/bng_re: fix ring ID widths
tipc: fix integer overflow in tipc_recvmsg() and tipc_recvstream()
net: airoha: fix ETS channel derivation in airoha_tc_setup_qdisc_ets()
mctp: check register_netdevice_notifier() error in mctp_device_init()
ptp: netc: explicitly clear TMR_OFF during initialization
rds: tcp: unregister sysctl before tearing down listen socket
ipv6: Change allocation flags to match rcu_read_lock section requirements
net: slip: serialize receive against buffer reallocation
...
…/cifs-2.6 Pull smb client fixes from Steve French: - Fix leak in cifs_close_deferred_file() - Fix resolving MacOS symlinks - Fix stale file size in readdir - Update git branches in MAINTAINERS file - Fix bounds check in cifs_filldir - Fix checks in parse_dfs_referrals() - Fix DFS referral checks for malformed packet * tag 'v7.2-rc4-smb3-client-fixes' of git://git.samba.org/sfrench/cifs-2.6: cifs: fix cifsFileInfo leak on kmalloc failure in deferred close drain paths cifs: prevent readdir from changing file size due to stale directory metadata smb: client: handle STATUS_STOPPED_ON_SYMLINK responses without a symlink target Add missing git branch info for cifs and ksmbd to MAINTAINERS file smb: client: bound dirent name against end of SMB response in cifs_filldir smb: client: validate DFS referral PathConsumed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.