April 2024 - Linux-stable-mirror

[PATCH] Bluetooth: qca: fix wcn3991 device address check

by Johan Hovold

Qualcomm Bluetooth controllers may not have been provisioned with a valid device address and instead end up using the default address 00:00:00:00:5a:ad. This address is now used to determine if a controller has a valid address or if one needs to be provided through devicetree or by user space before the controller can be used. It turns out that the WCN3991 controllers used in Chromium Trogdor machines use a different default address, 39:98:00:00:5a:ad, which also needs to be marked as invalid so that the correct address is fetched from the devicetree. Qualcomm has unfortunately not yet provided any answers as to whether the 39:98 encodes a hardware id and if there are other variants of the default address that needs to be handled by the driver. For now, add the Trogdor WCN3991 default address to the device address check to avoid having these controllers start with the default address instead of their assigned addresses. Fixes: 00567f70051a ("Bluetooth: qca: fix invalid device address check") Cc: stable(a)vger.kernel.org # 6.5 Cc: Doug Anderson <dianders(a)chromium.org> Cc: Janaki Ramaiah Thota <quic_janathot(a)quicinc.com> Signed-off-by: Johan Hovold <johan+linaro(a)kernel.org> --- drivers/bluetooth/btqca.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) Luiz and Doug, As the offending commit is now on its way into 6.9, let's just add the default address that the Trogdor machines uses to the address check. We can always amend this when/if Qualcomm provides some more details, or, in the worst case, when users report that they need to re-pair their Bluetooth gadgets if there are further variations of the default address. Johan diff --git a/drivers/bluetooth/btqca.c b/drivers/bluetooth/btqca.c index 216826c31ee3..cfa71708397b 100644 --- a/drivers/bluetooth/btqca.c +++ b/drivers/bluetooth/btqca.c @@ -16,6 +16,7 @@ #define VERSION "0.1" #define QCA_BDADDR_DEFAULT (&(bdaddr_t) {{ 0xad, 0x5a, 0x00, 0x00, 0x00, 0x00 }}) +#define QCA_BDADDR_WCN3991 (&(bdaddr_t) {{ 0xad, 0x5a, 0x00, 0x00, 0x98, 0x39 }}) int qca_read_soc_version(struct hci_dev *hdev, struct qca_btsoc_version *ver, enum qca_btsoc_type soc_type) @@ -638,8 +639,10 @@ static int qca_check_bdaddr(struct hci_dev *hdev) } bda = (struct hci_rp_read_bd_addr *)skb->data; - if (!bacmp(&bda->bdaddr, QCA_BDADDR_DEFAULT)) + if (!bacmp(&bda->bdaddr, QCA_BDADDR_DEFAULT) || + !bacmp(&bda->bdaddr, QCA_BDADDR_WCN3991)) { set_bit(HCI_QUIRK_USE_BDADDR_PROPERTY, &hdev->quirks); + } kfree_skb(skb); -- 2.43.2

8 months, 1 week

3
2
0 0

[PATCH net v3 0/4] Fix isolation of broadcast traffic and unmatched unicast traffic with MACsec offload

by Rahul Rameshbabu

