commit d27334b2888c10d2b60c954c59b186182d833107 Author: Greg Kroah-Hartman Date: Sun Aug 9 20:22:05 2026 +0200 Linux 6.6.151 Link: https://lore.kernel.org/r/[email protected] Tested-by: Pavel Machek (CIP) Tested-by: Shuah Khan Tested-by: Peter Schneider Tested-by: Wentao Guan Tested-by: Brett A C Sheffield Tested-by: Ron Economos Tested-by: Miguel Ojeda Tested-by: Mark Brown Signed-off-by: Greg Kroah-Hartman commit 5b75a6e292b82f266051a58783204014025db01a Author: Andrei Kuchynski Date: Fri Jul 17 10:46:14 2026 +0000 usb: typec: ucsi: Correct teardown ordering in ucsi_init() error path commit fb0bf289f5d529336ef490c8273e88a8a8b29f69 upstream. The commit 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") consolidated port teardown into the ucsi_unregister_port() helper. However, it introduced an ordering problem in the ucsi_init() error path. Fix this by ensuring ucsi_unregister_port() is called before we unregister their corresponding lockdep keys. Cc: [email protected] Fixes: 7aa7d4bf9d3f ("usb: typec: ucsi: Fix race condition and ordering in port unregistration") Reported-by: "Borah, Chaitanya Kumar" Closes: https://lore.kernel.org/all/[email protected]/ Signed-off-by: Andrei Kuchynski Tested-by: Chaitanya Kumar Borah Reviewed-by: Heikki Krogerus Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman commit da302460e1516e9e5ec6367a9871c88fd0901758 Author: Thomas Zimmermann Date: Tue Apr 21 09:29:05 2026 +0200 drm/tegra: fbdev: Do not assign to struct drm_fb_helper.info commit d23bd83f3e47a928e783c0d6a004737519dc77dc upstream. That field already contains the value being assigned. No need to do this twice. Signed-off-by: Thomas Zimmermann Fixes: 63c971af4036 ("drm/fb-helper: Allocate and release fb_info in single place") Cc: [email protected] Signed-off-by: Thierry Reding Link: https://patch.msgid.link/[email protected] Signed-off-by: Greg Kroah-Hartman commit dcaba7b281724c692ea76b944daae595ce43be23 Author: Kai Vehmanen Date: Thu Aug 6 13:02:03 2026 -0400 ALSA: hda: codecs: hdmi: disable keep-alive before audio format change [ Upstream commit a3d6d3cedfe87bbd5a677d52b22ac20d28e59cf8 ] When a keep-alive (KAE) silent stream is active on an Intel HDMI/DP codec, opening a real PCM stream reprograms the converter format and the audio infoframe in snd_hda_hdmi_generic_pcm_prepare(). Part of that reprogramming - the converter channel count and the channel mapping in snd_hda_hdmi_setup_audio_infoframe() - is not safe to do while a keep-alive stream is active. This is most visible when switching to a multichannel PCM configuration, where the active channel count actually changes. In that case the newly opened PCM stream plays no sound. Add an optional hdmi_ops .prepare hook, called at the start of the PCM prepare sequence (before the format and infoframe are touched), and implement it for HSW+ to release keep-alive. Keep-alive is then re-enabled as before once the new stream has been set up, in the setup_stream op. Fixes: 15175a4f2bbb ("ALSA: hda/hdmi: add keep-alive support for ADL-P and DG2") Reported-by: Alexander Kaplan Closes: https://gitlab.freedesktop.org/drm/xe/kernel/-/work_items/8412 Tested-by: Alexander Kaplan Cc: Signed-off-by: Kai Vehmanen Link: https://patch.msgid.link/[email protected] Signed-off-by: Takashi Iwai [ adapted three hunks from the post-6.12 split files (hdmi.c/hdmi_local.h/intelhdmi.c) back into the monolithic sound/pci/hda/patch_hdmi.c, with the prepare hook un-indented one level since 6.12 uses plain mutex_lock() instead of scoped_guard() ] Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 84351f12390349ba010920fc247e1a0b12e41eb3 Author: Jani Nikula Date: Mon Aug 3 16:26:58 2026 -0400 drm/i915/hdcp: check streams[] bounds before overflow [ Upstream commit bbb15a6b042d02e5508a02b4847e02d2579ee7bc ] The data->streams[] overflow check is done after the buffer overflow has already happened. Move the overflow check before the write. Side note, emitting a warning splat with a backtrace might be overkill here, but prefer not changing the behaviour other than not doing the overrun. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: e03187e12cae ("drm/i915/hdcp: MST streams support in hdcp port_data") Cc: [email protected] # v5.12+ Cc: Anshuman Gupta Cc: Suraj Kandpal Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/[email protected] Signed-off-by: Jani Nikula (cherry picked from commit 9284ab3b6e776c315883ac2611283d263c9460fd) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d7bec2276b6069cf29ddbf0a224dfe461a79d8a3 Author: Jani Nikula Date: Sat Aug 1 23:25:22 2026 -0400 drm/i915/hdcp: require monotonically increasing seq_num_v [ Upstream commit db9e64c983dcb07ff256bd455f258c44aa530ff8 ] The HDCP 2.2 specification requires the seq_num_v to be monotonically increasing, and repeated seq_num_v needs to be treated as an integrity failure. Make it so. For the first message, seq_num_v must be zero, and is already checked. We can only check for less-than-or-equal for the subsequent messages, where hdcp2_encrypted is true. Discovered using AI-assisted static analysis confirmed by Intel Product Security. Reported-by: Martin Hodo Fixes: d849178e2c9e ("drm/i915: Implement HDCP2.2 repeater authentication") Cc: [email protected] # v5.2+ Cc: Suraj Kandpal Reviewed-by: Suraj Kandpal Link: https://patch.msgid.link/[email protected] Signed-off-by: Jani Nikula (cherry picked from commit 58a224375c81179b52558c53d8857b93196d2687) Signed-off-by: Joonas Lahtinen Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit 214b63a6df022660a200d659479cb713dc3f1fd2 Author: Suraj Kandpal Date: Sat Aug 1 23:25:21 2026 -0400 drm/i915/hdcp: Move to using intel_display in intel_hdcp [ Upstream commit e35bf8f6a0ff06ceeff15bb032351cd5d006f92b ] Move to using intel_display wherever possible in intel_hdcp.c as a part of code refactor. --v2 -Move intel_display to the first line wherever possible [Jani] -use the closest reference when using to_intel_display [Jani] Signed-off-by: Suraj Kandpal Reviewed-by: Jani Nikula Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Stable-dep-of: db9e64c983dc ("drm/i915/hdcp: require monotonically increasing seq_num_v") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d1ba0459d8d0c62998bbabe2e1dff2dd82a8e53e Author: Jani Nikula Date: Sat Aug 1 23:25:20 2026 -0400 drm/i915/hdcp: migrate away from kdev_to_i915() in bind/unbind [ Upstream commit 3eac4684ecb5ea696bd283bd7f35e4829973f4f8 ] Use to_intel_display() instead of kdev_to_i915() in the HDCP component API hooks. Avoid further drive-by changes at this point, and just convert the display pointer to i915, and leave the struct intel_display conversion for later. Reviewed-by: Gustavo Sousa Link: https://patchwork.freedesktop.org/patch/msgid/0beedaa438e912828b48d9980f017807e079d7ab.1724942754.git.jani.nikula@intel.com Signed-off-by: Jani Nikula Stable-dep-of: db9e64c983dc ("drm/i915/hdcp: require monotonically increasing seq_num_v") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit b02ed4c9099a603e25170d3e922e5fc8351bac39 Author: Ville Syrjälä Date: Sat Aug 1 23:25:19 2026 -0400 drm/i915/fbc: Extract intel_fbc_has_fences() [ Upstream commit bc34d310b578952d37b5200a7fa7475ab2a2bd5e ] Pull the "do we have fences?" check into a single helper in the FBC code. Avoids having to call to outside the display code in multiple places for this. Signed-off-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Rodrigo Vivi Stable-dep-of: db9e64c983dc ("drm/i915/hdcp: require monotonically increasing seq_num_v") Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit c6eb2d615210b80339548ab07c0230edaab9a6c7 Author: Zhiling Zou Date: Fri Aug 7 07:48:23 2026 -0400 sctp: close UDP tunnel sockets during netns teardown [ Upstream commit ffb2bd7ade36ec4da32c46a6eddbf4515316d08c ] proc_sctp_do_udp_port() starts per-net SCTP UDP tunneling sockets when net.sctp.udp_port is set, and stops/restarts them when the sysctl value changes. The netns exit path does not stop these sockets, so a namespace can be torn down while its SCTP UDP tunnel sockets are still installed. Close the UDP tunnel sockets from sctp_ctrlsock_exit() after unregistering the per-net sysctl table. This prevents new sysctl writes from racing in while the sockets are being released, and closes the sockets before the control socket is destroyed. Fixes: 046c052b475e ("sctp: enable udp tunneling socks") Cc: [email protected] Reported-by: Sashiko Closes: https://sashiko.dev/#/patchset/b9f1f02b0780ad6a719e2413f5f0bb8eb7702d94.1782585631.git.roxy520tt%40gmail.com Signed-off-by: Zhiling Zou Signed-off-by: Ren Wei Acked-by: Xin Long Link: https://patch.msgid.link/6dab75f22855cb219e2e30a5497cab03b970ab91.1784033357.git.roxy520tt@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman commit d2c3760b45f2f481a4dd4c5adef4a29dfabd948f Author: Geliang Tang Date: Fri Aug 7 07:48:13 2026 -0400 mptcp: pm: userspace: fix use-after-free in get_local_id [ Upstream commit 9bc6d5e4ca9f3cbb41d43400b3a31cb0403796c9 ] 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] [ 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: f012d796a6de ("mptcp: check addrs list in userspace_pm_get_local_id") Cc: [email protected] Signed-off-by: Geliang Tang Tested-by: Xuanqiang Luo Reviewed-by: Matthieu Baerts (NGI0) Signed-off-by: Matthieu Baerts (NGI0) Link: https://patch.msgid.link/[email protected]…