From 52335131b829cbb67e10cf6542c7cdcd9f9dcb86 Mon Sep 17 00:00:00 2001 From: Greg Kroah-Hartman Date: Sat, 11 Feb 2023 12:42:41 +0100 Subject: [PATCH] 5.4-stable patches added patches: alsa-emux-avoid-potential-array-out-of-bound-in-snd_emux_xg_control.patch can-j1939-do-not-wait-250-ms-if-the-same-addr-was-already-claimed.patch tracing-fix-poll-and-select-do-not-work-on-per_cpu-trace_pipe-and-trace_pipe_raw.patch --- ...-out-of-bound-in-snd_emux_xg_control.patch | 37 ++++++ ...if-the-same-addr-was-already-claimed.patch | 106 ++++++++++++++++++ queue-5.4/series | 3 + ...er_cpu-trace_pipe-and-trace_pipe_raw.patch | 53 +++++++++ 4 files changed, 199 insertions(+) create mode 100644 queue-5.4/alsa-emux-avoid-potential-array-out-of-bound-in-snd_emux_xg_control.patch create mode 100644 queue-5.4/can-j1939-do-not-wait-250-ms-if-the-same-addr-was-already-claimed.patch create mode 100644 queue-5.4/tracing-fix-poll-and-select-do-not-work-on-per_cpu-trace_pipe-and-trace_pipe_raw.patch diff --git a/queue-5.4/alsa-emux-avoid-potential-array-out-of-bound-in-snd_emux_xg_control.patch b/queue-5.4/alsa-emux-avoid-potential-array-out-of-bound-in-snd_emux_xg_control.patch new file mode 100644 index 00000000000..76f7f55c772 --- /dev/null +++ b/queue-5.4/alsa-emux-avoid-potential-array-out-of-bound-in-snd_emux_xg_control.patch @@ -0,0 +1,37 @@ +From 6a32425f953b955b4ff82f339d01df0b713caa5d Mon Sep 17 00:00:00 2001 +From: Artemii Karasev +Date: Tue, 7 Feb 2023 18:20:26 +0500 +Subject: ALSA: emux: Avoid potential array out-of-bound in snd_emux_xg_control() + +From: Artemii Karasev + +commit 6a32425f953b955b4ff82f339d01df0b713caa5d upstream. + +snd_emux_xg_control() can be called with an argument 'param' greater +than size of 'control' array. It may lead to accessing 'control' +array at a wrong index. + +Found by Linux Verification Center (linuxtesting.org) with SVACE. + +Signed-off-by: Artemii Karasev +Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") +Cc: +Link: https://lore.kernel.org/r/20230207132026.2870-1-karasev@ispras.ru +Signed-off-by: Takashi Iwai +Signed-off-by: Greg Kroah-Hartman +--- + sound/synth/emux/emux_nrpn.c | 3 +++ + 1 file changed, 3 insertions(+) + +--- a/sound/synth/emux/emux_nrpn.c ++++ b/sound/synth/emux/emux_nrpn.c +@@ -349,6 +349,9 @@ int + snd_emux_xg_control(struct snd_emux_port *port, struct snd_midi_channel *chan, + int param) + { ++ if (param >= ARRAY_SIZE(chan->control)) ++ return -EINVAL; ++ + return send_converted_effect(xg_effects, ARRAY_SIZE(xg_effects), + port, chan, param, + chan->control[param], diff --git a/queue-5.4/can-j1939-do-not-wait-250-ms-if-the-same-addr-was-already-claimed.patch b/queue-5.4/can-j1939-do-not-wait-250-ms-if-the-same-addr-was-already-claimed.patch new file mode 100644 index 00000000000..224d7c63b69 --- /dev/null +++ b/queue-5.4/can-j1939-do-not-wait-250-ms-if-the-same-addr-was-already-claimed.patch @@ -0,0 +1,106 @@ +From 4ae5e1e97c44f4654516c1d41591a462ed62fa7b Mon Sep 17 00:00:00 2001 +From: Devid Antonio Filoni +Date: Fri, 25 Nov 2022 18:04:18 +0100 +Subject: can: j1939: do not wait 250 ms if the same addr was already claimed + +From: Devid Antonio Filoni + +commit 4ae5e1e97c44f4654516c1d41591a462ed62fa7b upstream. + +The ISO 11783-5 standard, in "4.5.2 - Address claim requirements", states: + d) No CF shall begin, or resume, transmission on the network until 250 + ms after it has successfully claimed an address except when + responding to a request for address-claimed. + +But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim +prioritization" show that the CF begins the transmission after 250 ms +from the first AC (address-claimed) message even if it sends another AC +message during that time window to resolve the address contention with +another CF. + +As stated in "4.4.2.3 - Address-claimed message": + In order to successfully claim an address, the CF sending an address + claimed message shall not receive a contending claim from another CF + for at least 250 ms. + +As stated in "4.4.3.2 - NAME management (NM) message": + 1) A commanding CF can + d) request that a CF with a specified NAME transmit the address- + claimed message with its current NAME. + 2) A target CF shall + d) send an address-claimed message in response to a request for a + matching NAME + +Taking the above arguments into account, the 250 ms wait is requested +only during network initialization. + +Do not restart the timer on AC message if both the NAME and the address +match and so if the address has already been claimed (timer has expired) +or the AC message has been sent to resolve the contention with another +CF (timer is still running). + +Signed-off-by: Devid Antonio Filoni +Acked-by: Oleksij Rempel +Link: https://lore.kernel.org/all/20221125170418.34575-1-devid.filoni@egluetechnologies.com +Fixes: 9d71dd0c7009 ("can: add support of SAE J1939 protocol") +Cc: stable@vger.kernel.org +Signed-off-by: Marc Kleine-Budde +Signed-off-by: Greg Kroah-Hartman +--- + net/can/j1939/address-claim.c | 40 +++++++++++++++++++++++++++++++++++ + 1 file changed, 40 insertions(+) + +diff --git a/net/can/j1939/address-claim.c b/net/can/j1939/address-claim.c +index f33c47327927..ca4ad6cdd5cb 100644 +--- a/net/can/j1939/address-claim.c ++++ b/net/can/j1939/address-claim.c +@@ -165,6 +165,46 @@ static void j1939_ac_process(struct j1939_priv *priv, struct sk_buff *skb) + * leaving this function. + */ + ecu = j1939_ecu_get_by_name_locked(priv, name); ++ ++ if (ecu && ecu->addr == skcb->addr.sa) { ++ /* The ISO 11783-5 standard, in "4.5.2 - Address claim ++ * requirements", states: ++ * d) No CF shall begin, or resume, transmission on the ++ * network until 250 ms after it has successfully claimed ++ * an address except when responding to a request for ++ * address-claimed. ++ * ++ * But "Figure 6" and "Figure 7" in "4.5.4.2 - Address-claim ++ * prioritization" show that the CF begins the transmission ++ * after 250 ms from the first AC (address-claimed) message ++ * even if it sends another AC message during that time window ++ * to resolve the address contention with another CF. ++ * ++ * As stated in "4.4.2.3 - Address-claimed message": ++ * In order to successfully claim an address, the CF sending ++ * an address claimed message shall not receive a contending ++ * claim from another CF for at least 250 ms. ++ * ++ * As stated in "4.4.3.2 - NAME management (NM) message": ++ * 1) A commanding CF can ++ * d) request that a CF with a specified NAME transmit ++ * the address-claimed message with its current NAME. ++ * 2) A target CF shall ++ * d) send an address-claimed message in response to a ++ * request for a matching NAME ++ * ++ * Taking the above arguments into account, the 250 ms wait is ++ * requested only during network initialization. ++ * ++ * Do not restart the timer on AC message if both the NAME and ++ * the address match and so if the address has already been ++ * claimed (timer has expired) or the AC message has been sent ++ * to resolve the contention with another CF (timer is still ++ * running). ++ */ ++ goto out_ecu_put; ++ } ++ + if (!ecu && j1939_address_is_unicast(skcb->addr.sa)) + ecu = j1939_ecu_create_locked(priv, name); + +-- +2.39.1 + diff --git a/queue-5.4/series b/queue-5.4/series index 304000da5cf..6169a28d401 100644 --- a/queue-5.4/series +++ b/queue-5.4/series @@ -59,3 +59,6 @@ wifi-brcmfmac-check-the-count-value-of-channel-spec-to-prevent-out-of-bounds-rea iio-adc-twl6030-enable-measurement-of-vac.patch btrfs-limit-device-extents-to-the-device-size.patch btrfs-zlib-zero-initialize-zlib-workspace.patch +alsa-emux-avoid-potential-array-out-of-bound-in-snd_emux_xg_control.patch +tracing-fix-poll-and-select-do-not-work-on-per_cpu-trace_pipe-and-trace_pipe_raw.patch +can-j1939-do-not-wait-250-ms-if-the-same-addr-was-already-claimed.patch diff --git a/queue-5.4/tracing-fix-poll-and-select-do-not-work-on-per_cpu-trace_pipe-and-trace_pipe_raw.patch b/queue-5.4/tracing-fix-poll-and-select-do-not-work-on-per_cpu-trace_pipe-and-trace_pipe_raw.patch new file mode 100644 index 00000000000..2238343b98e --- /dev/null +++ b/queue-5.4/tracing-fix-poll-and-select-do-not-work-on-per_cpu-trace_pipe-and-trace_pipe_raw.patch @@ -0,0 +1,53 @@ +From 3e46d910d8acf94e5360126593b68bf4fee4c4a1 Mon Sep 17 00:00:00 2001 +From: Shiju Jose +Date: Thu, 2 Feb 2023 18:23:09 +0000 +Subject: tracing: Fix poll() and select() do not work on per_cpu trace_pipe and trace_pipe_raw + +From: Shiju Jose + +commit 3e46d910d8acf94e5360126593b68bf4fee4c4a1 upstream. + +poll() and select() on per_cpu trace_pipe and trace_pipe_raw do not work +since kernel 6.1-rc6. This issue is seen after the commit +42fb0a1e84ff525ebe560e2baf9451ab69127e2b ("tracing/ring-buffer: Have +polling block on watermark"). + +This issue is firstly detected and reported, when testing the CXL error +events in the rasdaemon and also erified using the test application for poll() +and select(). + +This issue occurs for the per_cpu case, when calling the ring_buffer_poll_wait(), +in kernel/trace/ring_buffer.c, with the buffer_percent > 0 and then wait until the +percentage of pages are available. The default value set for the buffer_percent is 50 +in the kernel/trace/trace.c. + +As a fix, allow userspace application could set buffer_percent as 0 through +the buffer_percent_fops, so that the task will wake up as soon as data is added +to any of the specific cpu buffer. + +Link: https://lore.kernel.org/linux-trace-kernel/20230202182309.742-2-shiju.jose@huawei.com + +Cc: +Cc: +Cc: +Cc: stable@vger.kernel.org +Fixes: 42fb0a1e84ff5 ("tracing/ring-buffer: Have polling block on watermark") +Signed-off-by: Shiju Jose +Signed-off-by: Steven Rostedt (Google) +Signed-off-by: Greg Kroah-Hartman +--- + kernel/trace/trace.c | 3 --- + 1 file changed, 3 deletions(-) + +--- a/kernel/trace/trace.c ++++ b/kernel/trace/trace.c +@@ -8298,9 +8298,6 @@ buffer_percent_write(struct file *filp, + if (val > 100) + return -EINVAL; + +- if (!val) +- val = 1; +- + tr->buffer_percent = val; + + (*ppos)++; -- 2.47.3