summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2026-08-24workqueue: Fix unbound pool lifetime for pending pwqsYao Kai
KASAN reports a use-after-free of an unbound worker_pool in node_activate_pending_pwq(): BUG: KASAN: slab-use-after-free in _raw_spin_trylock+0x6d/0x120 Read of size 4 at addr ffff8880089ce000 by task kworker/u22:0/318 CPU: 1 UID: 0 PID: 318 Comm: kworker/u22:0 Not tainted 7.2.0 #1 PREEMPT(lazy) Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 Workqueue: 0x0 (flush-8:0) Call Trace: <TASK> dump_stack_lvl+0x53/0x70 print_report+0xce/0x610 kasan_report+0xce/0x100 _raw_spin_trylock+0x6d/0x120 pwq_dec_nr_in_flight+0x4b4/0xcb0 process_one_work+0x921/0x11a0 worker_thread+0x4d0/0xd20 kthread+0x2de/0x3c0 ret_from_fork+0x3aa/0x620 ret_from_fork_asm+0x1a/0x30 </TASK> Allocated by task 311: alloc_pwq+0x439/0xca0 apply_wqattrs_prepare+0x75e/0xd10 apply_workqueue_attrs_locked+0x44/0xa0 wq_nice_store+0x350/0x450 Freed by task 0: kfree+0x127/0x3b0 rcu_core+0x523/0x1780 handle_softirqs+0x1b3/0x610 Last potentially related work creation: put_unbound_pool+0x3f3/0x7d0 pwq_release_workfn+0x494/0x8e0 kthread_worker_fn+0x1ff/0x790 Canceling the last inactive work skips pwq_dec_nr_active(), so an empty pwq can remain on pending_pwqs when its refcnt reaches zero. pwq_release_workfn() currently puts the pool before removing that pwq. If this drops the last pool reference, the pool can be RCU-freed while the pwq remains reachable, and node_activate_pending_pwq() may trylock the freed pool->lock. Remove the pwq from pending_pwqs before putting the pool. Fixes: 5797b1c18919 ("workqueue: Implement system-wide nr_active enforcement for unbound workqueues") Cc: stable@vger.kernel.org Signed-off-by: Yao Kai <yaokai34@huawei.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-24Merge tag 'platform-drivers-x86-v7.3-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86 Pull x86 platform driver updates from Ilpo Järvinen "Highlights: Major refactoring effort: stop setting acpi_device_name/class() and pnp.device_class to facilitate their eventual removal Many rollback/remove path fixes (presumably mostly found by AI) Miscellaneous cleanups / refactoring / improvements amd/halo: - Add Halo RGB LED driver amd/hsmp: - Properly serialize probe, remove, and data paths - Add support for protocol v7 used by Family 1AH Model 80H - Fix error checking corner cases (largely from AI review) - Reject negative power cap amd/pmc: - Improve behavior on platforms that do not support STB - Add T14 Gen2 AMD (20XL) to s2idle quirk list amd/pmf: - Add ioctl interface to retrieve device metrics - Add support for new metrics tables used by Family 1AH Model 80H qcom-hamoa-ec (arm64): - Reject short responses asus-nb-wmi: - Support ProArt key on ASUS ProArt PX13 asus-armoury: - Gate PPT writes behind active fan curve - Add power limits for more models dell-wmi-base: - Fix handling of ultra performance key dell-wmi-sysman: - Don't hex dump attribute security buffer hp-bioscfg: - Various fixes - Improve reduced ACPI packages support (necessary for HP EliteBook 840 G2) lg-laptop: - Fix LED resource handling - Add support for events used in newer models - Fix keyboard backlight support on LG Gram 16T90SP hp-wmi: - Generalize thermal params to board params - Manage CPU and GPU PWM independently - Add GPU MUX switch support - Add Victus 15-fb0xxx support - Add OMEN MAX 16-ak0xxx, OMEN 16-n0xxx, OMEN 16-wd0xxx, OMEN 16-wf0xxx, and OMEN board ID 8D88 support - Add OMEN Transcend 16-u0xxx support huawei: - Add support for Fn-lock ACPI interface found on newer Huawei laptops such as MateBook 14 2024 ISST: - Improve input validation (many fixes) - Disallow SST-CP (core-power) feature if perf profile add fails lenovo/yb9-kbdock: - Add driver for Yoga Book 9 14IAH10 lenovo/ymc: - Extend hinge switch query to support Yoga 9 2-in-1 14IPH11 - Prevent loading on Yoga Book 9 14IAH10 to avoid duplicated input nodes msi-ec: - Add MSI Raider A18 HX A9WJG and MSI Katana GF76 11UEK support msi-wmi: - Add MSI Claw M-Center keys support oxpec: - Add support for OneXPlayer X2 Mini Pro redmi-wmi: - Report kbd backlight cycle, OEM preset power mode, and FnLock toggle events to userspace samsung-galaxybook: - Add Samsung Galaxy Book6 Pro support thinkpad_acpi: - Add USB-C Security support uniwill-laptop: - Add keyboard backlight, AC auto boot, and USB powershare support - Add MACHENIKE L16 Pro, AiStone X4SP4NAL, and Avell A60 MUV support - Make lightbar max brightness configurable and add support for LAPQC71A/B" * tag 'platform-drivers-x86-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/pdx86/platform-drivers-x86: (152 commits) platform/x86: think-lmi: Fix current password length check platform/x86: redmi-wmi: report EC state change events MAINTAINERS: update Intel PMC Core maintainer contact platform/x86: oxpec: Add support for OneXPlayer X2 Mini Pro platform/x86: thinkpad_acpi: Fix fan speed reporting on Edge E330 platform/x86: msi-ec: Add MSI Katana GF76 11UEK EC firmware platform/x86: think-lmi: Fix certificate thumbprint sysfs output mlxbf-bootctl: fix the build error with FIELD_PREP() platform/x86: think-lmi: Free system certificate signatures platform/x86: ISST: Add a NULL check for sst_inst[] platform/x86: ISST: Return error during profile addition platform/x86: ISST: Just allow 2 bits for SST feature enable platform/x86: ISST: Use PP level enable mask platform/x86: ISST: Validate parameter for frequency and priority platform/x86: ISST: Validate parameter for core power state platform/x86: ISST: Validate max level for set feature platform/x86: ISST: Validate logical CPU id and clos id platform/x86: ISST: Validate level in perf mask ioctls platform/x86: ISST: Validate socket ID in clos_assoc ioctl platform/x86/amd/hsmp: Reject negative power cap writes in hwmon ...
2026-08-24Bluetooth: RFCOMM: serialize session teardownChengfeng Ye
rfcomm_kill_listener() walks session_list and deletes every session without holding rfcomm_mutex, unlike the normal session processing and connect error paths. Under normal operation, an open RFCOMM socket pins rfcomm.ko, so rfcomm_kill_listener() does not run concurrently with rfcomm_dlc_open(). However, forced module unload via delete_module(O_TRUNC) can stop krfcommd while a failed connect is still unwinding. connect task forced unload / krfcommd ------------ ------------------------ rfcomm_lock() rfcomm_session_add() delete_module("rfcomm", O_TRUNC) rfcomm_kill_listener() fetch session from session_list kernel_connect() fails rfcomm_session_del() remove and free session rfcomm_session_del(session) The final call then reads the freed session and may corrupt the list. KASAN reported with mdelay() to enlarge critical window: BUG: KASAN: slab-use-after-free in rfcomm_run+0x3802/0x3f00 [rfcomm] Read of size 8 at addr ffff888111058d40 by task krfcommd/79 Tainted: [R]=FORCED_RMMOD Allocated by task 86: rfcomm_session_add+0xa1/0x300 [rfcomm] rfcomm_dlc_open+0x8b2/0xf30 [rfcomm] rfcomm_sock_connect+0x34c/0x530 [rfcomm] Freed by task 86: kfree+0x121/0x3c0 rfcomm_dlc_open+0xab7/0xf30 [rfcomm] rfcomm_sock_connect+0x34c/0x530 [rfcomm] Hold rfcomm_mutex across the teardown traversal so every reachable session_list walk uses the same serialization. Reviewed-by: Ali Ahmet Memis <ali@iusegentoo.com> Tested-by: Ali Ahmet Memis <ali@iusegentoo.com> Reviewed-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Chengfeng Ye <nicoyip.dev@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: do not leak an hci_conn when a second LE connect is rejectedRadek Podgorny
create_le_conn_complete() decides whether the failed connection is still pending by comparing it against hci_lookup_le_connect(), which returns the first LE connection in BT_CONNECT. That is the same connection only while at most one is pending. Two can be pending. Connections created on the passive scan path sit in BT_CONNECT with HCI_CONN_SCANNING set and are invisible to hci_lookup_le_connect() until hci_le_create_conn_sync() clears the flag when their command is issued, so the -EBUSY guard in hci_connect_le() does not prevent a second connection from being queued while the first is still on the scan path. Whenever two connections are in BT_CONNECT at once, the lookup may return one connection while create_le_conn_complete() is reporting the failure of the other; the early exit then drops the error and hci_conn_failed() never runs on the connection that failed. The controller also rejects a second HCI_OP_LE_CREATE_CONN issued while another connection creation is still outstanding, per Core Spec Vol 4, Part E. The spec calls for Command Disallowed there; the bcm43438 observed here answers with an LMP/LL error code instead, which bt_to_errno() maps to the -EPROTO (-71) in the log below. The leaked connection stays in BT_CONNECT forever, and because hci_connect_le() refuses to dial while hci_lookup_le_connect() finds anything, every subsequent attempt to reach any peer fails with -EBUSY and no command reaches the controller at all. Seen on a bcm43438 with two BLE peers polled on the same interval (state 5 is BT_CONNECT; both handles are UNSET ones, allocated from the ida above HCI_CONN_HANDLE_MAX): Bluetooth: hci1: Opcode 0x2013 failed: -71 # hcitool con < LE 14:9C:EF:03:68:81 handle 3840 state 5 lm CENTRAL < LE C4:D3:6A:8C:B5:38 handle 3841 state 5 lm CENTRAL A btmon capture across the next ten minutes of connect attempts contains no HCI_OP_LE_CREATE_CONN at all; outgoing LE connections do not recover until the adapter is reset. With this change the same scenario fails the rejected connection cleanly and further connects to both peers go through. Ask about the connection itself instead of about the device. Fixes: c9f73a2178c1 ("Bluetooth: hci_conn: Fix hci_connect_le_sync") Signed-off-by: Radek Podgorny <radek@podgorny.cz> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: RFCOMM: serialize security confirmation handlingChengfeng Ye
rfcomm_security_cfm() looks up a session on session_list and then walks its DLC list without holding rfcomm_mutex. Since RFCOMM session teardown uses rfcomm_mutex, krfcommd can close and free the same session and DLCs concurrently: hci_rx_work krfcommd ----------- --------- rfcomm_session_get() rfcomm_lock() rfcomm_session_close() rfcomm_dlc_unlink() rfcomm_session_del() kfree(s) rfcomm_unlock() walk s->dlcs The callback can then read a freed session list head and touch freed DLCs while updating their flags or timers. Serialize the session lookup and DLC traversal in rfcomm_security_cfm() with rfcomm_mutex. This matches the existing RFCOMM session lifetime rules and prevents concurrent rfcomm_session_del() / rfcomm_dlc_unlink() from tearing the objects down while the callback is using them. KASAN reported: BUG: KASAN: slab-use-after-free in rfcomm_security_cfm+0x41c/0x440 Read of size 8 at addr ffff888111fb3960 by task kworker/u17:1/89 Workqueue: hci0 hci_rx_work Call Trace: rfcomm_security_cfm+0x41c/0x440 hci_encrypt_cfm+0x139/0x590 hci_encrypt_change_evt+0x37b/0xc40 hci_event_packet+0x71b/0xb20 hci_rx_work+0x293/0x730 Allocated by task 69: rfcomm_session_add+0x9e/0x2f0 rfcomm_run+0x44b/0x41e0 Freed by task 69: kfree+0x131/0x3c0 rfcomm_session_del+0x188/0x220 rfcomm_run+0x1985/0x41e0 Fixes: 08c30aca9e698faddebd34f81e1196295f9dc063 ("Bluetooth: Remove RFCOMM session refcnt") 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>
2026-08-24Bluetooth: btusb: limit RTL8761B BROKEN_EXT_SCAN quirk to 0bda:a728Junjie Cao
Commit 5ead2063611a ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan") set HCI_QUIRK_BROKEN_EXT_SCAN for every CHIP_ID_8761B device to cure repeated 0x2042 failures on an 0bda:a728 dongle. The brokenness is per-dongle, not per-chip: on a TP-Link UB500 (2357:0604, RTL8761BU, fw 0xdfc6d922) extended scan works, and the legacy scan path the quirk forces is what is broken -- LE Set Scan Enable (0x200c) times out with -110 about 30 s after firmware load, btusb resets the device, and the adapter re-enumerates in an endless loop (382 firmware reloads in one boot). 7.1.8, which predates the stable backport, runs clean on this unit; 7.1.9 loops. Move the quirk from btrtl's chip-wide switch to a btusb device-table flag on the USB id the original fix was verified against. Other 8761B dongles return to their earlier long-standing behaviour. Link: https://bugzilla.redhat.com/show_bug.cgi?id=2521504 Fixes: 5ead2063611a ("Bluetooth: btrtl: fix RTL8761B/BU broken LE extended scan") Cc: stable@vger.kernel.org Signed-off-by: Junjie Cao <junjie.cao@intel.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: hci_uart: Fix false success return in hci_uart_setup()Gongwei Li
When reading the local version information for vendor detection fails, the error is only printed and 0 is returned, which masks the setup failure from the HCI core. Return PTR_ERR(skb) instead. Fixes: fb2ce8d11f039 ("Bluetooth: hci_uart: Add support for vendor detection flag") Fixes: 82f5169bf3d3b ("Bluetooth: hci_uart: add serdev driver support library") Cc: stable@vger.kernel.org Signed-off-by: Gongwei Li <ligongwei@kylinos.cn> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: RFCOMM: Validate MTU in rfcomm_apply_pn() to prevent infinite loopHyunwoo Kim
rfcomm_apply_pn() accepts the MTU value from a remote PN (Parameter Negotiation) frame without checking for zero. When the remote peer sends an MTU of zero, d->mtu is set to 0. This causes the sendmsg path to enter an infinite loop when fragmenting data, as each fragment has size == min_t(size_t, len, 0) == 0, so the remaining length never decreases. The infinite allocation of zero-length skbs exhausts all system memory. Fix by clamping d->mtu to RFCOMM_DEFAULT_MTU when the negotiated value is zero, consistent with the initial value assigned in rfcomm_dlc_alloc(). Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Signed-off-by: Hyunwoo Kim <imv4bel@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: ISO: fix use-after-free of listener socket in iso_conn_readyHang Nan
iso_conn_ready() looks up the BIS listener socket with iso_get_sock(), which takes a reference, and then, without re-checking its state, creates a child socket from it: parent = iso_get_sock(hdev, ...); if (!parent) return; lock_sock(parent); sk = iso_sock_alloc(sock_net(parent), NULL, BTPROTO_ISO, ...); ... iso_chan_add(conn, sk, parent); ... release_sock(parent); sock_put(parent); If the listener socket is closed concurrently, between iso_get_sock() and lock_sock(), the reference taken by iso_get_sock() may be the last one: the close path drops the link-list reference, and once iso_conn_ready() drops its own reference at the end of the function the socket is freed. The child socket, however, is already linked to the freed parent, and a later disconnect of the child runs iso_chan_del() -> bt_accept_unlink(), which dereferences the dangling parent pointer into the freed accept queue (a use-after-free). The same dangling pointer is also dereferenced through parent->***() in iso_chan_del(). Fix it the same way the connected (non-BIS) path was fixed in commit 0d255e63fcf3 ("Bluetooth: ISO: hold sk properly in iso_conn_ready"): after taking the socket lock, re-check that the parent is still a listening, alive socket, and bail out otherwise. Fixes: ccf74f2390d60 ("Bluetooth: Add BTPROTO_ISO socket type") Cc: stable@vger.kernel.org Signed-off-by: Hang Nan <2122295973@qq.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24docs: panic: Disclaimer about console verbosity when using panic_print with ↵Guilherme G. Piccoli
pstore Users of panic_print / panic_sys_info are usually aware of the potentially huge amount of information displayed with such options - their goal by using them is indeed to dump more information during panic! What might come unnoticed at first is the impact that the console_verbose() call on panic path has, specially in cases that users rely on pstore as a means to collect the panic logs. Recent experience shows that dumping all tasks in an ARM64 system (with qcom_geni tty driver) gets a 2 minute delay on panic time due to writing such information to console. But in that case, pstore was used, so there was no need for console printing, and suppressing that reduced the full time to less than 0.5 second. The option "printk.console_no_auto_verbose" aims exactly at this use case: avoid automatically increasing the loglevel during panic path. So, let's officially document this to avoid users wasting their time either on long panic printing or debugging the panic delays. While at it, improve the readability of the panic_print text, by adding some line breaks. Suggested-by: Petr Mladek <pmladek@suse.com> Reviewed-by: Bradley Morgan <include@grrlz.net> Reviewed-by: Feng Tang <feng.tang@linux.alibaba.com> Signed-off-by: Guilherme G. Piccoli <gpiccoli@igalia.com> Reviewed-by: Petr Mladek <pmladek@suse.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260819183419.2203903-1-gpiccoli@igalia.com>
2026-08-24Bluetooth: hci_core: use skb_get() instead of skb_clone() for req_skbXin Chen
BT enable fails intermittently with -ETIMEDOUT (-110). The kernel log shows the HCI Read Local Version command was sent and the firmware replied with status 0x00 (logged by hci_req_cmd_complete() BT_DBG), but the waiter in __hci_cmd_sync_sk() never woke up and timed out after 10 s: bluetooth hci0: Opcode 0xfc00 // __hci_cmd_sync_sk bluetooth hci0: opcode 0xfc00 plen 1 // hci_cmd_sync_add bluetooth hci0: skb len 4 // hci_cmd_sync_alloc bluetooth hci0: length 1 // hci_req_sync_run Bluetooth: hci0 cmd_cnt 1 cmd queued 1 // hci_cmd_work Bluetooth: hci0 type 1 len 4 // hci_send_frame Bluetooth: opcode 0xfc00 status 0x00 // hci_req_cmd_complete <-- req_skb NULL: req_complete_skb not set, hci_cmd_sync_complete() never called, req_status stays HCI_REQ_PEND --> <-- 10 s later: wait_event_interruptible_timeout expires --> bluetooth hci0: end: err -110 // __hci_cmd_sync_sk The root cause is that hci_send_cmd_sync() clones the sent command into hdev->req_skb so that hci_req_cmd_complete() can locate the registered completion callback. Under memory pressure this skb_clone() fails, leaving hdev->req_skb NULL. The firmware reply is received and processed, but hci_req_cmd_complete() finds NULL req_skb, so hci_cmd_sync_complete() is never called, req_status stays HCI_REQ_PEND, and the waiter times out with -ETIMEDOUT. req_skb is only used to read bt_cb(skb)->hci callbacks and opcode -- it is never modified. Replace skb_clone() with skb_get(), which simply increments the reference count of hdev->sent_cmd without allocating new memory and therefore cannot fail. This issue was first observed as a use-after-free in ttyport_close() when ttyport_open() failed, which was investigated in an earlier patch series [1]. That investigation led to the discovery of the true root cause described above. [1] https://lore.kernel.org/all/20250430111617.1151390-1-quic_cxin@quicinc.com/ Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback") Cc: stable@vger.kernel.org Signed-off-by: Xin Chen <xin.chen2@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: hci_event: clear HCI_LE_ADV only on a created connectionValentin Kindschi
le_conn_complete_evt() clears HCI_LE_ADV before looking at the event status, on the premise stated in its comment that all controllers stop advertising when a connection is created. That premise only holds when a connection was actually created. On a non-zero status none was, and the controller is still advertising: after the host issues LE Create Connection Cancel the event arrives with Unknown Connection Identifier (0x02), and a connection timeout behaves the same way. Clearing the flag there leaves the host believing advertising is off while the controller has it on. It is also wrong for extended advertising, where several sets can be advertising at once. hci_cc_le_set_ext_adv_enable() is careful about this - on disabling one set it walks hdev->adv_instances and only clears HCI_LE_ADV once no instance is still enabled. The unconditional clear here discards that bookkeeping, so one set connecting drops the flag while the others keep advertising. The direction of the error matters. A flag left set is self-correcting: hci_disable_advertising_sync() sends LE Set Advertising Enable(0) and the command complete puts the state back. A flag left clear is not, because that same function returns early without sending anything while the flag is clear: - LE Set Advertising Parameters is then sent to a controller that is still advertising, and is correctly rejected with Command Disallowed (0x0c); - hci_enable_advertising_sync() returns at that point, before the LE Set Advertising Enable that would set HCI_LE_ADV again. On a controller without LE Extended Advertising that is reachable from here: hci_schedule_adv_instance_sync() re-arms adv_instance_expire every HCI_DEFAULT_ADV_DURATION (2 s) and its "already advertising" shortcut tests HCI_LE_ADV, which can no longer become true, so the parameter write is retried for as long as advertising is configured: Bluetooth: hci0: Opcode 0x2006 failed: -16 Only clear the flag when a connection was established. Note this is not on its own sufficient to stop that retry loop - the redundant enable queued by hci_le_conn_failed() clears HCI_LE_ADV itself and recreates the same mismatch, which patch 1 addresses. This patch fixes the event handler reporting a state the controller is not in. Verified on the affected device (BCM43455, legacy advertising only) with this patch and patch 1 applied. A 221 s btmon capture with an out-of-range peer at -90 dBm contains two outgoing connection attempts that the host cancelled, each producing exactly the event this patch changes: < LE Set Advertising Parameters 0x2006 Success < LE Set Advertising Enable 0x200a Success < LE Create Connection Cancel 0x200e Success > LE Connection Complete Unknown Connection Identifier (0x02), central Nothing follows either one; the next command is an unrelated scan restart 70 ms later. Over the whole capture: 7 LE Set Advertising Parameters sent, all Success; 10 LE Set Advertising Enable, all Success; no Command Disallowed of any opcode, and no 2 s cadence anywhere. Two central connections to other peers completed normally afterwards, with feature exchange and a connection parameter update, so advertising was still live across the cancelled attempts. The extended advertising case above is a code argument, not a measurement: this controller has no LE Extended Advertising, so that path is not exercised by the capture. Fixes: fbd96c151cdc ("Bluetooth: Fix clearing HCI_LE_ADV for LE connections") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 btmon Signed-off-by: Valentin Kindschi <valentin.kindschi@fiveco.ch> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: hci_conn: re-enable advertising only for peripheral roleValentin Kindschi
hci_le_conn_failed() unconditionally calls hci_enable_advertising(), although its own comment states advertising should be re-enabled only when the failed attempt was made as a peripheral. hci_le_conn_failed() is reached from hci_conn_failed() for every failed LE connection, including outgoing central connections. For a central attempt this enable is redundant: hci_le_create_conn_sync() already restores advertising via hci_resume_advertising_sync() in its done: block. Because hci_enable_advertising() only queues the work on cmd_sync_work, it runs *after* that resume has already succeeded and set HCI_LE_ADV. The resulting HCI sequence, captured on a BCM43455 (no LE Extended Advertising, so legacy advertising is used): LE Create Connection Status Success ... 13.8 s, peer never answers ... LE Set Advertising Parameters (0x2006) Success <- done: resume, LE Set Advertising Enable (0x200a) Success HCI_LE_ADV set LE Create Connection Cancel (0x200e) Success LE Connection Complete Unknown Conn Id LE Set Advertising Parameters (0x2006) Command Disallowed (0x0c) The last command is the queued enable from hci_le_conn_failed() running as a second hci_enable_advertising_sync() pass. It clears HCI_LE_ADV (hci_sync.c, "Clear the HCI_LE_ADV bit temporarily"), then sends LE Set Advertising Parameters while the controller is still advertising, which the controller correctly rejects with Command Disallowed. The disable-first call at the top of hci_enable_advertising_sync() cannot prevent this: hci_disable_advertising_sync() returns early without sending anything when HCI_LE_ADV is clear, so it is a no-op exactly when the flag is wrong. hci_enable_advertising_sync() then returns without sending LE Set Advertising Enable, so HCI_LE_ADV is never set again. The legacy software rotation loop re-arms hci_schedule_adv_instance_sync() every HCI_DEFAULT_ADV_DURATION (2 s), and its "already advertising" shortcut tests HCI_LE_ADV, which can no longer become true. The command is therefore retried every 2 s indefinitely: Bluetooth: hci0: Opcode 0x2006 failed: -16 Observed on a gateway as 5326 occurrences over 3 hours, ending only when bluetoothd was restarted. Connection attempts that succeed do not call hci_le_conn_failed() and never trigger this. Add the role test the comment already describes. Both other hci_enable_advertising() call sites reached from a failed/closed LE connection (hci_cs_disconnect() and hci_disconn_complete_evt()) already guard on conn->role == HCI_ROLE_SLAVE; this one was missed. Reproducing needs legacy advertising (ext_adv_capable() false, so the software rotation loop is used), simultaneous peripheral advertising and outgoing central connects, and a central connect that times out rather than failing fast. The Fixes tag points at the commit that introduced the advertising restart into this path for the directed-advertising (peripheral) case; the role test that the later commit 0b1db38ca26b ("Bluetooth: Fix check for direct advertising") added to the sibling paths was never applied here. Fixes: 3c857757ef6e ("Bluetooth: Add directed advertising support through connect()") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 btmon Signed-off-by: Valentin Kindschi <valentin.kindschi@fiveco.ch> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: hci_bcm4377: Ignore reserved PHY in ext adv reports on BCM4378Lorenzo Stoakes (ARM)
Commit ed2a2ef16a6b ("Bluetooth: Add quirk to ignore reserved PHY bits in LE Extended Adv Report") added a quirk to handle creative use of the reserved bits in the PHY fields for 4388 controllers in Apple silicon. I observed the same issue with the BCM4378 Bluetooth controller (14e4:5f69, rev 05) on an Apple MacBook Pro (13-inch, M2, 2022): > HCI Event: LE Meta Event (0x3e) plen 51 LE Extended Advertising Report (0x0d) Num reports: 1 Entry 0 Event type: 0x2513 Props: 0x0013 Connectable Scannable Use legacy advertising PDUs Data status: Complete Reserved (0x2500) Legacy PDU Type: Reserved (0x2513) Address type: Random (0x01) Address: EA:C1:82:F0:24:C6 (Static) Primary PHY: Reserved Secondary PHY: No packets SID: no ADI field (0xff) TX power: 127 dBm RSSI: -57 dBm (0xc7) Periodic advertising interval: 0.00 msec (0x0000) Direct address type: Public (0x00) Direct address: 00:00:00:00:00:00 (OUI 00-00-00) Data length: 25 This results in the firmware rejecting connection attempts with "Unsupported Feature or Parameter Value" (0x11). Fix the issue by using the same quirk for BCM4378 devices too. I tested this locally and confirmed that the issue is resolved. This was observed when attempting to connect a Kinesis Advantage 360 keyboard to the MacBook. Assisted-by: Claude:claude-fable-5 Fixes: 2e7ed5f5e69b ("Bluetooth: hci_sync: Use advertised PHYs on hci_le_ext_create_conn_sync") Cc: stable@vger.kernel.org Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org> Reviewed-by: Sven Peter <sven@kernel.org> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: eir: Fix OOB read in eir_get_service_data()HyeongJun An
eir_get_service_data() walks the advertising data for a Service Data field with a matching UUID. On a mismatch it advances: eir += dlen; eir_len -= dlen; eir_get_data() reports dlen as the field's data length, but the field spans dlen + 2 bytes once its length and type bytes count, and more when non-Service-Data fields were skipped to reach it. The pointer lands correctly on the next field. eir_len does not, and the shortfall compounds across fields until eir_get_data() reads the length and type bytes of a "field" past the end of the buffer. For an ISO broadcast sink that buffer is hcon->le_per_adv_data[], filled from the periodic advertising reports of a remote broadcaster. A PA payload packed with mismatching Service Data fields walks off the array into the rest of struct hci_conn. A drifted field that matches the BAA UUID puts those bytes in iso_pi(sk)->base, where user space reads them back with getsockopt(BT_ISO_BASE). Recompute eir_len from the end of the buffer each iteration. Fixes: 8f9ae5b3ae80 ("Bluetooth: eir: Add helpers for managing service data") Cc: stable@vger.kernel.org Assisted-by: Claude:claude-opus-5 Signed-off-by: HyeongJun An <sammiee5311@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: btnxpuart: Validate the FW dump header lengthAli Ahmet Memis
nxp_process_fw_dump() pulls the ACL header off the frame and then reads seq_num and buf_len from a struct nxp_fw_dump_hdr placed at skb->data, without checking that the ACL payload is long enough to contain it. h4_recv_buf() collects HCI_ACL_HDR_SIZE bytes of header followed by the number of payload bytes named in that header, so skb->len is 4 + dlen with dlen supplied by the controller and possibly smaller than the 8 byte dump header, or zero. A short frame with connection handle 0xfff therefore reads both fields from beyond the received data. Beyond the read itself, buf_len is what terminates a dump: a value of zero makes the driver call hci_devcd_complete() and reset the controller, so a truncated frame can end a dump early. Use skb_pull_data() to validate and pull the FW dump header before accessing its fields. Warn and reject the chunk if the header is truncated. Fixes: 998e447f443f ("Bluetooth: btnxpuart: Add support for HCI coredump feature") Signed-off-by: Ali Ahmet Memis <ali@iusegentoo.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24docs: kernel-parameters: add CPU_FREQ, CPU_IDLE build optionsRandy Dunlap
CPU_FREQ and CPU_IDLE are used in descriptions of some kernel parameters so add their descriptions to the build options list. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260815172934.3604009-1-rdunlap@infradead.org>
2026-08-24Bluetooth: hci_sync: add conditional locking annotationsPauli Virtanen
Add context analysis annotations to functions doing conditional locking, to suppress analysis warnings. Fixes: cdc36db204ff ("Bluetooth: hci_sync: Fix advertising data UAFs") Tested-by: Nathan Chancellor <nathan@kernel.org> # build Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: btnxpuart: Check remote M.2 connector availability before pwrseqSherry Sun
The current code uses of_graph_is_present() to decide whether to enter the pwrseq path. However, of_graph_is_present() only checks for the structural presence of a port/ports sub-node and does not check the status property. This causes problems when a DT overlay disables the remote M.2 connector node (e.g., switching from PCIe WiFi to SDIO WiFi): the port node still exists, so of_graph_is_present() returns true, but the pwrseq provider never registers because the connector is disabled, leading to an infinite -EPROBE_DEFER loop. Replace of_graph_is_present() with a new helper that traverses the OF graph to the remote port parent (the M.2 connector node) and checks of_device_is_available(). When the remote connector is disabled, the pwrseq path is skipped, allowing the BT driver to fall through to the direct bluetooth child node path. Fixes: e48e332d84d8 ("Bluetooth: btnxpuart: Add M.2 Bluetooth device support using pwrseq") Signed-off-by: Sherry Sun <sherry.sun@nxp.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX pathChris Lu
btmtksdio_tx_packet() rounds the transfer size up to the SDIO block size of 256 bytes, but hands the host controller the SKB buffer as is: err = sdio_writesb(bdev->func, MTK_REG_CTDR, skb->data, round_up(skb->len, MTK_SDIO_BLOCK_SIZE)); Only skb->len bytes hold packet data, so the controller reads up to 255 bytes of uninitialised memory and sends it to the device over the SDIO bus. Depending on how much tailroom slack the SKB allocation happens to carry, that read can also extend past the end of the buffer. Compute the padded length up front, ensure the SKB has tailroom for it, and zero-fill the padding with skb_put_zero(). skb->len then covers the padding, so sdio_writesb() no longer needs to round up. byte_tx keeps counting the header and the payload only, and the error path restores the SKB so that the caller can requeue it. Writing behind skb->tail is only safe because the driver owns the buffer, which "Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TX" ensures. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Signed-off-by: Chris Lu <chris.lu@mediatek.com> Assisted-by: Claude:claude-opus-5 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: btmtksdio: Take exclusive ownership of the SKB before TXChris Lu
btmtksdio_tx_packet() prepends the MediaTek SDIO header with skb_push() and writes into that space after only checking the headroom size. On a cloned SKB that headroom belongs to a buffer shared with the other owner, which the driver has no right to write to. Cloned SKBs do reach this path: hci_send_cmd_sync() keeps a clone of every HCI command in hdev->sent_cmd before handing the SKB to the driver, and l2cap_ertm_send() clones SKBs for retransmission. Replace the open-coded headroom check with skb_cow_head(), which both guarantees the headroom and reallocates a private buffer when the SKB is cloned. The cost is one reallocation and copy per cloned packet, the usual price of this pattern in network drivers. This has no observable effect on its own, as the driver only writes in front of skb->data where no other owner looks. It is a prerequisite for "Bluetooth: btmtksdio: Fix out-of-bounds DMA read in the TX path", which writes padding behind skb->tail, and carries the same Fixes: tag so that both are backported together. Fixes: 9aebfd4a2200 ("Bluetooth: mediatek: add support for MediaTek MT7663S and MT7668S SDIO devices") Signed-off-by: Chris Lu <chris.lu@mediatek.com> Assisted-by: Claude:claude-opus-5 Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: btmtk: Do not discard the subsystem reset timeoutIsmail Tarim
When the MTK_BT_RST_DONE poll times out, btmtk_usb_subsys_reset() logs "Reset timeout" and keeps the error in err, but err is then overwritten by the return value of the following btmtk_usb_id_get() call, so the timeout is never reported to the caller. Commit 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") discarded the return value of the chip id read, so the function returned the timeout error as intended. Commit 3dcb122b3064 ("Bluetooth: btusb: mediatek: return error for failed reg access") started assigning err at that call and silently dropped it. Keep the timeout in a separate variable and return it, restoring the original behaviour without changing the control flow. Fixes: 3dcb122b3064 ("Bluetooth: btusb: mediatek: return error for failed reg access") Signed-off-by: Ismail Tarim <ismailtarim7@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: btmtk: Do not report success when subsys reset failsIsmail Tarim
btmtk_usb_subsys_reset() validates the subsystem reset by reading the chip id back. When that read succeeds at the bus level but yields an id of zero, the reset has demonstrably not taken effect: the function logs "Can't get device id, subsys reset fail." and then returns the return value of btmtk_usb_id_get(), which in that case is zero, i.e. success. btusb_mtk_reset() returns that value unchanged, so its caller cannot tell a completed reset from a failed one. Return -ENODEV when the chip id reads back as zero, leaving the existing MT6639 exemption intact. Observed on an MT7902 [13d3:3579]. The path can be reached on demand by asking the controller for a coredump, since btmtk requests a reset once the dump completes: # echo 1 > /sys/class/bluetooth/hci0/device/coredump Bluetooth: hci0: Mediatek coredump end Bluetooth: hci0: Can't get device id, subsys reset fail. usb 3-10: reset high-speed USB device number 5 using xhci_hcd usb 3-10: device descriptor read/64, error -110 usb usb3-port10: attempt power cycle usb usb3-port10: unable to enumerate USB device The same sequence occurs unprompted when the controller firmware asserts on its own. Note that this corrects the error reporting only; it does not by itself make the controller recoverable in the case above. Fixes: 25b6d7593a3a ("Bluetooth: btmtk: introduce btmtk reset work") Signed-off-by: Ismail Tarim <ismailtarim7@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: L2CAP: fix race l2cap_sock_cleanup_listen() vs. put_chanPauli Virtanen
For L2CAP sockets without owning sk->sk_socket, reading l2cap_pi(sk)->chan may race against concurrent l2cap_sock_kill() -> l2cap_sock_put_chan(). This excludes simultaneous proto_ops callbacks, but access in l2cap_sock_cleanup_listen() has unsafe lockless read. [Task 1] [Task 2 (hdev->workqueue)] l2cap_sock_release(parent) l2cap_disconn_cfm l2cap_sock_cleanup_listen l2cap_conn_del bt_accept_dequeue l2cap_chan_del lock_sock(sk) l2cap_sock_teardown_cb bt_accept_unlink bt_sk(sk)->parent = NULL release_sock(sk) ----------------> lock_sock(sk) parent = /* NULL */ lock_sock(sk) <--------------------- release_sock(sk) sock_set_flag(sk, SOCK_ZAPPED) l2cap_sock_close_cb l2cap_sock_kill(sk) l2cap_sock_put_chan chan = READ l2cap_pi(sk)->chan l2cap_pi(sk)->chan = NULL l2cap_chan_hold_unless_zero l2cap_put_chan(chan) kref_get_unless_zero(&chan->ref) Task 1 may observe NULL which causes null-ptr-deref. Fix the race by taking lock_sock() in l2cap_sock_kill() to synchronize with l2cap_sock_cleanup_listen(). hold_unless_zero() is not needed here, l2cap_pi(sk)->chan owns reference if it is non-NULL. Clarify code comments vs. locking. Fixes: 6fef032af009 ("Bluetooth: L2CAP: Fix use-after-free in l2cap_sock_new_connection_cb()") Reported-by: syzbot+e6382a2f53f5fc7453ac@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=e6382a2f53f5fc7453ac Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: mgmt: fix 'hdev->discovery.uuids' NULL dereferencePavel Shpakovskiy
'uuid_count' member of struct 'discovery_state' is assigned and read without any locks, so there is a chance of situation when uuid_count != 0, but uuids is NULL and there will be NULL pointer dereference. Possible race: 'hci_update_passive_scan_sync' 'hci_discovery_filter_clear' hdev->discovery.uuid_count = 0; <----------------------preempted-----------------------------> 'start_service_discovery' // Set uuid_count to value != 0 hdev->discovery.uuid_count = uuid_count; hdev->discovery.uuids = kmemdup(...); <----------------------preempted-----------------------------> spin_lock(&hdev->discovery.lock); kfree(hdev->discovery.uuids); hdev->discovery.uuids = NULL; spin_unlock(&hdev->discovery.lock); Now uuids == NULL and uuid_count != 0. So 'mgmt_device_found' -> 'is_filter_match' -> 'eir_has_uuids' receives non consistent discovery state, where NULL dereference of uuids happens. To fix it let's add discovery.lock around every read/write of uuid_count, uuids pair of struct members. It is also important to assign uuid_count value only after success kmemdup() allocation in start_service_discovery(), otherwise uuids is NULL, because kmemdup failed, but uuid_count is already assigned to non zero value. The following panic happens: [ ] ------------[ cut here ]------------ [ ] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ ] Internal error: Oops: 0000000096000006 [#1] PREEMPT SMP [ ] CPU: 0 PID: 15056 Comm: kworker/u9:2 [ ] Workqueue: hci0 hci_rx_work [ ] pstate: 10400009 (nzcV daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ ] pc : eir_has_uuids+0x2d8/0x590 [ ] lr : is_filter_match+0x258/0x320 ... [ ] Call trace: [ ] eir_has_uuids+0x2d8/0x590 [ ] is_filter_match+0x258/0x320 [ ] mgmt_device_found+0x5b0/0xafc [ ] process_adv_report.part.0+0x8c8/0xf14 [ ] hci_le_adv_report_evt+0x338/0x3f0 [ ] hci_le_meta_evt+0x1f0/0x4c8 [ ] hci_event_packet+0x440/0xc9c [ ] hci_rx_work+0x44c/0xaf8 [ ] process_one_work+0x54c/0x103c [ ] worker_thread+0x6c4/0x10c4 [ ] kthread+0x274/0x2ec [ ] ret_from_fork+0x10/0x20 [ ] Code: 14000004 91004021 eb14003f 54000180 (f9400024) [ ] ---[ end trace 0000000000000000 ]--- Fixes: 2935e556850e ("Bluetooth: hci_sync: fix double free in 'hci_discovery_filter_clear()'") Signed-off-by: Pavel Shpakovskiy <pashpakovskii@salutedevices.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24docs/sched_ext: document that cgroup CPU knobs are scheduler-dependentTao Cui
The scheduler core communicates the initial cpu controller settings to the BPF scheduler through ops.cgroup_init() and reports subsequent changes through the corresponding ops.cgroup_set_*() callbacks. Whether and how a knob takes effect is up to the loaded scheduler: it may implement the corresponding callback partially or not at all, so cpu.max, cpu.weight and friends can silently have no effect. Document this in the basics section of sched-ext.rst. Signed-off-by: Tao Cui <cuitao@kylinos.cn> Reviewed-by: Andrea Righi <arighi@nvidia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-24Bluetooth: L2CAP: reject accept queue add unless BT_LISTENPauli Virtanen
New sk should not be added to parent socket accept queue after last l2cap_sock_cleanup_listen() has run in l2cap_sock_teardown_cb() and state set to BT_CLOSED, as that can result to UAF on dereferencing the dangling parent reference. l2cap_sock_new_connection_cb() may race with parent l2cap_chan teardown, due to chan->state accessed without consistent locking: [Task 1] [Task 2] l2cap_sock_release(parent) l2cap_connect l2cap_sock_shutdown pchan = l2cap_global_chan_by_psm l2cap_chan_lock(pchan) l2cap_chan_close l2cap_sock_teardown_cb pchan->state = BT_CLOSED l2cap_chan_unlock(pchan) ------> l2cap_chan_lock(pchan) l2cap_new_connection l2cap_sock_new_connection_cb l2cap_chan_lock(pchan) <-------- l2cap_chan_unlock(pchan) l2cap_sock_kill(parent) /* bt_sk(sk)->parent dangling */ Fix by adding check for sk_state == BT_LISTEN after acquiring sk lock in l2cap_sock_new_connection_cb(). Add lock_sock() around sk_state writes where missing, to avoid data races. Although the data races on pchan->state should be fixed too, this defensive sk_state check probably makes sense in any case. Fixes: 2ff1a41a912d ("Bluetooth: L2CAP: Fix null-ptr-deref in l2cap_sock_state_change_cb()") Reported-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Closes: https://syzkaller.appspot.com/bug?extid=9265e754091c2d27ea29 Signed-off-by: Pauli Virtanen <pav@iki.fi> Reported-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Tested-by: syzbot+9265e754091c2d27ea29@syzkaller.appspotmail.com Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: L2CAP: access chan->conn safely in get/setsockoptPauli Virtanen
Since commit b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") l2cap_chan::conn has held reference and remains non-NULL also after the corresponding hci_conn is deleted. In this state accessing various fields eg. hci_conn::hdev is invalid, which leads to KASAN crash in l2cap_sock_setsockopt() access of conn->hcon->hdev. Check l2cap_chan::conn.hcon corresponds to an alive hci_conn before trying to use it in l2cap_sock.c. Hold l2cap_chan_lock() in getsockopt/setsockopt to ensure it stays alive, and to avoid data races in l2cap_chan fields. Fixes: b66774b48dd9 ("Bluetooth: L2CAP: Fix UAF in channel timeout by holding conn ref") Reported-by: syzbot+b106284c2a0b7bc80cf9@syzkaller.appspotmail.com Link: https://syzkaller.appspot.com/bug?extid=b106284c2a0b7bc80cf9 Signed-off-by: Pauli Virtanen <pav@iki.fi> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: hci_intel: fix usage_count leak when autosuspend_delay is negativeGuangshuo Li
intel_set_power() calls pm_runtime_use_autosuspend() when powering on the device, but the power-off path does not call the matching pm_runtime_dont_use_autosuspend() before disabling runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: 74cdad37cd24 ("Bluetooth: hci_intel: Add runtime PM support") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: hci_h5: fix usage_count leak when autosuspend_delay is negativeGuangshuo Li
h5_btrtl_open() calls pm_runtime_use_autosuspend(), but h5_btrtl_close() does not call the matching pm_runtime_dont_use_autosuspend() when tearing down runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: d9dd833cf6d2 ("Bluetooth: hci_h5: Add runtime suspend") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Bluetooth: hci_bcm: fix usage_count leak when autosuspend_delay is negativeGuangshuo Li
bcm_request_irq() calls pm_runtime_use_autosuspend(), but bcm_close() does not call the matching pm_runtime_dont_use_autosuspend() when tearing down runtime PM. If the autosuspend delay is set to a negative value while autosuspend is enabled, the runtime PM core increments usage_count to prevent runtime suspend. Without calling pm_runtime_dont_use_autosuspend() during driver teardown, this reference is not dropped and usage_count remains unbalanced. Add the missing pm_runtime_dont_use_autosuspend() call before disabling runtime PM. This issue was found by manual code inspection. Fixes: e88ab30d3669 ("Bluetooth: hci_bcm: Add suspend/resume runtime PM functions") Cc: stable@vger.kernel.org Signed-off-by: Guangshuo Li <lgs201920130244@gmail.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Merge tag 'mailbox-v7.3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox Pull mailbox updates from Jassi Brar: - mhuv2: - convert channel translation to fw_xlate() - use generic device property APIs - axiado: - add AX3005 mailbox controller driver and DT bindings - bcm2835: - use platform_get_irq() - simplify probe error handling - cix: - fix DT property string typo - use dev_err_probe() - exynos: - add Exynos850 mailbox driver support and DT bindings - microchip: - add null check for devm_kasprintf() - pcc: - fix missed-interrupt command timeout - verify shared memory signature - notify clients on polled completion - qcom: - fix CPUCP PREEMPT_RT deadlock and NULL data crash - fix IPCC duplicate channel allocation across holes - add IPQ5210 APCS and Nord IPCC bindings - riscv: - validate RPMI notification buffer lengths and event payload bounds - rockchip: - manage peripheral clock with devm helper - drop unused struct field - ti-msgmgr: - convert bindings to DT schema - remove redundant dev_err()/dev_err_probe() on IRQ request failures across drivers * tag 'mailbox-v7.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox: (22 commits) mailbox: add Axiado AX3005 mailbox driver dt-bindings: mailbox: add Axiado AX3005 mailbox dt-bindings: mailbox: Convert TI Message Manager to DT schema mailbox: cix: fix DT property name string typo and use dev_err_probe() mailbox: riscv-sbi-mpxy: validate RPMI notification lengths mailbox: bcm2835: use platform_get_irq and simplify probe mailbox: qcom-ipcc: fix duplicate channel allocation across holes mailbox: mchp-ipc-sbi: Add null check for devm_kasprintf() mailbox: Remove redundant dev_err()/dev_err_probe() dt-bindings: mailbox: qcom: Add IPQ5210 APCS compatible dt-bindings: mailbox: qcom-ipcc: Document Nord IPCC mailbox: exynos: Add support for Exynos850 mailbox dt-bindings: mailbox: google,gs101-mbox: Add samsung,exynos850-mbox mailbox: pcc: Fix command timeout due to missed interrupt mailbox: pcc: Check shared memory signature on request mailbox: pcc: Notify clients on polled completion mailbox: rockchip: drop unneeded runtime pointer (pclk) mailbox: rockchip: disable pclk on probe failure and unbind mailbox: qcom-cpucp: handle NULL data in send_data callback mailbox: qcom-cpucp: fix PREEMPT_RT self-deadlock in IRQ handler ...
2026-08-24doc:it_IT: align Italian documentation in processFederico Vaga
This commit updates the Italian translation in `process/` following these changes: commit 44abc8fcbff2 ("Documentation: process: Arbitrarily bump kernel major version number") commit ba2457109d5b ("Documentation: process: Also mention Sasha Levin as stable tree maintainer") commit 5ce70894f6ca ("Doc: correct spelling and wording mistakes") commit 46298375477b ("linux-next: update maintainer info.") commit 43e9076a00b1 ("docs: Fix conflicting contributor identity info") commit b27f9e8079bf ("docs: remove Documentation/dontdiff") commit 9734b3e753ad ("docs: 5.Posting: mentioned Suggested-by: tag") commit 4e6b7141d169 ("docs: clarify rules wrt tagging other people") commit 944df7a31452 ("docs: update the guidance for Link: tags") commit 0a83293322fd ("doc: development-process: add notice on testing") commit a037699da0a1 ("docs: Add debugging section to process") commit 78d979db6cef ("docs: add AI Coding Assistants documentation") commit a66437c27979 ("Documentation: Provide guidelines for tool-generated content") commit a592a36e4937 ("Documentation: use a source-read extension for the index link boilerplate") commit 102606402f4f ("Documentation: Project continuity") commit a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug") commit d0b343605f1b ("kernel-docs: Add new section for Rust learning materials") commit 57937eac1f78 ("kernel-docs: Add book to process/kernel-docs.rst") commit d8c949c577b5 ("docs/licensing: Clarify wording about "GPL" and "Proprietary"") commit ebf1bafd0907 ("LICENSES: Explicitly allow SPDX-FileCopyrightText") commit 9fa7153c31a3 ("rust: conclude the Rust experiment") commit 47cb33cedf47 ("docs: clarify wording in programming-language.rst") commit 45a92c0b91d7 ("docs: maintainers: add SPDX license to the file") commit 2932ba8d9c99 ("slab: Introduce kmalloc_obj() and family") commit e4c8b46b924e ("slab: Introduce kmalloc_flex() and family") commit d957b4184aee ("Documentation: deprecated.rst: kmalloc-family: mark argument as optional") commit 120a64c8021d ("Documentation: process: fix brackets") commit 079a028d6327 ("string: Remove strncpy() from the kernel") commit e551bd4109d2 ("Documentation: remove :kyb: tags") commit 4971ca2007e3 ("docs: process: email-client: add Thunderbird "Toggle Line Wrap" extension") commit f44a29784f68 ("Documentation: update maintainer-pgp-guide for latest best practices") commit 273aa250f138 ("Documentation: Improve wording on requirements for a free Nitrokey") commit 6c5c07bc8589 ("docs: process: maintainer-pgp-guide: update kernel.org docs link") commit 54857c52452a ("docs: maintainer-pgp-guide.rst: add a reference for kernel.org sign") commit a556bd882b94 ("docs: align with scripts/syscall.tbl migration") commit e5b1c0fa4ff2 ("Documentation: Remove :manpage: from non-existing man pages") commit 78a00cac1e96 ("docs: fix 're-use' -> 'reuse' in documentation") commit ec6fd28baf61 ("docs: remove unneeded maintainer_handbooks_main label") commit 8eae6da5f56c ("docs: auto-generate maintainer entry profile links") commit bda185c30593 ("docs: maintainers_include: Only show main entry for profiles") commit 2783096fb1dd ("docs: submit-checklist: Expand on build tests against different word sizes") commit fb12098d8ee4 ("docs: submit-checklist: Allow creating cross-references for ABI README") commit 5a63f0369bda ("docs/.../submit-checklist: Use Documentation/admin-guide/abi.rst for cross-ref of README") commit e5880f95a979 ("docs: process: discourage pointless boilerplate kdoc") commit 2c62e2e874d1 ("coding-style: fix verb typo") commit 197bbebd2581 ("docs: Update documentation to avoid mentioning of kernel.h") commit eba6ffd126cd ("docs: kdoc: move kernel-doc to tools/docs") commit 7c6d969d5349 ("Documentation: adopt new coding style of type-aware kmalloc-family") commit 323fa4b9608b ("Documentation: Fix syntax of kmalloc_objs example in coding style doc") commit d49172bbd7eb ("Documentation: clarify the expected collaboration with security bugs reporters") commit 3a68841d1d9b ("Documentation: smooth the text flow in the security bug reporting process") commit ceddb2c001d9 ("Documentation: insist on the plain-text requirement for security reports") commit f2b1cbef1536 ("Documentation: minor updates to the security contacts") commit a72b832a4823 ("Documentation: explain how to find maintainers addresses for security reports") commit 496fa1befba1 ("Documentation: clarify the mandatory and desirable info for security reports") commit f387e2e2b9d3 ("Documentation: fix two typos in latest update to the security report howto") commit aed3c3346765 ("Documentation: security-bugs: do not systematically Cc the security team") commit 4bf85afb9f3e ("Documentation: security-bugs: clarify requirements for AI-assisted reports") commit 561458db0d6b ("docs: security-bugs: add a link to the threat-model documentation") commit 5f5e7344322f ("kbuild: generate offset range data for builtin modules") commit 41047d53bcff ("docs:process:changes: fix version command for btrfs-progs") commit 82a1978d0fdc ("kheaders: use 'tar' instead of 'cpio' for copying files") commit d2b239099cf0 ("docs: changes: update Sphinx minimal version to 3.4.3") commit 5e25b972a22b ("docs: changes: update Python minimal version") commit 118c40b7b503 ("kbuild: require gcc-8 and binutils-2.30") commit 28d51df0dbaa ("Documentation: update binutils-2.30 version reference") commit fc6edeea53f4 ("docs: Remove reiserfsprogs from dependencies.") commit bc20c56e98e0 ("docs: changes: better document Python needs") commit 20c098928356 ("kbuild: Bump minimum version of LLVM for building the kernel to 15.0.0") commit 903922cfa0e6 ("lib/Kconfig.debug: Set the minimum required pahole version to v1.22") commit 8913632998fc ("Documentation: Fix typos and grammatical errors") commit c99fcb58501e ("docs: Fix an erroneous reference to sphinx.rst") commit d8a224f519c6 ("docs: changes/ver_linux: fix entries and add several tools") commit ece7e57afd51 ("docs: changes.rst and ver_linux: sort the lists") commit f32fb9c58a5b ("rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)") commit c3a00a3f31ff ("rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)") commit ce3267a39a92 ("kbuild: Bump minimum version of LLVM for building the kernel to 17.0.1") commit 2c1ccd9a1d78 ("docs: changes.rst: restore pahole 1.26 minimum (regressed by sort)") commit 3f997cbf676b ("docs: process: submitting-patches: split canonical patch format section") commit 6356f18f09dc ("Align git commit ID abbreviation guidelines and checks") commit cd9123eeb224 ("docs: submitting-patches: clarify Acked-by and introduce "# Suffix"") commit 25fb101385f7 ("docs: submitting-patches: clarify difference between Acked-by and Reviewed-by") commit 08c035da54a3 ("docs: submitting-patches: clarify that signers may use their discretion on tags") commit 95767a592dc9 ("docs: submitting-patches: document the format for affiliation") commit dc896f853e1a ("docs: submitting-patches: adjust Fixes definition slightly") commit 22014a230093 ("Documentation/process: submitting-patches: fix typo in "were do"") commit e36a7b1e1734 ("docs: submitting-patches: Clarify that removal of Acks needs explanation too") commit 8a12e3fbf2c3 ("docs: submitting-patches: suggest adding previous version links") commit 6252e5c1c20e ("docs: add an Assisted-by mention to submitting-patches.rst") commit 48c3876a6a6f ("docs: submitting-patches: Clarify that "reviewer" is a person") commit 83f71fbc66fb ("docs: submitting-patches: Fix section structure around DCO") Signed-off-by: Federico Vaga <federico.vaga@vaga.pv.it> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260816193906.68808-1-federico.vaga@vaga.pv.it>
2026-08-24selftests/cgroup: Add test for preserving boot-isolated CPUsGuopeng Zhang
Put a CPU isolated at boot into an isolated partition, change the partition back to member and check that the CPU remains isolated. Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn> Reviewed-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-24docs: threat-model: fix /dev/kmsg referenceJohan Hovold
Fix a '/dev/kmsg' reference which got replaced with '/proc/kmsg' (which is not accessible to regular users). Fixes: a03ef333fbd6 ("Documentation: security-bugs: explain what is and is not a security bug") Signed-off-by: Johan Hovold <johan@kernel.org> Acked-by: Willy Tarreau <w@1wt.eu> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260819134039.286793-1-johan@kernel.org>
2026-08-24cgroup/cpuset: Preserve boot-isolated CPUs on partition releaseGuopeng Zhang
isolated_cpus tracks CPUs isolated with isolcpus= as well as CPUs in isolated cpuset partitions. When an isolated partition is released, isolated_cpus_update() removes its whole CPU mask. This also clears CPUs which were already isolated at boot. This can be reproduced on a cgroup v2 system booted with isolcpus=domain,15: cd /sys/fs/cgroup echo +cpuset > cgroup.subtree_control mkdir cpuset-repro echo 15 > cpuset-repro/cpuset.cpus echo isolated > cpuset-repro/cpuset.cpus.partition echo member > cpuset-repro/cpuset.cpus.partition cat cpuset.cpus.isolated CPU 15 is absent before the change. It must remain in cpuset.cpus.isolated after the partition is released. Update isolated_cpus one CPU at a time and keep CPUs outside the boot-time domain housekeeping mask isolated. Fixes: c188f33c864e ("cgroup/cpuset: Account for boot time isolated CPUs") Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn> Acked-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-24selftests/cgroup: Drop invalid boot isolation comparisonGuopeng Zhang
check_isolcpus() clears ISOLCPUS before rebuilding it from sched domain data. Comparing that empty value with /sys/devices/system/cpu/isolated makes the test fail whenever isolcpus=domain is present. That sysfs file is generated from HK_TYPE_DOMAIN_BOOT and does not change when cpuset updates HK_TYPE_DOMAIN. Re-reading it cannot validate dynamic housekeeping updates. The cpuset.cpus.isolated and sched domain checks already cover the two dynamic interfaces, so remove the invalid comparison. This can be reproduced on a kernel booted with isolcpus=domain,15: # tools/testing/selftests/cgroup/test_cpuset_prs.sh The test fails its first state-matrix isolation check before the change and continues past that check afterward. Fixes: 6df415aa46ec ("cgroup/cpuset: Defer housekeeping_update() calls from CPU hotplug to workqueue") Signed-off-by: Guopeng Zhang <zhangguopeng@kylinos.cn> Reviewed-by: Waiman Long <longman@redhat.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-24docs: block: fix dead http link in blk-mq.rstJenson Johnathon Reggentin
The current link http://kernel.dk/blk-mq.pdf leads to a 404 error page. https://www.kernel.dk/blk-mq.pdf leads to the correct document. v2 to add the missing www. prefix in the actual file change. Signed-off-by: Jenson Johnathon Reggentin <mail@jregg.de> Acked-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260819192422.42189-1-mail@jregg.de>
2026-08-24docs/ja_JP: translate submitting-patches.rst (tag usage)Akiyoshi Kurita
Translate the Acked-by:, Cc:, and Co-developed-by: section into Japanese. Signed-off-by: Akiyoshi Kurita <weibu@redadmin.org> Acked-by: Akira Yokosawa <akiyks@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net> Message-ID: <20260730130030.1078990-1-weibu@redadmin.org>
2026-08-24docs: cgroup-v2: fix misc.events key format descriptionCheng Lingfei
In misc cgroup, misc.events does not output a simple "max" key. Instead, each registered misc resource outputs a separate key suffixed with ".max" (i.e., "<res>.max"). Update the documentation to clarify that the entry key is "<res>.max". Suggested-by: Michal Koutný <mkoutny@suse.com> Signed-off-by: Cheng Lingfei <chenglingfei@foxmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2026-08-24Bluetooth: hci_sync: Clear HCI_CMD_PENDING when dropping the last requestIbrahim Abdelkader
A synchronous HCI command that never receives a response leaves HCI_CMD_PENDING set: hci_req_cmd_complete() is the only place that clears it, and it only runs when a response matching the last command sent arrives. hci_send_cmd_sync() populates hdev->req_skb only when the flag transitions from clear to set, while hci_dev_open_sync() and hci_dev_close_sync() drop req_skb without clearing the flag. After a timeout followed by either, the two disagree: the flag claims a request is outstanding while req_skb is NULL. Subsequent synchronous commands are then sent with no req_skb, so hci_event_packet() has nothing to match an arriving event against, and the caller times out even though the controller answered. Commands answered by Command Complete recover on their own, since hci_req_cmd_complete() clears the flag as a side effect. Drivers using __hci_cmd_sync_ev() with a custom event do not, because a vendor event never reaches that path. On a WCN3988 (hci_qca over UART) this makes a controller firmware hang unrecoverable: the driver injects a hardware error and re-runs qca_setup(), qca_read_soc_version() waits for HCI_EV_VENDOR, the reply arrives within 4 ms and is discarded, and every retry fails the same way. The adapter is left down until the driver is unbound and rebound, or power is removed. Clear the flag wherever the last request is dropped, restoring the invariant that req_skb is non-NULL exactly when HCI_CMD_PENDING is set. Verified on hardware by forcing a command timeout: without this change setup fails on every attempt, with it setup succeeds on the first. Fixes: 2615fd9a7c25 ("Bluetooth: hci_sync: Fix overwriting request callback") Cc: stable@vger.kernel.org Signed-off-by: Ibrahim Abdelkader <iabdelka@qti.qualcomm.com> Signed-off-by: Hans de Goede <johannes.goede@oss.qualcomm.com> Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
2026-08-24Merge tag 'kvmarm-7.3' of ↵Paolo Bonzini
https://git.kernel.org/pub/scm/linux/kernel/git/kvmarm/kvmarm into HEAD KVM/arm64 changes for 7.3 - Add support for 'slot' based PMU events, paired with new UAPI that compels the user to select a specific PMU implementation - Lazy save/restore of vCPU state for pKVM, along with various fixes and cleanups to the management of vCPU state between the untrusted host and pKVM hypervisor - Disable traps of EL1 registers for nested hypervisors when FEAT_NV2p1 is present, guaranteeing that EL2-specific register bits are stateful in the EL1 counterpart - Leverage FEAT_NV3 to avoid unnecessary ERET/TLBI traps when the scope of those instructions remains 'in host' (i.e. L1 kernel/userspace) - Pile of fixes for the management of the VNCR pseudo-TLB, such as under-invalidations and races with concurrent TLBIs on other vCPUs - Consolidate the non-protected and pKVM view of ICH_VTR_EL2 to a runtime-patched constant, allowing the same data to be shared with pKVM prior to dropping host privileges - Considerable pile of LLM-assisted fixes around the shop but mostly in the VGIC, our in-kernel generator of bugs (and sometimes interrupts)
2026-08-24accel/amdxdna: put the chained BO when its mapping failsTaimuraz Kaitmazov
amdxdna_cmd_set_error() looks up the first BO of a command chain, which takes a reference, and drops it at the end of the function. The mapping of that BO is established in between, and the failure path returns without the put, so the reference is leaked. Ordinary use does not reach it. The chain has been submitted before any of this runs, so aie2_cmdlist_fill_slot() has already called amdxdna_cmd_get_op() on that BO and amdxdna_gem_vmap() has cached its address. What makes it reachable is that the BO is resolved again by handle here, and the handle is userspace's to recycle: closing it after submission and importing a dma-buf whose exporter implements no vmap onto the same id leaves amdxdna_gem_get_obj() returning an object this cannot map, since prime_import() types every import AMDXDNA_BO_SHARE. Fixes: d76856beb4a4 ("accel/amdxdna: Refactor GEM BO handling and add helper APIs for address retrieval") Signed-off-by: Taimuraz Kaitmazov <taimuraz@kaitmazov.com> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260819230852.287751-1-taimuraz@kaitmazov.com
2026-08-24accel/amdxdna: reject a command chain that carries no commandsTaimuraz Kaitmazov
A chain whose command_count is zero passes the payload length check, because struct_size(payload, data, 0) is just the header. The fill loop then does not run, so offset stays zero and the request is submitted with a zero-length buffer. On firmware without AIE2_NPU_COMMAND that ends at the opcode check, since op is still ERT_INVALID_CMD and aie2_get_chain_msg_op() answers MSG_OP_MAX_OPCODE. aie2_get_npu_chain_msg_op() answers MSG_OP_CHAIN_EXEC_NPU whatever it is given, so there the submission continues to drm_clflush_virt_range(cmd_buf, 0), which reads the byte before the buffer and faults on the vmap guard page. EXEC_CMD is reachable by any process that can open the render node. Reject the request instead. Fixes: 8ed8b0239617 ("accel/amdxdna: Add debug prints for command submission") Signed-off-by: Taimuraz Kaitmazov <taimuraz@kaitmazov.com> Reviewed-by: Lizhi Hou <lizhi.hou@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260818000019.369366-1-taimuraz@kaitmazov.com
2026-08-24accel/amdxdna: Remove __counted_by from struct amdxdna_cmd_chainLizhi Hou
struct amdxdna_cmd_chain contains a flexible array annotated with __counted_by(command_count). Since the structure is stored in shared AMDXDNA_BO_SHARE memory, userspace can modify command_count concurrently. If command_count is changed to zero, the bounds check generated from __counted_by may fail and trigger a kernel panic. Remove __counted_by to avoid relying on the userspace-controlled command_count for the flexible array bounds check. Fixes: aac243092b70 ("accel/amdxdna: Add command execution") Reviewed-by: Max Zhen <max.zhen@amd.com> Signed-off-by: Lizhi Hou <lizhi.hou@amd.com> Link: https://patch.msgid.link/20260821033543.1839719-1-lizhi.hou@amd.com
2026-08-24Merge tag 'i2c-7.3-part2' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux Pull more i2c updates from Andi Shyti: "Fixes and cleanups around probe error handling, resource management and a minor Rust cleanup. Drivers: - several drivers: drop duplicate IRQ error reporting - imx-lpi2c: improve probe initialization and error cleanup - mxs: fix DMA channel leak on probe failure - ocores: fix clock cleanup on resume failure - rcar: handle reset controllers without status support Muxes: - demux-pinctrl: fix OF node leak on allocation failure Rust: - mark trivial I2cAdapter reference-counting methods inline" * tag 'i2c-7.3-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/andi.shyti/linux: i2c: rust: mark I2cAdapter methods as inline i2c: rcar: fix reset handling for Gen5 i2c: mxs: fix DMA channel leak on probe error i2c: mux: demux-pinctrl: fix OF node leak on kstrdup failure i2c: ocores: Disable clock on failed resume i2c: imx-lpi2c: reset controller in probe stage i2c: imx-lpi2c: properly unwind resources on probe failure i2c: busses: drop redundant dev_err_probe() around irq helpers
2026-08-24Merge tag 'pinctrl-v7.3-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control updates from Linus Walleij: "Core changes: - Use the non-blocking mux_state_try_select() in the generic MUX pin control back-end - Free pin maps on pinctrl_generic_to_map() failure in the core helpers New hardware pin control: - Qualcomm Maili TLMM SoC, PMG1110 PMIC, and Eliza LPASS LPI TLMM SoC (this is for the low power audio, LPASS = Low Power Audio SubSystem portions) - Upboard support on top of the Intel pin controller - Apple T6030 and T6031 support (just compatible strings) - Samsung Exynos 8855 SoC - Mediatek MT6858 SoC - Rockchip RK3308B and RV1106 SoCs - Airoha EN7523 and AN7563 SoCs Improvements: - Qualcomm TLMM GPIOs are unconditionally marked as wakeup capable - Qualcomm improvements on top of the Qualcomm PDC (power domain controller) irqchip improvements from tglx:s tree - Qualcomm IPQ806x and IPQ9650 non-urgent pin grop fixups - The NPCM8xx driver has been put into shape fixing many pin and group definitions - Some non-urgent Tegra 264 pin assignments are fixed up - Some non-urgent fixups to Airoha AN7581 and AN7583 registers and pin assignments, missing features etc" * tag 'pinctrl-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: (130 commits) dt-bindings: pinctrl: Convert TI DA850 pupd to DT schema pinctrl: meson: sync some modify from A4 pinctrl: meson: a4: Add input enable pin configuration pinctrl: realtek: rtd1625: remove unused group name spdif_sel pinctrl: realtek: rtd1625: fix base_bit for VE4 GPIO 13 dt-bindings: pinctrl: microchip,pic32mzda-pinctrl: Convert to DT schema Revert "Merge branch 'ib-rsk7204' into devel" pinctrl: rockchip: Add RV1106 pinctrl support dt-bindings: pinctrl: rockchip: Add RV1106 compatible pinctrl: rockchip: Decode drive strength in the get function pinctrl: fix PINCTRL_GENERIC_MUX not always being selectable pinctrl: airoha: add support of an7563 SoC dt-bindings: pinctrl: airoha: add support of an7563 pin controller pinctrl: airoha: try to find chip scu node by phandle first pinctrl: airoha: add support of en7523 SoC dt-bindings: pinctrl: airoha: add support of en7523 pin controller pinctrl: airoha: an7583: add support for olt pinmux pinctrl: airoha: an7583: add support for pon_alt pinmux pinctrl: airoha: an7583: add support for npu_uart pinmux dt-bindings: pinctrl: airoha: an7583: add missed features ...
2026-08-24f2fs: use adjusted write range after f2fs_write_checks()Seongjae Jeong
generic_write_checks() in f2fs_write_checks() can adjust iocb->ki_pos for append writes and truncate the iterator to limit the number of bytes to write. In f2fs_file_write_iter(), the pinned-file overwrite check currently uses the position and count saved before f2fs_write_checks(), so it can check a range different from the actual write range. The forced buffered I/O cleanup also uses orig_pos saved before f2fs_write_checks(). For O_APPEND writes, this can make the cleanup flush and invalidate the wrong page cache range. Move the pinned-file overwrite check after f2fs_write_checks() and use the adjusted iocb->ki_pos and iov_iter_count(from). Also save the adjusted write position and use it for the forced buffered I/O cleanup. Fixes: 3fdd89b452c2 ("f2fs: prevent writing without fallocate() for pinned files") Fixes: 92318f20d703 ("f2fs: preserve direct write semantics when buffering is forced") Signed-off-by: Seongjae Jeong <jsjlee1020@gmail.com> Reviewed-by: Chao Yu <chao@kernel.org> Signed-off-by: Jaegeuk Kim <jaegeuk@kernel.org>
2026-08-24Merge tag 'auxdisplay-v7.3-1' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay Pull auxdisplay updates from Andy Shevchenko: - Cancel backlight work on panel registration failure - Miscellaneous cleanups * tag 'auxdisplay-v7.3-1' of git://git.kernel.org/pub/scm/linux/kernel/git/andy/linux-auxdisplay: auxdisplay: charlcd: cancel backlight work on registration failure auxdisplay: panel: Remove unused callback binding code auxdisplay: Remove redundant dev_err()
2026-08-24fuse: zero the partial EOF page when extending a fileJimmy Zuber
Extending a fuse file past a non-page-aligned EOF does not zero the tail of the old last page. When that page is cached and has been mmap-dirtied beyond the old EOF, the now in-bounds tail is served to later reads as stale data rather than zeros, which violates POSIX file-extension semantics. Some file systems get this zeroing automatically at writeback time (block_write_full_folio() / iomap_writeback_handle_eof() zero the tail of the folio straddling i_size). A non-writeback caching fuse file system uses neither path, so it has to zero the tail itself from the size-extending paths, like XFS (xfs_file_write_zero_eof()) and ext4 (ext4_block_zero_eof()) do. Call truncate_pagecache_range() over the newly-exposed range up front from the three paths that extend a file, before the new size is published: - a buffered write whose position is past the old EOF (fuse_perform_write()); - a size-extending setattr/truncate (fuse_do_setattr()); - a size-extending fallocate (fuse_file_fallocate()). This unmaps the stale mappings and zeroes the partial tail of the old EOF folio, so a later read returns zeros. Truncating [old EOF, write start) before a buffered write keeps the dropped range disjoint from the written data, so a write that lands inside the old EOF folio is preserved. writeback_cache connections are unaffected, as their writes go through iomap_file_buffered_write(), which zeroes post-EOF folios. The bug is observable on a non-writeback_cache server that returns FOPEN_KEEP_CACHE on writable files (without FOPEN_DIRECT_IO), and is caught by the new write_extend_eof fuse selftest. Signed-off-by: Jimmy Zuber <jamz@amazon.com> Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
generated by cgit v1.2.3 (git 2.25.1) at 2026-09-08 15:16:05 +0000