6.18-stable patches

added patches:
	platform-x86-hp-wmi-ignore-backlight-and-fnlock-events.patch
	vsock-virtio-fix-msg_peek-ignoring-skb-offset-when-calculating-bytes-to-copy.patch

diff --git a/queue-6.18/platform-x86-hp-wmi-ignore-backlight-and-fnlock-events.patch b/queue-6.18/platform-x86-hp-wmi-ignore-backlight-and-fnlock-events.patch
new file mode 100644 (file)
index 0000000..c9c5600
--- /dev/null
+++ b/queue-6.18/platform-x86-hp-wmi-ignore-backlight-and-fnlock-events.patch
@@ -0,0 +1,45 @@
+From e8c597368b8500a824c639bfb5ed0044068c6870 Mon Sep 17 00:00:00 2001
+From: Krishna Chomal <krishna.chomal108@gmail.com>
+Date: Fri, 3 Apr 2026 13:31:55 +0530
+Subject: platform/x86: hp-wmi: Ignore backlight and FnLock events
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Krishna Chomal <krishna.chomal108@gmail.com>
+
+commit e8c597368b8500a824c639bfb5ed0044068c6870 upstream.
+
+On HP OmniBook 7 the keyboard backlight and FnLock keys are handled
+directly by the firmware. However, they still trigger WMI events which
+results in "Unknown key code" warnings in dmesg.
+
+Add these key codes to the keymap with KE_IGNORE to silence the warnings
+since no software action is needed.
+
+Tested-by: Artem S. Tashkinov <aros@gmx.com>
+Reported-by: Artem S. Tashkinov <aros@gmx.com>
+Closes: https://bugzilla.kernel.org/show_bug.cgi?id=221181
+Signed-off-by: Krishna Chomal <krishna.chomal108@gmail.com>
+Link: https://patch.msgid.link/20260403080155.169653-1-krishna.chomal108@gmail.com
+Reviewed-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/platform/x86/hp/hp-wmi.c |    5 +++++
+ 1 file changed, 5 insertions(+)
+
+--- a/drivers/platform/x86/hp/hp-wmi.c
++++ b/drivers/platform/x86/hp/hp-wmi.c
+@@ -362,6 +362,11 @@ static const struct key_entry hp_wmi_key
+       { KE_KEY, 0x21a9,  { KEY_TOUCHPAD_OFF } },
+       { KE_KEY, 0x121a9, { KEY_TOUCHPAD_ON } },
+       { KE_KEY, 0x231b,  { KEY_HELP } },
++      { KE_IGNORE, 0x21ab, }, /* FnLock on */
++      { KE_IGNORE, 0x121ab, }, /* FnLock off */
++      { KE_IGNORE, 0x30021aa, }, /* kbd backlight: level 2 -> off */
++      { KE_IGNORE, 0x33221aa, }, /* kbd backlight: off -> level 1 */
++      { KE_IGNORE, 0x36421aa, }, /* kbd backlight: level 1 -> level 2*/
+       { KE_END, 0 }
+ };
+ 

diff --git a/queue-6.18/series b/queue-6.18/series
index e044693b375cae7e1c30936268278ccd0558dfe0..98377f7806642c5893fc6e87c386baea1d036981 100644 (file)
--- a/queue-6.18/series
+++ b/queue-6.18/series
@@ -42,3 +42,5 @@ spi-at91-usart-fix-controller-deregistration.patch
 media-saa7164-add-ioremap-return-checks-and-cleanups.patch
 spi-amlogic-spisg-fix-controller-deregistration.patch
 spi-aspeed-smc-fix-controller-deregistration.patch
+platform-x86-hp-wmi-ignore-backlight-and-fnlock-events.patch
+vsock-virtio-fix-msg_peek-ignoring-skb-offset-when-calculating-bytes-to-copy.patch

diff --git a/queue-6.18/vsock-virtio-fix-msg_peek-ignoring-skb-offset-when-calculating-bytes-to-copy.patch b/queue-6.18/vsock-virtio-fix-msg_peek-ignoring-skb-offset-when-calculating-bytes-to-copy.patch
new file mode 100644 (file)
index 0000000..42dd84b
--- /dev/null
+++ b/queue-6.18/vsock-virtio-fix-msg_peek-ignoring-skb-offset-when-calculating-bytes-to-copy.patch
@@ -0,0 +1,45 @@
+From 080f22f5d30233faf3d83be3098f35b8be9b7a00 Mon Sep 17 00:00:00 2001
+From: Luigi Leonardi <leonardi@redhat.com>
+Date: Wed, 15 Apr 2026 17:09:28 +0200
+Subject: vsock/virtio: fix MSG_PEEK ignoring skb offset when calculating bytes to copy
+
+From: Luigi Leonardi <leonardi@redhat.com>
+
+commit 080f22f5d30233faf3d83be3098f35b8be9b7a00 upstream.
+
+`virtio_transport_stream_do_peek()` does not account for the skb offset
+when computing the number of bytes to copy.
+
+This means that, after a partial recv() that advances the offset, a peek
+requesting more bytes than are available in the sk_buff causes
+`skb_copy_datagram_iter()` to go past the valid payload, resulting in
+a -EFAULT.
+
+The dequeue path already handles this correctly.
+Apply the same logic to the peek path.
+
+Fixes: 0df7cd3c13e4 ("vsock/virtio/vhost: read data from non-linear skb")
+Reviewed-by: Stefano Garzarella <sgarzare@redhat.com>
+Acked-by: Arseniy Krasnov <avkrasnov@salutedevices.com>
+Signed-off-by: Luigi Leonardi <leonardi@redhat.com>
+Link: https://patch.msgid.link/20260415-fix_peek-v4-1-8207e872759e@redhat.com
+Signed-off-by: Jakub Kicinski <kuba@kernel.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/vmw_vsock/virtio_transport_common.c |    5 ++---
+ 1 file changed, 2 insertions(+), 3 deletions(-)
+
+--- a/net/vmw_vsock/virtio_transport_common.c
++++ b/net/vmw_vsock/virtio_transport_common.c
+@@ -546,9 +546,8 @@ virtio_transport_stream_do_peek(struct v
+       skb_queue_walk(&vvs->rx_queue, skb) {
+               size_t bytes;
+ 
+-              bytes = len - total;
+-              if (bytes > skb->len)
+-                      bytes = skb->len;
++              bytes = min_t(size_t, len - total,
++                            skb->len - VIRTIO_VSOCK_SKB_CB(skb)->offset);
+ 
+               spin_unlock_bh(&vvs->rx_lock);
+