]> git.ipfire.org Git - thirdparty/kernel/stable-queue.git/commitdiff
5.15-stable patches
authorGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 14 Apr 2024 13:43:14 +0000 (15:43 +0200)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sun, 14 Apr 2024 13:43:14 +0000 (15:43 +0200)
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

queue-5.15/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch [new file with mode: 0644]
queue-5.15/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch [new file with mode: 0644]
queue-5.15/media-cec-core-remove-length-check-of-timer-status.patch [new file with mode: 0644]
queue-5.15/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch [new file with mode: 0644]
queue-5.15/series [new file with mode: 0644]

diff --git a/queue-5.15/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch b/queue-5.15/batman-adv-avoid-infinite-loop-trying-to-resize-local-tt.patch
new file mode 100644 (file)
index 0000000..8d599c3
--- /dev/null
@@ -0,0 +1,68 @@
+From b1f532a3b1e6d2e5559c7ace49322922637a28aa Mon Sep 17 00:00:00 2001
+From: Sven Eckelmann <sven@narfation.org>
+Date: Mon, 12 Feb 2024 13:58:33 +0100
+Subject: batman-adv: Avoid infinite loop trying to resize local TT
+
+From: Sven Eckelmann <sven@narfation.org>
+
+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 <sven@narfation.org>
+Signed-off-by: Simon Wunderlich <sw@simonwunderlich.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -3948,7 +3948,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.15/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch b/queue-5.15/bluetooth-fix-memory-leak-in-hci_req_sync_complete.patch
new file mode 100644 (file)
index 0000000..37e4303
--- /dev/null
@@ -0,0 +1,37 @@
+From 45d355a926ab40f3ae7bc0b0a00cb0e3e8a5a810 Mon Sep 17 00:00:00 2001
+From: Dmitry Antipov <dmantipov@yandex.ru>
+Date: Tue, 2 Apr 2024 14:32:05 +0300
+Subject: Bluetooth: Fix memory leak in hci_req_sync_complete()
+
+From: Dmitry Antipov <dmantipov@yandex.ru>
+
+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 <dmantipov@yandex.ru>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -108,8 +108,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.15/media-cec-core-remove-length-check-of-timer-status.patch b/queue-5.15/media-cec-core-remove-length-check-of-timer-status.patch
new file mode 100644 (file)
index 0000000..a081e19
--- /dev/null
@@ -0,0 +1,52 @@
+From ce5d241c3ad4568c12842168288993234345c0eb Mon Sep 17 00:00:00 2001
+From: Nini Song <nini.song@mediatek.com>
+Date: Thu, 25 Jan 2024 21:28:45 +0800
+Subject: media: cec: core: remove length check of Timer Status
+
+From: Nini Song <nini.song@mediatek.com>
+
+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 <nini.song@mediatek.com>
+Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -1117,20 +1117,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.15/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch b/queue-5.15/ring-buffer-only-update-pages_touched-when-a-new-page-is-touched.patch
new file mode 100644 (file)
index 0000000..e53e593
--- /dev/null
@@ -0,0 +1,83 @@
+From ffe3986fece696cf65e0ef99e74c75f848be8e30 Mon Sep 17 00:00:00 2001
+From: "Steven Rostedt (Google)" <rostedt@goodmis.org>
+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) <rostedt@goodmis.org>
+
+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 <mathieu.desnoyers@efficios.com>
+Fixes: 2c2b0a78b3739 ("ring-buffer: Add percentage of ring buffer full to wake up reader")
+Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org>
+Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ 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
+@@ -1509,7 +1509,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.
+@@ -1546,8 +1545,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.15/series b/queue-5.15/series
new file mode 100644 (file)
index 0000000..5ebe62a
--- /dev/null
@@ -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