Some device drivers support devices that enable them to annotate whether a Rx skb refers to a packet that was processed by the MACsec offloading functionality of the device. Logic in the Rx handling for MACsec offload does not utilize this information to preemptively avoid forwarding to the macsec netdev currently. Because of this, things like multicast messages or unicast messages with an unmatched destination address such as ARP requests are forwarded to the macsec netdev whether the message received was MACsec encrypted or not. The goal of this patch series is to improve the Rx handling for MACsec offload for devices capable of annotating skbs received that were decrypted by the NIC offload for MACsec. Here is a summary of the issue that occurs with the existing logic today. * The current design of the MACsec offload handling path tries to use "best guess" mechanisms for determining whether a packet associated with the currently handled skb in the datapath was processed via HW offload * The best guess mechanism uses the following heuristic logic (in order of precedence) - Check if header destination MAC address matches MACsec netdev MAC address -> forward to MACsec port - Check if packet is multicast traffic -> forward to MACsec port - MACsec security channel was able to be looked up from skb offload context (mlx5 only) -> forward to MACsec port * Problem: plaintext traffic can potentially solicit a MACsec encrypted response from the offload device - Core aspect of MACsec is that it identifies unauthorized LAN connections and excludes them from communication + This behavior can be seen when not enabling offload for MACsec - The offload behavior violates this principle in MACsec I believe this behavior is a security bug since applications utilizing MACsec could be exploited using this behavior, and the correct way to resolve this is by having the hardware correctly indicate whether MACsec offload occurred for the packet or not. In the patches in this series, I leave a warning for when the problematic path occurs because I cannot figure out a secure way to fix the security issue that applies to the core MACsec offload handling in the Rx path without breaking MACsec offload for other vendors. Shown at the bottom is an example use case where plaintext traffic sent to a physical port of a NIC configured for MACsec offload is unable to be handled correctly by the software stack when the NIC provides awareness to the kernel about whether the received packet is MACsec traffic or not. In this specific example, plaintext ARP requests are being responded with MACsec encrypted ARP replies (which leads to routing information being unable to be built for the requester). Side 1 ip link del macsec0 ip address flush mlx5_1 ip address add 1.1.1.1/24 dev mlx5_1 ip link set dev mlx5_1 up ip link add link mlx5_1 macsec0 type macsec sci 1 encrypt on ip link set dev macsec0 address 00:11:22:33:44:66 ip macsec offload macsec0 mac ip macsec add macsec0 tx sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16 ip macsec add macsec0 rx sci 2 on ip macsec add macsec0 rx sci 2 sa 0 pn 1 on key 00 ead3664f508eb06c40ac7104cdae4ce5 ip address flush macsec0 ip address add 2.2.2.1/24 dev macsec0 ip link set dev macsec0 up # macsec0 enters promiscuous mode. # This enables all traffic received on macsec_vlan to be processed by # the macsec offload rx datapath. This however means that traffic # meant to be received by mlx5_1 will be incorrectly steered to # macsec0 as well. ip link add link macsec0 name macsec_vlan type vlan id 1 ip link set dev macsec_vlan address 00:11:22:33:44:88 ip address flush macsec_vlan ip address add 3.3.3.1/24 dev macsec_vlan ip link set dev macsec_vlan up Side 2 ip link del macsec0 ip address flush mlx5_1 ip address add 1.1.1.2/24 dev mlx5_1 ip link set dev mlx5_1 up ip link add link mlx5_1 macsec0 type macsec sci 2 encrypt on ip link set dev macsec0 address 00:11:22:33:44:77 ip macsec offload macsec0 mac ip macsec add macsec0 tx sa 0 pn 1 on key 00 ead3664f508eb06c40ac7104cdae4ce5 ip macsec add macsec0 rx sci 1 on ip macsec add macsec0 rx sci 1 sa 0 pn 1 on key 00 dffafc8d7b9a43d5b9a3dfbbf6a30c16 ip address flush macsec0 ip address add 2.2.2.2/24 dev macsec0 ip link set dev macsec0 up # macsec0 enters promiscuous mode. # This enables all traffic received on macsec_vlan to be processed by # the macsec offload rx datapath. This however means that traffic # meant to be received by mlx5_1 will be incorrectly steered to # macsec0 as well. ip link add link macsec0 name macsec_vlan type vlan id 1 ip link set dev macsec_vlan address 00:11:22:33:44:99 ip address flush macsec_vlan ip address add 3.3.3.2/24 dev macsec_vlan ip link set dev macsec_vlan up Side 1 ping -I mlx5_1 1.1.1.2 PING 1.1.1.2 (1.1.1.2) from 1.1.1.1 mlx5_1: 56(84) bytes of data. From 1.1.1.1 icmp_seq=1 Destination Host Unreachable ping: sendmsg: No route to host From 1.1.1.1 icmp_seq=2 Destination Host Unreachable From 1.1.1.1 icmp_seq=3 Destination Host Unreachable Changes: v2->v3: * Made dev paramater const for eth_skb_pkt_type helper as suggested by Sabrina Dubroca <sd(a)queasysnail.net> v1->v2: * Fixed series subject to detail the issue being fixed * Removed strange characters from cover letter * Added comment in example that illustrates the impact involving promiscuous mode * Added patch for generalizing packet type detection * Added Fixes: tags and targeting net * Removed pointless warning in the heuristic Rx path for macsec offload * Applied small refactor in Rx path offload to minimize scope of rx_sc local variable Link: https://github.com/Binary-Eater/macsec-rx-offload/blob/trunk/MACsec_violati… Link: https://lore.kernel.org/netdev/20240419213033.400467-5-rrameshbabu@nvidia.c… Link: https://lore.kernel.org/netdev/20240419011740.333714-1-rrameshbabu@nvidia.c… Link: https://lore.kernel.org/netdev/87r0l25y1c.fsf@nvidia.com/ Link: https://lore.kernel.org/netdev/20231116182900.46052-1-rrameshbabu@nvidia.co… Cc: Sabrina Dubroca <sd(a)queasysnail.net> Cc: stable(a)vger.kernel.org Signed-off-by: Rahul Rameshbabu <rrameshbabu(a)nvidia.com> --- Rahul Rameshbabu (4): macsec: Enable devices to advertise whether they update sk_buff md_dst during offloads ethernet: Add helper for assigning packet type when dest address does not match device address macsec: Detect if Rx skb is macsec-related for offloading devices that update md_dst net/mlx5e: Advertise mlx5 ethernet driver updates sk_buff md_dst for MACsec .../mellanox/mlx5/core/en_accel/macsec.c | 1 + drivers/net/macsec.c | 46 +++++++++++++++---- include/linux/etherdevice.h | 25 ++++++++++ include/net/macsec.h | 2 + net/ethernet/eth.c | 12 +---- 5 files changed, 65 insertions(+), 21 deletions(-) -- 2.42.0

