From: Greg Kroah-Hartman Date: Fri, 15 Jul 2022 13:35:00 +0000 (+0200) Subject: 4.9-stable patches X-Git-Tag: v4.9.324~55 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=f49156a7ba450d19584e00c74bf4f1334e457595;p=thirdparty%2Fkernel%2Fstable-queue.git 4.9-stable patches added patches: arm-9213-1-print-message-about-disabled-spectre-workarounds-only-once.patch net-sock-tracing-fix-sock_exceed_buf_limit-not-to-dereference-stale-pointer.patch nilfs2-fix-incorrect-masking-of-permission-flags-for-symlinks.patch xen-netback-avoid-entering-xenvif_rx_next_skb-with-an-empty-rx-queue.patch --- diff --git a/queue-4.9/arm-9213-1-print-message-about-disabled-spectre-workarounds-only-once.patch b/queue-4.9/arm-9213-1-print-message-about-disabled-spectre-workarounds-only-once.patch new file mode 100644 index 00000000000..161cbd147e4 --- /dev/null +++ b/queue-4.9/arm-9213-1-print-message-about-disabled-spectre-workarounds-only-once.patch @@ -0,0 +1,33 @@ +From e4ced82deb5fb17222fb82e092c3f8311955b585 Mon Sep 17 00:00:00 2001 +From: Dmitry Osipenko +Date: Tue, 28 Jun 2022 08:55:45 +0100 +Subject: ARM: 9213/1: Print message about disabled Spectre workarounds only once + +From: Dmitry Osipenko + +commit e4ced82deb5fb17222fb82e092c3f8311955b585 upstream. + +Print the message about disabled Spectre workarounds only once. The +message is printed each time CPU goes out from idling state on NVIDIA +Tegra boards, causing storm in KMSG that makes system unusable. + +Cc: stable@vger.kernel.org +Signed-off-by: Dmitry Osipenko +Signed-off-by: Russell King (Oracle) +Signed-off-by: Greg Kroah-Hartman +--- + arch/arm/mm/proc-v7-bugs.c | 3 +-- + 1 file changed, 1 insertion(+), 2 deletions(-) + +--- a/arch/arm/mm/proc-v7-bugs.c ++++ b/arch/arm/mm/proc-v7-bugs.c +@@ -110,8 +110,7 @@ static unsigned int spectre_v2_install_w + #else + static unsigned int spectre_v2_install_workaround(unsigned int method) + { +- pr_info("CPU%u: Spectre V2: workarounds disabled by configuration\n", +- smp_processor_id()); ++ pr_info_once("Spectre V2: workarounds disabled by configuration\n"); + + return SPECTRE_VULNERABLE; + } diff --git a/queue-4.9/net-sock-tracing-fix-sock_exceed_buf_limit-not-to-dereference-stale-pointer.patch b/queue-4.9/net-sock-tracing-fix-sock_exceed_buf_limit-not-to-dereference-stale-pointer.patch new file mode 100644 index 00000000000..f2c48b3d07b --- /dev/null +++ b/queue-4.9/net-sock-tracing-fix-sock_exceed_buf_limit-not-to-dereference-stale-pointer.patch @@ -0,0 +1,53 @@ +From 820b8963adaea34a87abbecb906d1f54c0aabfb7 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Wed, 6 Jul 2022 10:50:40 -0400 +Subject: net: sock: tracing: Fix sock_exceed_buf_limit not to dereference stale pointer + +From: Steven Rostedt (Google) + +commit 820b8963adaea34a87abbecb906d1f54c0aabfb7 upstream. + +The trace event sock_exceed_buf_limit saves the prot->sysctl_mem pointer +and then dereferences it in the TP_printk() portion. This is unsafe as the +TP_printk() portion is executed at the time the buffer is read. That is, +it can be seconds, minutes, days, months, even years later. If the proto +is freed, then this dereference will can also lead to a kernel crash. + +Instead, save the sysctl_mem array into the ring buffer and have the +TP_printk() reference that instead. This is the proper and safe way to +read pointers in trace events. + +Link: https://lore.kernel.org/all/20220706052130.16368-12-kuniyu@amazon.com/ + +Cc: stable@vger.kernel.org +Fixes: 3847ce32aea9f ("core: add tracepoints for queueing skb to rcvbuf") +Signed-off-by: Steven Rostedt (Google) +Acked-by: Kuniyuki Iwashima +Signed-off-by: David S. Miller +Signed-off-by: Greg Kroah-Hartman +--- + include/trace/events/sock.h | 6 ++++-- + 1 file changed, 4 insertions(+), 2 deletions(-) + +--- a/include/trace/events/sock.h ++++ b/include/trace/events/sock.h +@@ -37,7 +37,7 @@ TRACE_EVENT(sock_exceed_buf_limit, + + TP_STRUCT__entry( + __array(char, name, 32) +- __field(long *, sysctl_mem) ++ __array(long, sysctl_mem, 3) + __field(long, allocated) + __field(int, sysctl_rmem) + __field(int, rmem_alloc) +@@ -45,7 +45,9 @@ TRACE_EVENT(sock_exceed_buf_limit, + + TP_fast_assign( + strncpy(__entry->name, prot->name, 32); +- __entry->sysctl_mem = prot->sysctl_mem; ++ __entry->sysctl_mem[0] = READ_ONCE(prot->sysctl_mem[0]); ++ __entry->sysctl_mem[1] = READ_ONCE(prot->sysctl_mem[1]); ++ __entry->sysctl_mem[2] = READ_ONCE(prot->sysctl_mem[2]); + __entry->allocated = allocated; + __entry->sysctl_rmem = prot->sysctl_rmem[0]; + __entry->rmem_alloc = atomic_read(&sk->sk_rmem_alloc); diff --git a/queue-4.9/nilfs2-fix-incorrect-masking-of-permission-flags-for-symlinks.patch b/queue-4.9/nilfs2-fix-incorrect-masking-of-permission-flags-for-symlinks.patch new file mode 100644 index 00000000000..71162af962d --- /dev/null +++ b/queue-4.9/nilfs2-fix-incorrect-masking-of-permission-flags-for-symlinks.patch @@ -0,0 +1,45 @@ +From 5924e6ec1585445f251ea92713eb15beb732622a Mon Sep 17 00:00:00 2001 +From: Ryusuke Konishi +Date: Thu, 23 Jun 2022 17:54:01 +0900 +Subject: nilfs2: fix incorrect masking of permission flags for symlinks + +From: Ryusuke Konishi + +commit 5924e6ec1585445f251ea92713eb15beb732622a upstream. + +The permission flags of newly created symlinks are wrongly dropped on +nilfs2 with the current umask value even though symlinks should have 777 +(rwxrwxrwx) permissions: + + $ umask + 0022 + $ touch file && ln -s file symlink; ls -l file symlink + -rw-r--r--. 1 root root 0 Jun 23 16:29 file + lrwxr-xr-x. 1 root root 4 Jun 23 16:29 symlink -> file + +This fixes the bug by inserting a missing check that excludes +symlinks. + +Link: https://lkml.kernel.org/r/1655974441-5612-1-git-send-email-konishi.ryusuke@gmail.com +Signed-off-by: Ryusuke Konishi +Reported-by: Tommy Pettersson +Reported-by: Ciprian Craciun +Tested-by: Ryusuke Konishi +Signed-off-by: Andrew Morton +Signed-off-by: Greg Kroah-Hartman +--- + fs/nilfs2/nilfs.h | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/fs/nilfs2/nilfs.h ++++ b/fs/nilfs2/nilfs.h +@@ -212,6 +212,9 @@ static inline int nilfs_acl_chmod(struct + + static inline int nilfs_init_acl(struct inode *inode, struct inode *dir) + { ++ if (S_ISLNK(inode->i_mode)) ++ return 0; ++ + inode->i_mode &= ~current_umask(); + return 0; + } diff --git a/queue-4.9/series b/queue-4.9/series index 590736fb6b8..02e32546c5e 100644 --- a/queue-4.9/series +++ b/queue-4.9/series @@ -1,2 +1,6 @@ arm64-entry-restore-tramp_map_kernel-isb.patch alsa-hda-add-fixup-for-dell-latitidue-e5430.patch +xen-netback-avoid-entering-xenvif_rx_next_skb-with-an-empty-rx-queue.patch +net-sock-tracing-fix-sock_exceed_buf_limit-not-to-dereference-stale-pointer.patch +arm-9213-1-print-message-about-disabled-spectre-workarounds-only-once.patch +nilfs2-fix-incorrect-masking-of-permission-flags-for-symlinks.patch diff --git a/queue-4.9/xen-netback-avoid-entering-xenvif_rx_next_skb-with-an-empty-rx-queue.patch b/queue-4.9/xen-netback-avoid-entering-xenvif_rx_next_skb-with-an-empty-rx-queue.patch new file mode 100644 index 00000000000..995d47a20f6 --- /dev/null +++ b/queue-4.9/xen-netback-avoid-entering-xenvif_rx_next_skb-with-an-empty-rx-queue.patch @@ -0,0 +1,60 @@ +From 94e8100678889ab428e68acadf042de723f094b9 Mon Sep 17 00:00:00 2001 +From: Juergen Gross +Date: Wed, 13 Jul 2022 15:53:22 +0200 +Subject: xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue + +From: Juergen Gross + +commit 94e8100678889ab428e68acadf042de723f094b9 upstream. + +xenvif_rx_next_skb() is expecting the rx queue not being empty, but +in case the loop in xenvif_rx_action() is doing multiple iterations, +the availability of another skb in the rx queue is not being checked. + +This can lead to crashes: + +[40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080 +[40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback] +[40072.537534] PGD 0 P4D 0 +[40072.537644] Oops: 0000 [#1] SMP NOPTI +[40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5 +[40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021 +[40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000 +[40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback] +[40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246 +[40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7 +[40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8 +[40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008 +[40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708 +[40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0 +[40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000 +[40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 +[40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660 +[40072.539211] Call Trace: +[40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback] +[40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback] + +Fix that by stopping the loop in case the rx queue becomes empty. + +Cc: stable@vger.kernel.org +Fixes: 98f6d57ced73 ("xen-netback: process guest rx packets in batches") +Signed-off-by: Juergen Gross +Reviewed-by: Jan Beulich +Reviewed-by: Paul Durrant +Link: https://lore.kernel.org/r/20220713135322.19616-1-jgross@suse.com +Signed-off-by: Jakub Kicinski +Signed-off-by: Greg Kroah-Hartman +--- + drivers/net/xen-netback/rx.c | 1 + + 1 file changed, 1 insertion(+) + +--- a/drivers/net/xen-netback/rx.c ++++ b/drivers/net/xen-netback/rx.c +@@ -482,6 +482,7 @@ void xenvif_rx_action(struct xenvif_queu + queue->rx_copy.completed = &completed_skbs; + + while (xenvif_rx_ring_slots_available(queue) && ++ !skb_queue_empty(&queue->rx_queue) && + work_done < RX_BATCH_SIZE) { + xenvif_rx_skb(queue); + work_done++;