Skip to content
  1. Jul 22, 2022
    • Dmitry Osipenko's avatar
      ARM: 9213/1: Print message about disabled Spectre workarounds only once · 6d80ac94
      Dmitry Osipenko authored
      commit e4ced82d
      
       upstream.
      
      Print the message about disabled Spectre workarounds only once. The
      message is printed each time CPU goes out from idling state on NVIDIA
      Tegra boards, causing storm in KMSG that makes system unusable.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarDmitry Osipenko <dmitry.osipenko@collabora.com>
      Signed-off-by: default avatarRussell King (Oracle) <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d80ac94
    • Steven Rostedt (Google)'s avatar
      net: sock: tracing: Fix sock_exceed_buf_limit not to dereference stale pointer · dc3f1afa
      Steven Rostedt (Google) authored
      commit 820b8963 upstream.
      
      The trace event sock_exceed_buf_limit saves the prot->sysctl_mem pointer
      and then dereferences it in the TP_printk() portion. This is unsafe as the
      TP_printk() portion is executed at the time the buffer is read. That is,
      it can be seconds, minutes, days, months, even years later. If the proto
      is freed, then this dereference will can also lead to a kernel crash.
      
      Instead, save the sysctl_mem array into the ring buffer and have the
      TP_printk() reference that instead. This is the proper and safe way to
      read pointers in trace events.
      
      Link: https://lore.kernel.org/all/20220706052130.16368-12-kuniyu@amazon.com/
      
      Cc: stable@vger.kernel.org
      Fixes: 3847ce32
      
       ("core: add tracepoints for queueing skb to rcvbuf")
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Acked-by: default avatarKuniyuki Iwashima <kuniyu@amazon.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dc3f1afa
    • Zheng Yejian's avatar
      tracing/histograms: Fix memory leak problem · eb622d55
      Zheng Yejian authored
      commit 7edc3945 upstream.
      
      This reverts commit 46bbe5c6.
      
      As commit 46bbe5c6 ("tracing: fix double free") said, the
      "double free" problem reported by clang static analyzer is:
        > In parse_var_defs() if there is a problem allocating
        > var_defs.expr, the earlier var_defs.name is freed.
        > This free is duplicated by free_var_defs() which frees
        > the rest of the list.
      
      However, if there is a problem allocating N-th var_defs.expr:
        + in parse_var_defs(), the freed 'earlier var_defs.name' is
          actually the N-th var_defs.name;
        + then in free_var_defs(), the names from 0th to (N-1)-th are freed;
      
                              IF ALLOCATING PROBLEM HAPPENED HERE!!! -+
                                                                       \
                                                                        |
                0th           1th                 (N-1)-th      N-th    V
                +-------------+-------------+-----+-------------+-----------
      var_defs: | name | expr | name | expr | ... | name | expr | name | ///
                +-------------+-------------+-----+-------------+-----------
      
      These two frees don't act on same name, so there was no "double free"
      problem before. Conversely, after that commit, we get a "memory leak"
      problem because the above "N-th var_defs.name" is not freed.
      
      If enable CONFIG_DEBUG_KMEMLEAK and inject a fault at where the N-th
      var_defs.expr allocated, then execute on shell like:
        $ echo 'hist:key=call_site:val=$v1,$v2:v1=bytes_req,v2=bytes_alloc' > \
      /sys/kernel/debug/tracing/events/kmem/kmalloc/trigger
      
      Then kmemleak reports:
        unreferenced object 0xffff8fb100ef3518 (size 8):
          comm "bash", pid 196, jiffies 4295681690 (age 28.538s)
          hex dump (first 8 bytes):
            76 31 00 00 b1 8f ff ff                          v1......
          backtrace:
            [<0000000038fe4895>] kstrdup+0x2d/0x60
            [<00000000c99c049a>] event_hist_trigger_parse+0x206f/0x20e0
            [<00000000ae70d2cc>] trigger_process_regex+0xc0/0x110
            [<0000000066737a4c>] event_trigger_write+0x75/0xd0
            [<000000007341e40c>] vfs_write+0xbb/0x2a0
            [<0000000087fde4c2>] ksys_write+0x59/0xd0
            [<00000000581e9cdf>] do_syscall_64+0x3a/0x80
            [<00000000cf3b065c>] entry_SYSCALL_64_after_hwframe+0x46/0xb0
      
      Link: https://lkml.kernel.org/r/20220711014731.69520-1-zhengyejian1@huawei.com
      
      Cc: stable@vger.kernel.org
      Fixes: 46bbe5c6
      
       ("tracing: fix double free")
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Suggested-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Reviewed-by: default avatarTom Zanussi <tom.zanussi@linux.intel.com>
      Signed-off-by: default avatarZheng Yejian <zhengyejian1@huawei.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      eb622d55
    • Juergen Gross's avatar
      xen/netback: avoid entering xenvif_rx_next_skb() with an empty rx queue · 5a071aef
      Juergen Gross authored
      commit 94e81006 upstream.
      
      xenvif_rx_next_skb() is expecting the rx queue not being empty, but
      in case the loop in xenvif_rx_action() is doing multiple iterations,
      the availability of another skb in the rx queue is not being checked.
      
      This can lead to crashes:
      
      [40072.537261] BUG: unable to handle kernel NULL pointer dereference at 0000000000000080
      [40072.537407] IP: xenvif_rx_skb+0x23/0x590 [xen_netback]
      [40072.537534] PGD 0 P4D 0
      [40072.537644] Oops: 0000 [#1] SMP NOPTI
      [40072.537749] CPU: 0 PID: 12505 Comm: v1-c40247-q2-gu Not tainted 4.12.14-122.121-default #1 SLE12-SP5
      [40072.537867] Hardware name: HP ProLiant DL580 Gen9/ProLiant DL580 Gen9, BIOS U17 11/23/2021
      [40072.537999] task: ffff880433b38100 task.stack: ffffc90043d40000
      [40072.538112] RIP: e030:xenvif_rx_skb+0x23/0x590 [xen_netback]
      [40072.538217] RSP: e02b:ffffc90043d43de0 EFLAGS: 00010246
      [40072.538319] RAX: 0000000000000000 RBX: ffffc90043cd7cd0 RCX: 00000000000000f7
      [40072.538430] RDX: 0000000000000000 RSI: 0000000000000006 RDI: ffffc90043d43df8
      [40072.538531] RBP: 000000000000003f R08: 000077ff80000000 R09: 0000000000000008
      [40072.538644] R10: 0000000000007ff0 R11: 00000000000008f6 R12: ffffc90043ce2708
      [40072.538745] R13: 0000000000000000 R14: ffffc90043d43ed0 R15: ffff88043ea748c0
      [40072.538861] FS: 0000000000000000(0000) GS:ffff880484600000(0000) knlGS:0000000000000000
      [40072.538988] CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033
      [40072.539088] CR2: 0000000000000080 CR3: 0000000407ac8000 CR4: 0000000000040660
      [40072.539211] Call Trace:
      [40072.539319] xenvif_rx_action+0x71/0x90 [xen_netback]
      [40072.539429] xenvif_kthread_guest_rx+0x14a/0x29c [xen_netback]
      
      Fix that by stopping the loop in case the rx queue becomes empty.
      
      Cc: stable@vger.kernel.org
      Fixes: 98f6d57c
      
       ("xen-netback: process guest rx packets in batches")
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Reviewed-by: default avatarJan Beulich <jbeulich@suse.com>
      Reviewed-by: default avatarPaul Durrant <paul@xen.org>
      Link: https://lore.kernel.org/r/20220713135322.19616-1-jgross@suse.com
      Signed-off-by: default avatarJakub Kicinski <kuba@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5a071aef
    • Meng Tang's avatar
      ALSA: hda/realtek - Fix headset mic problem for a HP machine with alc221 · c6d7d576
      Meng Tang authored
      commit 4ba5c853
      
       upstream.
      
      On a HP 288 Pro G2 MT (X9W02AV), the front mic could not be detected.
      In order to get it working, the pin configuration needs to be set
      correctly, and the ALC221_FIXUP_HP_288PRO_MIC_NO_PRESENCE fixup needs
      to be applied.
      
      Signed-off-by: default avatarMeng Tang <tangmeng@uniontech.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20220713063332.30095-1-tangmeng@uniontech.com
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6d7d576
    • Meng Tang's avatar
      ALSA: hda/conexant: Apply quirk for another HP ProDesk 600 G3 model · 2ce34f99
      Meng Tang authored
      commit d16d69bf
      
       upstream.
      
      There is another HP ProDesk 600 G3 model with the PCI SSID 103c:82b4
      that requires the quirk HP_MIC_NO_PRESENCE. Add the corresponding
      entry to the quirk table.
      
      Signed-off-by: default avatarMeng Tang <tangmeng@uniontech.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20220711101744.25189-1-tangmeng@uniontech.com
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2ce34f99
    • Meng Tang's avatar
      ALSA: hda - Add fixup for Dell Latitidue E5430 · 27fb0914
      Meng Tang authored
      commit 841bdf85
      
       upstream.
      
      Another Dell model, another fixup entry: Latitude E5430 needs the same
      fixup as other Latitude E series as workaround for noise problems.
      
      Signed-off-by: default avatarMeng Tang <tangmeng@uniontech.com>
      Cc: <stable@vger.kernel.org>
      Link: https://lore.kernel.org/r/20220712060005.20176-1-tangmeng@uniontech.com
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      27fb0914
  2. Jul 12, 2022
  3. Jul 07, 2022