--- /dev/null
+From 49aadf830eb048134d33ad7329d92ecff45d8dbb Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 2 Jan 2026 12:14:10 +0100
+Subject: ASoC: codecs: wsa883x: fix unnecessary initialisation
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 49aadf830eb048134d33ad7329d92ecff45d8dbb upstream.
+
+The soundwire update_status() callback may be called multiple times with
+the same ATTACHED status but initialisation should only be done when
+transitioning from UNATTACHED to ATTACHED.
+
+This avoids repeated initialisation of the codecs during boot of
+machines like the Lenovo ThinkPad X13s:
+
+[ 11.614523] wsa883x-codec sdw:1:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2
+[ 11.618022] wsa883x-codec sdw:1:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2
+[ 11.621377] wsa883x-codec sdw:1:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2
+[ 11.624065] wsa883x-codec sdw:1:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2
+[ 11.631382] wsa883x-codec sdw:1:0:0217:0202:00:2: WSA883X Version 1_1, Variant: WSA8835_V2
+[ 11.634424] wsa883x-codec sdw:1:0:0217:0202:00:2: WSA883X Version 1_1, Variant: WSA8835_V2
+
+Fixes: 43b8c7dc85a1 ("ASoC: codecs: add wsa883x amplifier support")
+Cc: stable@vger.kernel.org # 6.0
+Cc: Srinivas Kandagatla <srini@kernel.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
+Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260102111413.9605-2-johan@kernel.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/codecs/wsa883x.c | 9 +++++++++
+ 1 file changed, 9 insertions(+)
+
+--- a/sound/soc/codecs/wsa883x.c
++++ b/sound/soc/codecs/wsa883x.c
+@@ -475,6 +475,7 @@ struct wsa883x_priv {
+ int active_ports;
+ int dev_mode;
+ int comp_offset;
++ bool hw_init;
+ /*
+ * Protects temperature reading code (related to speaker protection) and
+ * fields: temperature and pa_on.
+@@ -1043,6 +1044,9 @@ static int wsa883x_init(struct wsa883x_p
+ struct regmap *regmap = wsa883x->regmap;
+ int variant, version, ret;
+
++ if (wsa883x->hw_init)
++ return 0;
++
+ ret = regmap_read(regmap, WSA883X_OTP_REG_0, &variant);
+ if (ret)
+ return ret;
+@@ -1085,6 +1089,8 @@ static int wsa883x_init(struct wsa883x_p
+ wsa883x->comp_offset);
+ }
+
++ wsa883x->hw_init = true;
++
+ return 0;
+ }
+
+@@ -1093,6 +1099,9 @@ static int wsa883x_update_status(struct
+ {
+ struct wsa883x_priv *wsa883x = dev_get_drvdata(&slave->dev);
+
++ if (status == SDW_SLAVE_UNATTACHED)
++ wsa883x->hw_init = false;
++
+ if (status == SDW_SLAVE_ATTACHED && slave->dev_num > 0)
+ return wsa883x_init(wsa883x);
+
--- /dev/null
+From 120f3e6ff76209ee2f62a64e5e7e9d70274df42b Mon Sep 17 00:00:00 2001
+From: Johan Hovold <johan@kernel.org>
+Date: Fri, 2 Jan 2026 12:14:12 +0100
+Subject: ASoC: codecs: wsa884x: fix codec initialisation
+
+From: Johan Hovold <johan@kernel.org>
+
+commit 120f3e6ff76209ee2f62a64e5e7e9d70274df42b upstream.
+
+The soundwire update_status() callback may be called multiple times with
+the same ATTACHED status but initialisation should only be done when
+transitioning from UNATTACHED to ATTACHED.
+
+Fix the inverted hw_init flag which was set to false instead of true
+after initialisation which defeats its purpose and may result in
+repeated unnecessary initialisation.
+
+Similarly, the initial state of the flag was also inverted so that the
+codec would only be initialised and brought out of regmap cache only
+mode if its status first transitions to UNATTACHED.
+
+Fixes: aa21a7d4f68a ("ASoC: codecs: wsa884x: Add WSA884x family of speakers")
+Cc: stable@vger.kernel.org # 6.5
+Cc: Krzysztof Kozlowski <krzk@kernel.org>
+Signed-off-by: Johan Hovold <johan@kernel.org>
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
+Tested-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
+Reviewed-by: Srinivas Kandagatla <srinivas.kandagatla@oss.qualcomm.com>
+Link: https://patch.msgid.link/20260102111413.9605-4-johan@kernel.org
+Signed-off-by: Mark Brown <broonie@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ sound/soc/codecs/wsa884x.c | 3 +--
+ 1 file changed, 1 insertion(+), 2 deletions(-)
+
+--- a/sound/soc/codecs/wsa884x.c
++++ b/sound/soc/codecs/wsa884x.c
+@@ -1534,7 +1534,7 @@ static void wsa884x_init(struct wsa884x_
+
+ wsa884x_set_gain_parameters(wsa884x);
+
+- wsa884x->hw_init = false;
++ wsa884x->hw_init = true;
+ }
+
+ static int wsa884x_update_status(struct sdw_slave *slave,
+@@ -2109,7 +2109,6 @@ static int wsa884x_probe(struct sdw_slav
+
+ /* Start in cache-only until device is enumerated */
+ regcache_cache_only(wsa884x->regmap, true);
+- wsa884x->hw_init = true;
+
+ if (IS_REACHABLE(CONFIG_HWMON)) {
+ struct device *hwmon;
--- /dev/null
+From dc2d5ddb193e363187bae2ad358245642d2721fb Mon Sep 17 00:00:00 2001
+From: Shenghao Yang <me@shenghaoyang.info>
+Date: Wed, 31 Dec 2025 13:50:26 +0800
+Subject: drm/gud: fix NULL fb and crtc dereferences on USB disconnect
+
+From: Shenghao Yang <me@shenghaoyang.info>
+
+commit dc2d5ddb193e363187bae2ad358245642d2721fb upstream.
+
+On disconnect drm_atomic_helper_disable_all() is called which
+sets both the fb and crtc for a plane to NULL before invoking a commit.
+
+This causes a kernel oops on every display disconnect.
+
+Add guards for those dereferences.
+
+Cc: <stable@vger.kernel.org> # 6.18.x
+Fixes: 73cfd166e045 ("drm/gud: Replace simple display pipe with DRM atomic helpers")
+Signed-off-by: Shenghao Yang <me@shenghaoyang.info>
+Reviewed-by: Ruben Wauters <rubenru09@aol.com>
+Signed-off-by: Ruben Wauters <rubenru09@aol.com>
+Link: https://patch.msgid.link/20251231055039.44266-1-me@shenghaoyang.info
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/gpu/drm/gud/gud_pipe.c | 20 ++++++++------------
+ 1 file changed, 8 insertions(+), 12 deletions(-)
+
+diff --git a/drivers/gpu/drm/gud/gud_pipe.c b/drivers/gpu/drm/gud/gud_pipe.c
+index 76d77a736d84..4b77be94348d 100644
+--- a/drivers/gpu/drm/gud/gud_pipe.c
++++ b/drivers/gpu/drm/gud/gud_pipe.c
+@@ -457,27 +457,20 @@ int gud_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *old_plane_state = drm_atomic_get_old_plane_state(state, plane);
+ struct drm_plane_state *new_plane_state = drm_atomic_get_new_plane_state(state, plane);
+ struct drm_crtc *crtc = new_plane_state->crtc;
+- struct drm_crtc_state *crtc_state;
++ struct drm_crtc_state *crtc_state = NULL;
+ const struct drm_display_mode *mode;
+ struct drm_framebuffer *old_fb = old_plane_state->fb;
+ struct drm_connector_state *connector_state = NULL;
+ struct drm_framebuffer *fb = new_plane_state->fb;
+- const struct drm_format_info *format = fb->format;
++ const struct drm_format_info *format;
+ struct drm_connector *connector;
+ unsigned int i, num_properties;
+ struct gud_state_req *req;
+ int idx, ret;
+ size_t len;
+
+- if (drm_WARN_ON_ONCE(plane->dev, !fb))
+- return -EINVAL;
+-
+- if (drm_WARN_ON_ONCE(plane->dev, !crtc))
+- return -EINVAL;
+-
+- crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+-
+- mode = &crtc_state->mode;
++ if (crtc)
++ crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
+
+ ret = drm_atomic_helper_check_plane_state(new_plane_state, crtc_state,
+ DRM_PLANE_NO_SCALING,
+@@ -492,6 +485,9 @@ int gud_plane_atomic_check(struct drm_plane *plane,
+ if (old_plane_state->rotation != new_plane_state->rotation)
+ crtc_state->mode_changed = true;
+
++ mode = &crtc_state->mode;
++ format = fb->format;
++
+ if (old_fb && old_fb->format != format)
+ crtc_state->mode_changed = true;
+
+@@ -598,7 +594,7 @@ void gud_plane_atomic_update(struct drm_plane *plane,
+ struct drm_atomic_helper_damage_iter iter;
+ int ret, idx;
+
+- if (crtc->state->mode_changed || !crtc->state->enable) {
++ if (!crtc || crtc->state->mode_changed || !crtc->state->enable) {
+ cancel_work_sync(&gdrm->work);
+ mutex_lock(&gdrm->damage_lock);
+ if (gdrm->fb) {
+--
+2.52.0
+
--- /dev/null
+From da579f05ef0faada3559e7faddf761c75cdf85e1 Mon Sep 17 00:00:00 2001
+From: Ming Lei <ming.lei@redhat.com>
+Date: Wed, 14 Jan 2026 16:54:05 +0800
+Subject: io_uring: move local task_work in exit cancel loop
+
+From: Ming Lei <ming.lei@redhat.com>
+
+commit da579f05ef0faada3559e7faddf761c75cdf85e1 upstream.
+
+With IORING_SETUP_DEFER_TASKRUN, task work is queued to ctx->work_llist
+(local work) rather than the fallback list. During io_ring_exit_work(),
+io_move_task_work_from_local() was called once before the cancel loop,
+moving work from work_llist to fallback_llist.
+
+However, task work can be added to work_llist during the cancel loop
+itself. There are two cases:
+
+1) io_kill_timeouts() is called from io_uring_try_cancel_requests() to
+cancel pending timeouts, and it adds task work via io_req_queue_tw_complete()
+for each cancelled timeout:
+
+2) URING_CMD requests like ublk can be completed via
+io_uring_cmd_complete_in_task() from ublk_queue_rq() during canceling,
+given ublk request queue is only quiesced when canceling the 1st uring_cmd.
+
+Since io_allowed_defer_tw_run() returns false in io_ring_exit_work()
+(kworker != submitter_task), io_run_local_work() is never invoked,
+and the work_llist entries are never processed. This causes
+io_uring_try_cancel_requests() to loop indefinitely, resulting in
+100% CPU usage in kworker threads.
+
+Fix this by moving io_move_task_work_from_local() inside the cancel
+loop, ensuring any work on work_llist is moved to fallback before
+each cancel attempt.
+
+Cc: stable@vger.kernel.org
+Fixes: c0e0d6ba25f1 ("io_uring: add IORING_SETUP_DEFER_TASKRUN")
+Signed-off-by: Ming Lei <ming.lei@redhat.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/io_uring.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+--- a/io_uring/io_uring.c
++++ b/io_uring/io_uring.c
+@@ -3017,12 +3017,12 @@ static __cold void io_ring_exit_work(str
+ mutex_unlock(&ctx->uring_lock);
+ }
+
+- if (ctx->flags & IORING_SETUP_DEFER_TASKRUN)
+- io_move_task_work_from_local(ctx);
+-
+ /* The SQPOLL thread never reaches this path */
+- while (io_uring_try_cancel_requests(ctx, NULL, true, false))
++ do {
++ if (ctx->flags & IORING_SETUP_DEFER_TASKRUN)
++ io_move_task_work_from_local(ctx);
+ cond_resched();
++ } while (io_uring_try_cancel_requests(ctx, NULL, true, false));
+
+ if (ctx->sq_data) {
+ struct io_sq_data *sqd = ctx->sq_data;
--- /dev/null
+From 7d3fa7e954934fbda0a017ac1c305b7b10ecceef Mon Sep 17 00:00:00 2001
+From: Janne Grunau <j@jannau.net>
+Date: Wed, 31 Dec 2025 11:10:57 +0100
+Subject: nvme-apple: add "apple,t8103-nvme-ans2" as compatible
+
+From: Janne Grunau <j@jannau.net>
+
+commit 7d3fa7e954934fbda0a017ac1c305b7b10ecceef upstream.
+
+After discussion with the devicetree maintainers we agreed to not extend
+lists with the generic compatible "apple,nvme-ans2" anymore [1]. Add
+"apple,t8103-nvme-ans2" as fallback compatible as it is the SoC the
+driver and bindings were written for.
+
+[1]: https://lore.kernel.org/asahi/12ab93b7-1fc2-4ce0-926e-c8141cfe81bf@kernel.org/
+
+Cc: stable@vger.kernel.org # v6.18+
+Fixes: 5bd2927aceba ("nvme-apple: Add initial Apple SoC NVMe driver")
+Reviewed-by: Neal Gompa <neal@gompa.dev>
+Reviewed-by: Christoph Hellwig <hch@lst.de>
+Signed-off-by: Janne Grunau <j@jannau.net>
+Signed-off-by: Keith Busch <kbusch@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/nvme/host/apple.c | 1 +
+ 1 file changed, 1 insertion(+)
+
+--- a/drivers/nvme/host/apple.c
++++ b/drivers/nvme/host/apple.c
+@@ -1703,6 +1703,7 @@ static const struct apple_nvme_hw apple_
+
+ static const struct of_device_id apple_nvme_of_match[] = {
+ { .compatible = "apple,t8015-nvme-ans2", .data = &apple_nvme_t8015_hw },
++ { .compatible = "apple,t8103-nvme-ans2", .data = &apple_nvme_t8103_hw },
+ { .compatible = "apple,nvme-ans2", .data = &apple_nvme_t8103_hw },
+ {},
+ };
--- /dev/null
+From 469d71512d135907bf5ea0972dfab8c420f57848 Mon Sep 17 00:00:00 2001
+From: Andreas Gruenbacher <agruenba@redhat.com>
+Date: Mon, 12 Jan 2026 11:47:35 +0100
+Subject: Revert "gfs2: Fix use of bio_chain"
+
+From: Andreas Gruenbacher <agruenba@redhat.com>
+
+commit 469d71512d135907bf5ea0972dfab8c420f57848 upstream.
+
+This reverts commit 8a157e0a0aa5143b5d94201508c0ca1bb8cfb941.
+
+That commit incorrectly assumed that the bio_chain() arguments were
+swapped in gfs2. However, gfs2 intentionally constructs bio chains so
+that the first bio's bi_end_io callback is invoked when all bios in the
+chain have completed, unlike bio chains where the last bio's callback is
+invoked.
+
+Fixes: 8a157e0a0aa5 ("gfs2: Fix use of bio_chain")
+Cc: stable@vger.kernel.org
+Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ fs/gfs2/lops.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+--- a/fs/gfs2/lops.c
++++ b/fs/gfs2/lops.c
+@@ -487,7 +487,7 @@ static struct bio *gfs2_chain_bio(struct
+ new = bio_alloc(prev->bi_bdev, nr_iovecs, prev->bi_opf, GFP_NOIO);
+ bio_clone_blkg_association(new, prev);
+ new->bi_iter.bi_sector = bio_end_sector(prev);
+- bio_chain(prev, new);
++ bio_chain(new, prev);
+ submit_bio(prev);
+ return new;
+ }
--- /dev/null
+From 6a069876eb1402478900ee0eb7d7fe276bb1f4e3 Mon Sep 17 00:00:00 2001
+From: Alice Ryhl <aliceryhl@google.com>
+Date: Mon, 5 Jan 2026 10:44:06 +0000
+Subject: rust: bitops: fix missing _find_* functions on 32-bit ARM
+
+From: Alice Ryhl <aliceryhl@google.com>
+
+commit 6a069876eb1402478900ee0eb7d7fe276bb1f4e3 upstream.
+
+On 32-bit ARM, you may encounter linker errors such as this one:
+
+ ld.lld: error: undefined symbol: _find_next_zero_bit
+ >>> referenced by rust_binder_main.43196037ba7bcee1-cgu.0
+ >>> drivers/android/binder/rust_binder_main.o:(<rust_binder_main::process::Process>::insert_or_update_handle) in archive vmlinux.a
+ >>> referenced by rust_binder_main.43196037ba7bcee1-cgu.0
+ >>> drivers/android/binder/rust_binder_main.o:(<rust_binder_main::process::Process>::insert_or_update_handle) in archive vmlinux.a
+
+This error occurs because even though the functions are declared by
+include/linux/find.h, the definition is #ifdef'd out on 32-bit ARM. This
+is because arch/arm/include/asm/bitops.h contains:
+
+ #define find_first_zero_bit(p,sz) _find_first_zero_bit_le(p,sz)
+ #define find_next_zero_bit(p,sz,off) _find_next_zero_bit_le(p,sz,off)
+ #define find_first_bit(p,sz) _find_first_bit_le(p,sz)
+ #define find_next_bit(p,sz,off) _find_next_bit_le(p,sz,off)
+
+And the underscore-prefixed function is conditional on #ifndef of the
+non-underscore-prefixed name, but the declaration in find.h is *not*
+conditional on that #ifndef.
+
+To fix the linker error, we ensure that the symbols in question exist
+when compiling Rust code. We do this by defining them in rust/helpers/
+whenever the normal definition is #ifndef'd out.
+
+Note that these helpers are somewhat unusual in that they do not have
+the rust_helper_ prefix that most helpers have. Adding the rust_helper_
+prefix does not compile, as 'bindings::_find_next_zero_bit()' will
+result in a call to a symbol called _find_next_zero_bit as defined by
+include/linux/find.h rather than a symbol with the rust_helper_ prefix.
+This is because when a symbol is present in both include/ and
+rust/helpers/, the one from include/ wins under the assumption that the
+current configuration is one where that helper is unnecessary. This
+heuristic fails for _find_next_zero_bit() because the header file always
+declares it even if the symbol does not exist.
+
+The functions still use the __rust_helper annotation. This lets the
+wrapper function be inlined into Rust code even if full kernel LTO is
+not used once the patch series for that feature lands.
+
+Yury: arches are free to implement they own find_bit() functions. Most
+rely on generic implementation, but arm32 and m86k - not; so they require
+custom handling. Alice confirmed it fixes the build for both.
+
+Cc: stable@vger.kernel.org
+Fixes: 6cf93a9ed39e ("rust: add bindings for bitops.h")
+Reported-by: Andreas Hindborg <a.hindborg@kernel.org>
+Closes: https://rust-for-linux.zulipchat.com/#narrow/channel/x/topic/x/near/561677301
+Tested-by: Andreas Hindborg <a.hindborg@kernel.org>
+Reviewed-by: Dirk Behme <dirk.behme@de.bosch.com>
+Signed-off-by: Alice Ryhl <aliceryhl@google.com>
+Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ rust/helpers/bitops.c | 42 ++++++++++++++++++++++++++++++++++++++++++
+ 1 file changed, 42 insertions(+)
+
+diff --git a/rust/helpers/bitops.c b/rust/helpers/bitops.c
+index 5d0861d29d3f..e79ef9e6d98f 100644
+--- a/rust/helpers/bitops.c
++++ b/rust/helpers/bitops.c
+@@ -1,6 +1,7 @@
+ // SPDX-License-Identifier: GPL-2.0
+
+ #include <linux/bitops.h>
++#include <linux/find.h>
+
+ void rust_helper___set_bit(unsigned long nr, unsigned long *addr)
+ {
+@@ -21,3 +22,44 @@ void rust_helper_clear_bit(unsigned long nr, volatile unsigned long *addr)
+ {
+ clear_bit(nr, addr);
+ }
++
++/*
++ * The rust_helper_ prefix is intentionally omitted below so that the
++ * declarations in include/linux/find.h are compatible with these helpers.
++ *
++ * Note that the below #ifdefs mean that the helper is only created if C does
++ * not provide a definition.
++ */
++#ifdef find_first_zero_bit
++__rust_helper
++unsigned long _find_first_zero_bit(const unsigned long *p, unsigned long size)
++{
++ return find_first_zero_bit(p, size);
++}
++#endif /* find_first_zero_bit */
++
++#ifdef find_next_zero_bit
++__rust_helper
++unsigned long _find_next_zero_bit(const unsigned long *addr,
++ unsigned long size, unsigned long offset)
++{
++ return find_next_zero_bit(addr, size, offset);
++}
++#endif /* find_next_zero_bit */
++
++#ifdef find_first_bit
++__rust_helper
++unsigned long _find_first_bit(const unsigned long *addr, unsigned long size)
++{
++ return find_first_bit(addr, size);
++}
++#endif /* find_first_bit */
++
++#ifdef find_next_bit
++__rust_helper
++unsigned long _find_next_bit(const unsigned long *addr, unsigned long size,
++ unsigned long offset)
++{
++ return find_next_bit(addr, size, offset);
++}
++#endif /* find_next_bit */
+--
+2.52.0
+
firmware-imx-scu-irq-set-mu_resource_id-before-get-handle.patch
efi-cper-fix-cper_bits_to_str-buffer-handling-and-return-value.patch
+nvme-apple-add-apple-t8103-nvme-ans2-as-compatible.patch
+revert-gfs2-fix-use-of-bio_chain.patch
+x86-fpu-clear-xstate_bv-in-guest-xsave-state-whenever-xfd-1.patch
+rust-bitops-fix-missing-_find_-functions-on-32-bit-arm.patch
+asoc-codecs-wsa884x-fix-codec-initialisation.patch
+asoc-codecs-wsa883x-fix-unnecessary-initialisation.patch
+drm-gud-fix-null-fb-and-crtc-dereferences-on-usb-disconnect.patch
+virtio_net-fix-misalignment-bug-in-struct-virtnet_info.patch
+io_uring-move-local-task_work-in-exit-cancel-loop.patch
--- /dev/null
+From 4156c3745f06bc197094b9ee97a9584e69ed00bf Mon Sep 17 00:00:00 2001
+From: "Gustavo A. R. Silva" <gustavoars@kernel.org>
+Date: Sat, 10 Jan 2026 17:07:17 +0900
+Subject: virtio_net: Fix misalignment bug in struct virtnet_info
+
+From: Gustavo A. R. Silva <gustavoars@kernel.org>
+
+commit 4156c3745f06bc197094b9ee97a9584e69ed00bf upstream.
+
+Use the new TRAILING_OVERLAP() helper to fix a misalignment bug
+along with the following warning:
+
+drivers/net/virtio_net.c:429:46: warning: structure containing a flexible array member is not at the end of another structure [-Wflex-array-member-not-at-end]
+
+This helper creates a union between a flexible-array member (FAM)
+and a set of members that would otherwise follow it (in this case
+`u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];`). This
+overlays the trailing members (rss_hash_key_data) onto the FAM
+(hash_key_data) while keeping the FAM and the start of MEMBERS aligned.
+The static_assert() ensures this alignment remains.
+
+Notice that due to tail padding in flexible `struct
+virtio_net_rss_config_trailer`, `rss_trailer.hash_key_data`
+(at offset 83 in struct virtnet_info) and `rss_hash_key_data` (at
+offset 84 in struct virtnet_info) are misaligned by one byte. See
+below:
+
+struct virtio_net_rss_config_trailer {
+ __le16 max_tx_vq; /* 0 2 */
+ __u8 hash_key_length; /* 2 1 */
+ __u8 hash_key_data[]; /* 3 0 */
+
+ /* size: 4, cachelines: 1, members: 3 */
+ /* padding: 1 */
+ /* last cacheline: 4 bytes */
+};
+
+struct virtnet_info {
+...
+ struct virtio_net_rss_config_trailer rss_trailer; /* 80 4 */
+
+ /* XXX last struct has 1 byte of padding */
+
+ u8 rss_hash_key_data[40]; /* 84 40 */
+...
+ /* size: 832, cachelines: 13, members: 48 */
+ /* sum members: 801, holes: 8, sum holes: 31 */
+ /* paddings: 2, sum paddings: 5 */
+};
+
+After changes, those members are correctly aligned at offset 795:
+
+struct virtnet_info {
+...
+ union {
+ struct virtio_net_rss_config_trailer rss_trailer; /* 792 4 */
+ struct {
+ unsigned char __offset_to_hash_key_data[3]; /* 792 3 */
+ u8 rss_hash_key_data[40]; /* 795 40 */
+ }; /* 792 43 */
+ }; /* 792 44 */
+...
+ /* size: 840, cachelines: 14, members: 47 */
+ /* sum members: 801, holes: 8, sum holes: 35 */
+ /* padding: 4 */
+ /* paddings: 1, sum paddings: 4 */
+ /* last cacheline: 8 bytes */
+};
+
+As a result, the RSS key passed to the device is shifted by 1
+byte: the last byte is cut off, and instead a (possibly
+uninitialized) byte is added at the beginning.
+
+As a last note `struct virtio_net_rss_config_hdr *rss_hdr;` is also
+moved to the end, since it seems those three members should stick
+around together. :)
+
+Cc: stable@vger.kernel.org
+Fixes: ed3100e90d0d ("virtio_net: Use new RSS config structs")
+Signed-off-by: Gustavo A. R. Silva <gustavoars@kernel.org>
+Acked-by: Michael S. Tsirkin <mst@redhat.com>
+Link: https://patch.msgid.link/aWIItWq5dV9XTTCJ@kspp
+Signed-off-by: Paolo Abeni <pabeni@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/net/virtio_net.c | 12 +++++++++---
+ 1 file changed, 9 insertions(+), 3 deletions(-)
+
+--- a/drivers/net/virtio_net.c
++++ b/drivers/net/virtio_net.c
+@@ -425,9 +425,6 @@ struct virtnet_info {
+ u16 rss_indir_table_size;
+ u32 rss_hash_types_supported;
+ u32 rss_hash_types_saved;
+- struct virtio_net_rss_config_hdr *rss_hdr;
+- struct virtio_net_rss_config_trailer rss_trailer;
+- u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];
+
+ /* Has control virtqueue */
+ bool has_cvq;
+@@ -493,7 +490,16 @@ struct virtnet_info {
+ struct failover *failover;
+
+ u64 device_stats_cap;
++
++ struct virtio_net_rss_config_hdr *rss_hdr;
++
++ /* Must be last as it ends in a flexible-array member. */
++ TRAILING_OVERLAP(struct virtio_net_rss_config_trailer, rss_trailer, hash_key_data,
++ u8 rss_hash_key_data[VIRTIO_NET_RSS_MAX_KEY_SIZE];
++ );
+ };
++static_assert(offsetof(struct virtnet_info, rss_trailer.hash_key_data) ==
++ offsetof(struct virtnet_info, rss_hash_key_data));
+
+ struct padded_vnet_hdr {
+ struct virtio_net_hdr_v1_hash hdr;
--- /dev/null
+From b45f721775947a84996deb5c661602254ce25ce6 Mon Sep 17 00:00:00 2001
+From: Sean Christopherson <seanjc@google.com>
+Date: Wed, 31 Dec 2025 16:43:15 +0100
+Subject: x86/fpu: Clear XSTATE_BV[i] in guest XSAVE state whenever XFD[i]=1
+
+From: Sean Christopherson <seanjc@google.com>
+
+commit b45f721775947a84996deb5c661602254ce25ce6 upstream.
+
+When loading guest XSAVE state via KVM_SET_XSAVE, and when updating XFD in
+response to a guest WRMSR, clear XFD-disabled features in the saved (or to
+be restored) XSTATE_BV to ensure KVM doesn't attempt to load state for
+features that are disabled via the guest's XFD. Because the kernel
+executes XRSTOR with the guest's XFD, saving XSTATE_BV[i]=1 with XFD[i]=1
+will cause XRSTOR to #NM and panic the kernel.
+
+E.g. if fpu_update_guest_xfd() sets XFD without clearing XSTATE_BV:
+
+ ------------[ cut here ]------------
+ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#29: amx_test/848
+ Modules linked in: kvm_intel kvm irqbypass
+ CPU: 29 UID: 1000 PID: 848 Comm: amx_test Not tainted 6.19.0-rc2-ffa07f7fd437-x86_amx_nm_xfd_non_init-vm #171 NONE
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+ RIP: 0010:exc_device_not_available+0x101/0x110
+ Call Trace:
+ <TASK>
+ asm_exc_device_not_available+0x1a/0x20
+ RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90
+ switch_fpu_return+0x4a/0xb0
+ kvm_arch_vcpu_ioctl_run+0x1245/0x1e40 [kvm]
+ kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]
+ __x64_sys_ioctl+0x8f/0xd0
+ do_syscall_64+0x62/0x940
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+ </TASK>
+ ---[ end trace 0000000000000000 ]---
+
+This can happen if the guest executes WRMSR(MSR_IA32_XFD) to set XFD[18] = 1,
+and a host IRQ triggers kernel_fpu_begin() prior to the vmexit handler's
+call to fpu_update_guest_xfd().
+
+and if userspace stuffs XSTATE_BV[i]=1 via KVM_SET_XSAVE:
+
+ ------------[ cut here ]------------
+ WARNING: arch/x86/kernel/traps.c:1524 at exc_device_not_available+0x101/0x110, CPU#14: amx_test/867
+ Modules linked in: kvm_intel kvm irqbypass
+ CPU: 14 UID: 1000 PID: 867 Comm: amx_test Not tainted 6.19.0-rc2-2dace9faccd6-x86_amx_nm_xfd_non_init-vm #168 NONE
+ Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
+ RIP: 0010:exc_device_not_available+0x101/0x110
+ Call Trace:
+ <TASK>
+ asm_exc_device_not_available+0x1a/0x20
+ RIP: 0010:restore_fpregs_from_fpstate+0x36/0x90
+ fpu_swap_kvm_fpstate+0x6b/0x120
+ kvm_load_guest_fpu+0x30/0x80 [kvm]
+ kvm_arch_vcpu_ioctl_run+0x85/0x1e40 [kvm]
+ kvm_vcpu_ioctl+0x2c3/0x8f0 [kvm]
+ __x64_sys_ioctl+0x8f/0xd0
+ do_syscall_64+0x62/0x940
+ entry_SYSCALL_64_after_hwframe+0x4b/0x53
+ </TASK>
+ ---[ end trace 0000000000000000 ]---
+
+The new behavior is consistent with the AMX architecture. Per Intel's SDM,
+XSAVE saves XSTATE_BV as '0' for components that are disabled via XFD
+(and non-compacted XSAVE saves the initial configuration of the state
+component):
+
+ If XSAVE, XSAVEC, XSAVEOPT, or XSAVES is saving the state component i,
+ the instruction does not generate #NM when XCR0[i] = IA32_XFD[i] = 1;
+ instead, it operates as if XINUSE[i] = 0 (and the state component was
+ in its initial state): it saves bit i of XSTATE_BV field of the XSAVE
+ header as 0; in addition, XSAVE saves the initial configuration of the
+ state component (the other instructions do not save state component i).
+
+Alternatively, KVM could always do XRSTOR with XFD=0, e.g. by using
+a constant XFD based on the set of enabled features when XSAVEing for
+a struct fpu_guest. However, having XSTATE_BV[i]=1 for XFD-disabled
+features can only happen in the above interrupt case, or in similar
+scenarios involving preemption on preemptible kernels, because
+fpu_swap_kvm_fpstate()'s call to save_fpregs_to_fpstate() saves the
+outgoing FPU state with the current XFD; and that is (on all but the
+first WRMSR to XFD) the guest XFD.
+
+Therefore, XFD can only go out of sync with XSTATE_BV in the above
+interrupt case, or in similar scenarios involving preemption on
+preemptible kernels, and it we can consider it (de facto) part of KVM
+ABI that KVM_GET_XSAVE returns XSTATE_BV[i]=0 for XFD-disabled features.
+
+Reported-by: Paolo Bonzini <pbonzini@redhat.com>
+Cc: stable@vger.kernel.org
+Fixes: 820a6ee944e7 ("kvm: x86: Add emulation for IA32_XFD", 2022-01-14)
+Signed-off-by: Sean Christopherson <seanjc@google.com>
+[Move clearing of XSTATE_BV from fpu_copy_uabi_to_guest_fpstate
+ to kvm_vcpu_ioctl_x86_set_xsave. - Paolo]
+Reviewed-by: Binbin Wu <binbin.wu@linux.intel.com>
+Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ arch/x86/kernel/fpu/core.c | 32 +++++++++++++++++++++++++++++---
+ arch/x86/kvm/x86.c | 9 +++++++++
+ 2 files changed, 38 insertions(+), 3 deletions(-)
+
+--- a/arch/x86/kernel/fpu/core.c
++++ b/arch/x86/kernel/fpu/core.c
+@@ -318,10 +318,29 @@ EXPORT_SYMBOL_GPL(fpu_enable_guest_xfd_f
+ #ifdef CONFIG_X86_64
+ void fpu_update_guest_xfd(struct fpu_guest *guest_fpu, u64 xfd)
+ {
++ struct fpstate *fpstate = guest_fpu->fpstate;
++
+ fpregs_lock();
+- guest_fpu->fpstate->xfd = xfd;
+- if (guest_fpu->fpstate->in_use)
+- xfd_update_state(guest_fpu->fpstate);
++
++ /*
++ * KVM's guest ABI is that setting XFD[i]=1 *can* immediately revert the
++ * save state to its initial configuration. Likewise, KVM_GET_XSAVE does
++ * the same as XSAVE and returns XSTATE_BV[i]=0 whenever XFD[i]=1.
++ *
++ * If the guest's FPU state is in hardware, just update XFD: the XSAVE
++ * in fpu_swap_kvm_fpstate will clear XSTATE_BV[i] whenever XFD[i]=1.
++ *
++ * If however the guest's FPU state is NOT resident in hardware, clear
++ * disabled components in XSTATE_BV now, or a subsequent XRSTOR will
++ * attempt to load disabled components and generate #NM _in the host_.
++ */
++ if (xfd && test_thread_flag(TIF_NEED_FPU_LOAD))
++ fpstate->regs.xsave.header.xfeatures &= ~xfd;
++
++ fpstate->xfd = xfd;
++ if (fpstate->in_use)
++ xfd_update_state(fpstate);
++
+ fpregs_unlock();
+ }
+ EXPORT_SYMBOL_GPL(fpu_update_guest_xfd);
+@@ -430,6 +449,13 @@ int fpu_copy_uabi_to_guest_fpstate(struc
+ return -EINVAL;
+
+ /*
++ * Disabled features must be in their initial state, otherwise XRSTOR
++ * causes an exception.
++ */
++ if (WARN_ON_ONCE(ustate->xsave.header.xfeatures & kstate->xfd))
++ return -EINVAL;
++
++ /*
+ * Nullify @vpkru to preserve its current value if PKRU's bit isn't set
+ * in the header. KVM's odd ABI is to leave PKRU untouched in this
+ * case (all other components are eventually re-initialized).
+--- a/arch/x86/kvm/x86.c
++++ b/arch/x86/kvm/x86.c
+@@ -5842,9 +5842,18 @@ static int kvm_vcpu_ioctl_x86_get_xsave(
+ static int kvm_vcpu_ioctl_x86_set_xsave(struct kvm_vcpu *vcpu,
+ struct kvm_xsave *guest_xsave)
+ {
++ union fpregs_state *xstate = (union fpregs_state *)guest_xsave->region;
++
+ if (fpstate_is_confidential(&vcpu->arch.guest_fpu))
+ return vcpu->kvm->arch.has_protected_state ? -EINVAL : 0;
+
++ /*
++ * For backwards compatibility, do not expect disabled features to be in
++ * their initial state. XSTATE_BV[i] must still be cleared whenever
++ * XFD[i]=1, or XRSTOR would cause a #NM.
++ */
++ xstate->xsave.header.xfeatures &= ~vcpu->arch.guest_fpu.fpstate->xfd;
++
+ return fpu_copy_uabi_to_guest_fpstate(&vcpu->arch.guest_fpu,
+ guest_xsave->region,
+ kvm_caps.supported_xcr0,
projects / thirdparty / kernel / stable-queue.git / commitdiff