8 months, 1 week

3
6
0 0

[PATCH] usb: gadget: u_audio: Clear uac pointer when freed.

by Chris Wulff

This prevents use of a stale pointer if functions are called after g_cleanup that shouldn't be. This doesn't fix any races, but converts a possibly silent kernel memory corruption into an obvious NULL pointer dereference report. Fixes: eb9fecb9e69b ("usb: gadget: f_uac2: split out audio core") Signed-off-by: Chris Wulff <chris.wulff(a)biamp.com> --- v1: Split from https://lore.kernel.org/linux-usb/CO1PR17MB54190B898057616EEB3F9E51E10E2@CO… drivers/usb/gadget/function/u_audio.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/usb/gadget/function/u_audio.c b/drivers/usb/gadget/function/u_audio.c index c8e8154c59f5..ec1dceb08729 100644 --- a/drivers/usb/gadget/function/u_audio.c +++ b/drivers/usb/gadget/function/u_audio.c @@ -1419,6 +1419,8 @@ void g_audio_cleanup(struct g_audio *g_audio) return; uac = g_audio->uac; + g_audio->uac = NULL; + card = uac->card; if (card) snd_card_free_when_closed(card); -- 2.34.1

8 months, 1 week

2
1
0 0

[PATCH v2] usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.

by Chris Wulff

Hang on to the control IDs instead of pointers since those are correctly handled with locks. Fixes: 8fe9a03f4331 ("usb: gadget: u_audio: Rate ctl notifies about current srate (0=stopped)") Fixes: c565ad07ef35 ("usb: gadget: u_audio: Support multiple sampling rates") Fixes: 02de698ca812 ("usb: gadget: u_audio: add bi-directional volume and mute support") Signed-off-by: Chris Wulff <chris.wulff(a)biamp.com> --- v2: Removed items not directly related to controls. Added Fixes: v1: https://lore.kernel.org/linux-usb/CO1PR17MB54190B898057616EEB3F9E51E10E2@CO… drivers/usb/gadget/function/u_audio.c | 19 +++++++++---------- 1 file changed, 9 insertions(+), 10 deletions(-) diff --git a/drivers/usb/gadget/function/u_audio.c b/drivers/usb/gadget/function/u_audio.c index 4a42574b4a7f..c8e8154c59f5 100644 --- a/drivers/usb/gadget/function/u_audio.c +++ b/drivers/usb/gadget/function/u_audio.c @@ -57,13 +57,13 @@ struct uac_rtd_params { /* Volume/Mute controls and their state */ int fu_id; /* Feature Unit ID */ - struct snd_kcontrol *snd_kctl_volume; - struct snd_kcontrol *snd_kctl_mute; + struct snd_ctl_elem_id snd_kctl_volume_id; + struct snd_ctl_elem_id snd_kctl_mute_id; s16 volume_min, volume_max, volume_res; s16 volume; int mute; - struct snd_kcontrol *snd_kctl_rate; /* read-only current rate */ + struct snd_ctl_elem_id snd_kctl_rate_id; /* read-only current rate */ int srate; /* selected samplerate */ int active; /* playback/capture running */ @@ -494,14 +494,13 @@ static inline void free_ep_fback(struct uac_rtd_params *prm, struct usb_ep *ep) static void set_active(struct uac_rtd_params *prm, bool active) { // notifying through the Rate ctrl - struct snd_kcontrol *kctl = prm->snd_kctl_rate; unsigned long flags; spin_lock_irqsave(&prm->lock, flags); if (prm->active != active) { prm->active = active; snd_ctl_notify(prm->uac->card, SNDRV_CTL_EVENT_MASK_VALUE, - &kctl->id); + &prm->snd_kctl_rate_id); } spin_unlock_irqrestore(&prm->lock, flags); } @@ -807,7 +806,7 @@ int u_audio_set_volume(struct g_audio *audio_dev, int playback, s16 val) if (change) snd_ctl_notify(uac->card, SNDRV_CTL_EVENT_MASK_VALUE, - &prm->snd_kctl_volume->id); + &prm->snd_kctl_volume_id); return 0; } @@ -856,7 +855,7 @@ int u_audio_set_mute(struct g_audio *audio_dev, int playback, int val) if (change) snd_ctl_notify(uac->card, SNDRV_CTL_EVENT_MASK_VALUE, - &prm->snd_kctl_mute->id); + &prm->snd_kctl_mute_id); return 0; } @@ -1331,7 +1330,7 @@ int g_audio_setup(struct g_audio *g_audio, const char *pcm_name, err = snd_ctl_add(card, kctl); if (err < 0) goto snd_fail; - prm->snd_kctl_mute = kctl; + prm->snd_kctl_mute_id = kctl->id; prm->mute = 0; } @@ -1359,7 +1358,7 @@ int g_audio_setup(struct g_audio *g_audio, const char *pcm_name, err = snd_ctl_add(card, kctl); if (err < 0) goto snd_fail; - prm->snd_kctl_volume = kctl; + prm->snd_kctl_volume_id = kctl->id; prm->volume = fu->volume_max; prm->volume_max = fu->volume_max; prm->volume_min = fu->volume_min; @@ -1383,7 +1382,7 @@ int g_audio_setup(struct g_audio *g_audio, const char *pcm_name, err = snd_ctl_add(card, kctl); if (err < 0) goto snd_fail; - prm->snd_kctl_rate = kctl; + prm->snd_kctl_rate_id = kctl->id; } strscpy(card->driver, card_name, sizeof(card->driver)); -- 2.34.1

8 months, 1 week

2
1
0 0

[tip: x86/urgent] cpu: Re-enable CPU mitigations by default for !X86 architectures

by tip-bot2 for Sean Christopherson

