From: Greg Kroah-Hartman Date: Sun, 14 Apr 2024 13:42:46 +0000 (+0200) Subject: 5.4-stable patches X-Git-Tag: v5.15.156~65 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=bfc63b4022eb47122703afe48b00eeeb81c6f70e;p=thirdparty%2Fkernel%2Fstable-queue.git 5.4-stable patches added patches: batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch series --- diff --git a/queue-5.4/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch b/queue-5.4/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch new file mode 100644 index 00000000000..0843bd97898 --- /dev/null +++ b/queue-5.4/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch @@ -0,0 +1,68 @@ +From b1f532a3b1e6d2e5559c7ace49322922637a28aa Mon Sep 17 00:00:00 2001 +From: Sven Eckelmann +Date: Mon, 12 Feb 2024 13:58:33 +0100 +Subject: batman-adv: Avoid infinite loop trying to resize local TT + +From: Sven Eckelmann + +commit b1f532a3b1e6d2e5559c7ace49322922637a28aa upstream. + +If the MTU of one of an attached interface becomes too small to transmit +the local translation table then it must be resized to fit inside all +fragments (when enabled) or a single packet. + +But if the MTU becomes too low to transmit even the header + the VLAN +specific part then the resizing of the local TT will never succeed. This +can for example happen when the usable space is 110 bytes and 11 VLANs are +on top of batman-adv. In this case, at least 116 byte would be needed. +There will just be an endless spam of + + batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110) + +in the log but the function will never finish. Problem here is that the +timeout will be halved all the time and will then stagnate at 0 and +therefore never be able to reduce the table even more. + +There are other scenarios possible with a similar result. The number of +BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too +high to fit inside a packet. Such a scenario can therefore happen also with +only a single VLAN + 7 non-purgable addresses - requiring at least 120 +bytes. + +While this should be handled proactively when: + +* interface with too low MTU is added +* VLAN is added +* non-purgeable local mac is added +* MTU of an attached interface is reduced +* fragmentation setting gets disabled (which most likely requires dropping + attached interfaces) + +not all of these scenarios can be prevented because batman-adv is only +consuming events without the the possibility to prevent these actions +(non-purgable MAC address added, MTU of an attached interface is reduced). +It is therefore necessary to also make sure that the code is able to handle +also the situations when there were already incompatible system +configuration are present. + +Cc: stable@vger.kernel.org +Fixes: a19d3d85e1b8 ("batman-adv: limit local translation table max size") +Reported-by: syzbot+a6a4b5bb3da165594cff@syzkaller.appspotmail.com +Signed-off-by: Sven Eckelmann +Signed-off-by: Simon Wunderlich +Signed-off-by: Greg Kroah-Hartman +--- + net/batman-adv/translation-table.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/net/batman-adv/translation-table.c ++++ b/net/batman-adv/translation-table.c +@@ -4190,7 +4190,7 @@ void batadv_tt_local_resize_to_mtu(struc + + spin_lock_bh(&bat_priv->tt.commit_lock); + +- while (true) { ++ while (timeout) { + table_size = batadv_tt_local_table_transmit_size(bat_priv); + if (packet_size_max >= table_size) + break; diff --git a/queue-5.4/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch b/queue-5.4/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch new file mode 100644 index 00000000000..a569154edc4 --- /dev/null +++ b/queue-5.4/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch @@ -0,0 +1,37 @@ +From 45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810 Mon Sep 17 00:00:00 2001 +From: Dmitry Antipov +Date: Tue, 2 Apr 2024 14:32:05 +0300 +Subject: Bluetooth: Fix memory leak in hci_req_sync_complete() + +From: Dmitry Antipov + +commit 45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810 upstream. + +In 'hci_req_sync_complete()', always free the previous sync +request state before assigning reference to a new one. + +Reported-by: syzbot+39ec16ff6cc18b1d066d@syzkaller.appspotmail.com +Closes: https://syzkaller.appspot.com/bug?extid=39ec16ff6cc18b1d066d +Cc: stable@vger.kernel.org +Fixes: f60cb30579d3 ("Bluetooth: Convert hci_req_sync family of function to new request API") +Signed-off-by: Dmitry Antipov +Signed-off-by: Luiz Augusto von Dentz +Signed-off-by: Greg Kroah-Hartman +--- + net/bluetooth/hci_request.c | 4 +++- + 1 file changed, 3 insertions(+), 1 deletion(-) + +--- a/net/bluetooth/hci_request.c ++++ b/net/bluetooth/hci_request.c +@@ -107,8 +107,10 @@ static void hci_req_sync_complete(struct + if (hdev->req_status == HCI_REQ_PEND) { + hdev->req_result = result; + hdev->req_status = HCI_REQ_DONE; +- if (skb) ++ if (skb) { ++ kfree_skb(hdev->req_skb); + hdev->req_skb = skb_get(skb); ++ } + wake_up_interruptible(&hdev->req_wait_q); + } + } diff --git a/queue-5.4/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch b/queue-5.4/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch new file mode 100644 index 00000000000..73eefd6dd59 --- /dev/null +++ b/queue-5.4/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch @@ -0,0 +1,83 @@ +From ffe3986fece696cf65e0ef99e74c75f848be8e30 Mon Sep 17 00:00:00 2001 +From: "Steven Rostedt (Google)" +Date: Tue, 9 Apr 2024 15:13:09 -0400 +Subject: ring-buffer: Only update pages_touched when a new page is touched + +From: Steven Rostedt (Google) + +commit ffe3986fece696cf65e0ef99e74c75f848be8e30 upstream. + +The "buffer_percent" logic that is used by the ring buffer splice code to +only wake up the tasks when there's no data after the buffer is filled to +the percentage of the "buffer_percent" file is dependent on three +variables that determine the amount of data that is in the ring buffer: + + 1) pages_read - incremented whenever a new sub-buffer is consumed + 2) pages_lost - incremented every time a writer overwrites a sub-buffer + 3) pages_touched - incremented when a write goes to a new sub-buffer + +The percentage is the calculation of: + + (pages_touched - (pages_lost + pages_read)) / nr_pages + +Basically, the amount of data is the total number of sub-bufs that have been +touched, minus the number of sub-bufs lost and sub-bufs consumed. This is +divided by the total count to give the buffer percentage. When the +percentage is greater than the value in the "buffer_percent" file, it +wakes up splice readers waiting for that amount. + +It was observed that over time, the amount read from the splice was +constantly decreasing the longer the trace was running. That is, if one +asked for 60%, it would read over 60% when it first starts tracing, but +then it would be woken up at under 60% and would slowly decrease the +amount of data read after being woken up, where the amount becomes much +less than the buffer percent. + +This was due to an accounting of the pages_touched incrementation. This +value is incremented whenever a writer transfers to a new sub-buffer. But +the place where it was incremented was incorrect. If a writer overflowed +the current sub-buffer it would go to the next one. If it gets preempted +by an interrupt at that time, and the interrupt performs a trace, it too +will end up going to the next sub-buffer. But only one should increment +the counter. Unfortunately, that was not the case. + +Change the cmpxchg() that does the real switch of the tail-page into a +try_cmpxchg(), and on success, perform the increment of pages_touched. This +will only increment the counter once for when the writer moves to a new +sub-buffer, and not when there's a race and is incremented for when a +writer and its preempting writer both move to the same new sub-buffer. + +Link: https://lore.kernel.org/linux-trace-kernel/20240409151309.0d0e5056@gandalf.local.home + +Cc: stable@vger.kernel.org +Cc: Mathieu Desnoyers +Fixes: 2c2b0a78b3739 ("ring-buffer: Add percentage of ring buffer full to wake up reader") +Acked-by: Masami Hiramatsu (Google) +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/ring_buffer.c | 6 +++--- + 1 file changed, 3 insertions(+), 3 deletions(-) + +--- a/kernel/trace/ring_buffer.c ++++ b/kernel/trace/ring_buffer.c +@@ -1163,7 +1163,6 @@ static void rb_tail_page_update(struct r + old_write = local_add_return(RB_WRITE_INTCNT, &next_page->write); + old_entries = local_add_return(RB_WRITE_INTCNT, &next_page->entries); + +- local_inc(&cpu_buffer->pages_touched); + /* + * Just make sure we have seen our old_write and synchronize + * with any interrupts that come in. +@@ -1200,8 +1199,9 @@ static void rb_tail_page_update(struct r + */ + local_set(&next_page->page->commit, 0); + +- /* Again, either we update tail_page or an interrupt does */ +- (void)cmpxchg(&cpu_buffer->tail_page, tail_page, next_page); ++ /* Either we update tail_page or an interrupt does */ ++ if (try_cmpxchg(&cpu_buffer->tail_page, &tail_page, next_page)) ++ local_inc(&cpu_buffer->pages_touched); + } + } + diff --git a/queue-5.4/series b/queue-5.4/series new file mode 100644 index 00000000000..97def5ac885 --- /dev/null +++ b/queue-5.4/series @@ -0,0 +1,3 @@ +batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch +ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch +bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch