From: Greg Kroah-Hartman Date: Sun, 14 Apr 2024 13:43:00 +0000 (+0200) Subject: 5.10-stable patches X-Git-Tag: v5.15.156~64 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=0ebf78d5b58362d1d157377e4c78be9b04222a0f;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-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 media-cec-core-remove-length-check-of-timer-status.patch ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch series --- diff --git a/queue-5.10/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch b/queue-5.10/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch new file mode 100644 index 00000000000..214d0a69273 --- /dev/null +++ b/queue-5.10/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 +@@ -4188,7 +4188,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.10/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch b/queue-5.10/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch new file mode 100644 index 00000000000..a569154edc4 --- /dev/null +++ b/queue-5.10/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.10/media-cec-core-remove-length-check-of-timer-status.patch b/queue-5.10/media-cec-core-remove-length-check-of-timer-status.patch new file mode 100644 index 00000000000..c230b8c2d26 --- /dev/null +++ b/queue-5.10/media-cec-core-remove-length-check-of-timer-status.patch @@ -0,0 +1,52 @@ +From ce5d241c3ad4568c12842168288993234345c0eb Mon Sep 17 00:00:00 2001 +From: Nini Song +Date: Thu, 25 Jan 2024 21:28:45 +0800 +Subject: media: cec: core: remove length check of Timer Status + +From: Nini Song + +commit ce5d241c3ad4568c12842168288993234345c0eb upstream. + +The valid_la is used to check the length requirements, +including special cases of Timer Status. If the length is +shorter than 5, that means no Duration Available is returned, +the message will be forced to be invalid. + +However, the description of Duration Available in the spec +is that this parameter may be returned when these cases, or +that it can be optionally return when these cases. The key +words in the spec description are flexible choices. + +Remove the special length check of Timer Status to fit the +spec which is not compulsory about that. + +Signed-off-by: Nini Song +Signed-off-by: Hans Verkuil +Signed-off-by: Greg Kroah-Hartman +--- + drivers/media/cec/core/cec-adap.c | 14 -------------- + 1 file changed, 14 deletions(-) + +--- a/drivers/media/cec/core/cec-adap.c ++++ b/drivers/media/cec/core/cec-adap.c +@@ -1116,20 +1116,6 @@ void cec_received_msg_ts(struct cec_adap + if (valid_la && min_len) { + /* These messages have special length requirements */ + switch (cmd) { +- case CEC_MSG_TIMER_STATUS: +- if (msg->msg[2] & 0x10) { +- switch (msg->msg[2] & 0xf) { +- case CEC_OP_PROG_INFO_NOT_ENOUGH_SPACE: +- case CEC_OP_PROG_INFO_MIGHT_NOT_BE_ENOUGH_SPACE: +- if (msg->len < 5) +- valid_la = false; +- break; +- } +- } else if ((msg->msg[2] & 0xf) == CEC_OP_PROG_ERROR_DUPLICATE) { +- if (msg->len < 5) +- valid_la = false; +- } +- break; + case CEC_MSG_RECORD_ON: + switch (msg->msg[2]) { + case CEC_OP_RECORD_SRC_OWN: diff --git a/queue-5.10/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch b/queue-5.10/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch new file mode 100644 index 00000000000..a30256295d8 --- /dev/null +++ b/queue-5.10/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 +@@ -1439,7 +1439,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. +@@ -1476,8 +1475,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.10/series b/queue-5.10/series new file mode 100644 index 00000000000..5ebe62a63d7 --- /dev/null +++ b/queue-5.10/series @@ -0,0 +1,4 @@ +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 +media-cec-core-remove-length-check-of-timer-status.patch