The following commit has been merged into the x86/urgent branch of tip: Commit-ID: fe42754b94a42d08cf9501790afc25c4f6a5f631 Gitweb: https://git.kernel.org/tip/fe42754b94a42d08cf9501790afc25c4f6a5f631 Author: Sean Christopherson <seanjc(a)google.com> AuthorDate: Fri, 19 Apr 2024 17:05:54 -07:00 Committer: Borislav Petkov (AMD) <bp(a)alien8.de> CommitterDate: Thu, 25 Apr 2024 15:47:35 +02:00 cpu: Re-enable CPU mitigations by default for !X86 architectures Rename x86's to CPU_MITIGATIONS, define it in generic code, and force it on for all architectures exception x86. A recent commit to turn mitigations off by default if SPECULATION_MITIGATIONS=n kinda sorta missed that "cpu_mitigations" is completely generic, whereas SPECULATION_MITIGATIONS is x86-specific. Rename x86's SPECULATIVE_MITIGATIONS instead of keeping both and have it select CPU_MITIGATIONS, as having two configs for the same thing is unnecessary and confusing. This will also allow x86 to use the knob to manage mitigations that aren't strictly related to speculative execution. Use another Kconfig to communicate to common code that CPU_MITIGATIONS is already defined instead of having x86's menu depend on the common CPU_MITIGATIONS. This allows keeping a single point of contact for all of x86's mitigations, and it's not clear that other architectures *want* to allow disabling mitigations at compile-time. Fixes: f337a6a21e2f ("x86/cpu: Actually turn off mitigations by default for SPECULATION_MITIGATIONS=n") Closes: https://lkml.kernel.org/r/20240413115324.53303a68%40canb.auug.org.au Reported-by: Stephen Rothwell <sfr(a)canb.auug.org.au> Reported-by: Michael Ellerman <mpe(a)ellerman.id.au> Reported-by: Geert Uytterhoeven <geert(a)linux-m68k.org> Signed-off-by: Sean Christopherson <seanjc(a)google.com> Signed-off-by: Borislav Petkov (AMD) <bp(a)alien8.de> Acked-by: Josh Poimboeuf <jpoimboe(a)kernel.org> Acked-by: Borislav Petkov (AMD) <bp(a)alien8.de> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240420000556.2645001-2-seanjc@google.com --- arch/Kconfig | 8 ++++++++ arch/x86/Kconfig | 11 ++++++----- kernel/cpu.c | 4 ++-- 3 files changed, 16 insertions(+), 7 deletions(-) diff --git a/arch/Kconfig b/arch/Kconfig index 65afb1d..30f7930 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -9,6 +9,14 @@ # source "arch/$(SRCARCH)/Kconfig" +config ARCH_CONFIGURES_CPU_MITIGATIONS + bool + +if !ARCH_CONFIGURES_CPU_MITIGATIONS +config CPU_MITIGATIONS + def_bool y +endif + menu "General architecture-dependent options" config ARCH_HAS_SUBPAGE_FAULTS diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 4474bf3..619a04d 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -62,6 +62,7 @@ config X86 select ACPI_HOTPLUG_CPU if ACPI_PROCESSOR && HOTPLUG_CPU select ARCH_32BIT_OFF_T if X86_32 select ARCH_CLOCKSOURCE_INIT + select ARCH_CONFIGURES_CPU_MITIGATIONS select ARCH_CORRECT_STACKTRACE_ON_KRETPROBE select ARCH_ENABLE_HUGEPAGE_MIGRATION if X86_64 && HUGETLB_PAGE && MIGRATION select ARCH_ENABLE_MEMORY_HOTPLUG if X86_64 @@ -2488,17 +2489,17 @@ config PREFIX_SYMBOLS def_bool y depends on CALL_PADDING && !CFI_CLANG -menuconfig SPECULATION_MITIGATIONS - bool "Mitigations for speculative execution vulnerabilities" +menuconfig CPU_MITIGATIONS + bool "Mitigations for CPU vulnerabilities" default y help - Say Y here to enable options which enable mitigations for - speculative execution hardware vulnerabilities. + Say Y here to enable options which enable mitigations for hardware + vulnerabilities (usually related to speculative execution). If you say N, all mitigations will be disabled. You really should know what you are doing to say so. -if SPECULATION_MITIGATIONS +if CPU_MITIGATIONS config MITIGATION_PAGE_TABLE_ISOLATION bool "Remove the kernel mapping in user mode" diff --git a/kernel/cpu.c b/kernel/cpu.c index 07ad53b..bb0ff27 100644 --- a/kernel/cpu.c +++ b/kernel/cpu.c @@ -3207,8 +3207,8 @@ enum cpu_mitigations { }; static enum cpu_mitigations cpu_mitigations __ro_after_init = - IS_ENABLED(CONFIG_SPECULATION_MITIGATIONS) ? CPU_MITIGATIONS_AUTO : - CPU_MITIGATIONS_OFF; + IS_ENABLED(CONFIG_CPU_MITIGATIONS) ? CPU_MITIGATIONS_AUTO : + CPU_MITIGATIONS_OFF; static int __init mitigations_parse_cmdline(char *arg) {

8 months, 1 week

1
0
0 0

[PATCH] kbuild: rust: force `alloc` extern to allow "empty" Rust files

by Miguel Ojeda

If one attempts to build an essentially empty file somewhere in the kernel tree, it leads to a build error because the compiler does not recognize the `new_uninit` unstable feature: error[E0635]: unknown feature `new_uninit` --> <crate attribute>:1:9 | 1 | feature(new_uninit) | ^^^^^^^^^^ The reason is that we pass `-Zcrate-attr='feature(new_uninit)'` (together with `-Zallow-features=new_uninit`) to let non-`rust/` code use that unstable feature. However, the compiler only recognizes the feature if the `alloc` crate is resolved (the feature is an `alloc` one). `--extern alloc`, which we pass, is not enough to resolve the crate. Introducing a reference like `use alloc;` or `extern crate alloc;` solves the issue, thus this is not seen in normal files. For instance, `use`ing the `kernel` prelude introduces such a reference, since `alloc` is used inside. While normal use of the build system is not impacted by this, it can still be fairly confusing for kernel developers [1], thus use the unstable `force` option of `--extern` [2] (added in Rust 1.71 [3]) to force the compiler to resolve `alloc`. This new unstable feature is only needed meanwhile we use the other unstable feature, since then we will not need `-Zcrate-attr`. Cc: stable(a)vger.kernel.org # v6.6+ Reported-by: Daniel Almeida <daniel.almeida(a)collabora.com> Reported-by: Julian Stecklina <julian.stecklina(a)cyberus-technology.de> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/288089-General/topic/x/… [1] Fixes: 2f7ab1267dc9 ("Kbuild: add Rust support") Link: https://github.com/rust-lang/rust/issues/111302 [2] Link: https://github.com/rust-lang/rust/pull/109421 [3] Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> --- scripts/Makefile.build | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/Makefile.build b/scripts/Makefile.build index baf86c0880b6..533a7799fdfe 100644 --- a/scripts/Makefile.build +++ b/scripts/Makefile.build @@ -273,7 +273,7 @@ rust_common_cmd = \ -Zallow-features=$(rust_allowed_features) \ -Zcrate-attr=no_std \ -Zcrate-attr='feature($(rust_allowed_features))' \ - --extern alloc --extern kernel \ + -Zunstable-options --extern force:alloc --extern kernel \ --crate-type rlib -L $(objtree)/rust/ \ --crate-name $(basename $(notdir $@)) \ --sysroot=/dev/null \ base-commit: 4cece764965020c22cff7665b18a012006359095 -- 2.44.0

8 months, 1 week

4
3
0 0

[PATCH 0/3] HID: bpf: some fixes for pre-loading HID-BPF

by Benjamin Tissoires

As I am working on the next functionalities of HID-BPF, I realized that I had a few issues while preloading the skeleton at boot. None of the errors are terrible as they are not inducing a kernel crash, so it's not super urgent IMO. Regarding the last one, I'm not sure what makes RHEL behave slightly different than upstream. But I am not sure also that the code matches upstream everywhere, so lazy loading it seems like a sensible idea. Furthermore, that also means that the code will not be available until requested by user space, which fits well in the whole idea of HID-BPF: if the user doesn't want it, then it shouldn't be it. Signed-off-by: Benjamin Tissoires <bentiss(a)kernel.org> --- Benjamin Tissoires (3): HID: bpf: fix a comment in a define HID: bpf: fix return value of entrypoints_*__attach() HID: bpf: lazy load the hid_tail_call entrypoint drivers/hid/bpf/hid_bpf_dispatch.c | 6 ------ drivers/hid/bpf/hid_bpf_jmp_table.c | 17 ++++++++++++----- 2 files changed, 12 insertions(+), 11 deletions(-) --- base-commit: b912cf042072e12e93faa874265b30cc0aa521b9 change-id: 20240419-hid_bpf_lazy_skel-ab0d674cb49b Best regards, -- Benjamin Tissoires <bentiss(a)kernel.org>

8 months, 1 week

2
6
0 0

[tip: irq/urgent] irqchip/gic-v3-its: Prevent double free on error

by tip-bot2 for Guanrui Huang

The following commit has been merged into the irq/urgent branch of tip: Commit-ID: c26591afd33adce296c022e3480dea4282b7ef91 Gitweb: https://git.kernel.org/tip/c26591afd33adce296c022e3480dea4282b7ef91 Author: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> AuthorDate: Thu, 18 Apr 2024 14:10:52 +08:00 Committer: Thomas Gleixner <tglx(a)linutronix.de> CommitterDate: Thu, 25 Apr 2024 14:30:46 +02:00 irqchip/gic-v3-its: Prevent double free on error The error handling path in its_vpe_irq_domain_alloc() causes a double free when its_vpe_init() fails after successfully allocating at least one interrupt. This happens because its_vpe_irq_domain_free() frees the interrupts along with the area bitmap and the vprop_page and its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the vprop_page again. Fix this by unconditionally invoking its_vpe_irq_domain_free() which handles all cases correctly and by removing the bitmap/vprop_page freeing from its_vpe_irq_domain_alloc(). [ tglx: Massaged change log ] Fixes: 7d75bbb4bc1a ("irqchip/gic-v3-its: Add VPE irq domain allocation/teardown") Signed-off-by: Guanrui Huang <guanrui.huang(a)linux.alibaba.com> Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Reviewed-by: Zenghui Yu <yuzenghui(a)huawei.com> Cc: stable(a)vger.kernel.org Link: https://lore.kernel.org/r/20240418061053.96803-2-guanrui.huang@linux.alibab… --- drivers/irqchip/irq-gic-v3-its.c | 9 ++------- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/drivers/irqchip/irq-gic-v3-its.c b/drivers/irqchip/irq-gic-v3-its.c index 2a537cb..5f7d3db 100644 --- a/drivers/irqchip/irq-gic-v3-its.c +++ b/drivers/irqchip/irq-gic-v3-its.c @@ -4567,13 +4567,8 @@ static int its_vpe_irq_domain_alloc(struct irq_domain *domain, unsigned int virq irqd_set_resend_when_in_progress(irq_get_irq_data(virq + i)); } - if (err) { - if (i > 0) - its_vpe_irq_domain_free(domain, virq, i); - - its_lpi_free(bitmap, base, nr_ids); - its_free_prop_table(vprop_page); - } + if (err) + its_vpe_irq_domain_free(domain, virq, i); return err; }

8 months, 1 week

1
0
0 0

stable-rc: 5.10: arm64: ring_buffer.c:1479:21: error: implicit declaration of function 'try_cmpxchg'

by Naresh Kamboju

The arm64 and arm builds are failing on stable-rc linux.5.10.y branch due to following build warnings / errors. Anders, build bisected and found first commit as, first bad commit: [9bf29b51d2bc21abdb8bd36382c1c324a1c54ca7] ring-buffer: Only update pages_touched when a new page is touched Reported-by: Linux Kernel Functional Testing <lkft(a)linaro.org> Build log: ----- kernel/trace/ring_buffer.c: In function 'rb_tail_page_update': kernel/trace/ring_buffer.c:1479:21: error: implicit declaration of function 'try_cmpxchg'; did you mean 'xa_cmpxchg'? [-Werror=implicit-function-declaration] 1479 | if (try_cmpxchg(&cpu_buffer->tail_page, &tail_page, next_page)) | ^~~~~~~~~~~ | xa_cmpxchg cc1: some warnings being treated as errors Links: - https://storage.tuxsuite.com/public/linaro/lkft/builds/2fWFu97bCGW3ZYMbPsIp… - https://storage.tuxsuite.com/public/linaro/lkft/builds/2fWFuBOMDouq6VfImqR2… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10… - https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-5.10.y/build/v5.10… Meta data: git_repo: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc git_sha : 5feded50ee597a37f4778545a879337c2f72490d git_short_log : 5feded50ee59 ("Linux 5.10.216-rc1") arch: arm64 toolchain: gcc-12 Steps to reproduce: --- - https://storage.tuxsuite.com/public/linaro/lkft/builds/2fWFuBOMDouq6VfImqR2… -- Linaro LKFT https://lkft.linaro.org

8 months, 1 week

1
0
0 0

[PATCH -next] fbdev: savage: Handle err return when savagefb_check_var failed

by Cai Xinchen

The commit 04e5eac8f3ab("fbdev: savage: Error out if pixclock equals zero") checks the value of pixclock to avoid divide-by-zero error. However the function savagefb_probe doesn't handle the error return of savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error. Fixes: 04e5eac8f3ab ("fbdev: savage: Error out if pixclock equals zero") Signed-off-by: Cai Xinchen <caixinchen1(a)huawei.com> Cc: stable(a)vger.kernel.org --- drivers/video/fbdev/savage/savagefb_driver.c | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/video/fbdev/savage/savagefb_driver.c b/drivers/video/fbdev/savage/savagefb_driver.c index ebc9aeffdde7..ac41f8f37589 100644 --- a/drivers/video/fbdev/savage/savagefb_driver.c +++ b/drivers/video/fbdev/savage/savagefb_driver.c @@ -2276,7 +2276,10 @@ static int savagefb_probe(struct pci_dev *dev, const struct pci_device_id *id) if (info->var.xres_virtual > 0x1000) info->var.xres_virtual = 0x1000; #endif - savagefb_check_var(&info->var, info); + err = savagefb_check_var(&info->var, info); + if (err) + goto failed; + savagefb_set_fix(info); /* -- 2.34.1

8 months, 1 week

2
1
0 0

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror April 2024