Skip to content
Snippets Groups Projects
  1. Mar 17, 2022
    • Paul Moore's avatar
      audit: improve audit queue handling when "audit=1" on cmdline · 1518b80b
      Paul Moore authored
      mainline inclusion
      from mainline-v5.17-rc3
      commit f26d04331360d42dbd6b58448bd98e4edbfbe1c5
      category: bugfix
      bugzilla: 186384 https://gitee.com/openeuler/kernel/issues/I4X1AI?from=project-issue
      
      
      CVE: NA
      
      --------------------------------
      
      When an admin enables audit at early boot via the "audit=1" kernel
      command line the audit queue behavior is slightly different; the
      audit subsystem goes to greater lengths to avoid dropping records,
      which unfortunately can result in problems when the audit daemon is
      forcibly stopped for an extended period of time.
      
      This patch makes a number of changes designed to improve the audit
      queuing behavior so that leaving the audit daemon in a stopped state
      for an extended period does not cause a significant impact to the
      system.
      
      - kauditd_send_queue() is now limited to looping through the
        passed queue only once per call.  This not only prevents the
        function from looping indefinitely when records are returned
        to the current queue, it also allows any recovery handling in
        kauditd_thread() to take place when kauditd_send_queue()
        returns.
      
      - Transient netlink send errors seen as -EAGAIN now cause the
        record to be returned to the retry queue instead of going to
        the hold queue.  The intention of the hold queue is to store,
        perhaps for an extended period of time, the events which led
        up to the audit daemon going offline.  The retry queue remains
        a temporary queue intended to protect against transient issues
        between the kernel and the audit daemon.
      
      - The retry queue is now limited by the audit_backlog_limit
        setting, the same as the other queues.  This allows admins
        to bound the size of all of the audit queues on the system.
      
      - kauditd_rehold_skb() now returns records to the end of the
        hold queue to ensure ordering is preserved in the face of
        recent changes to kauditd_send_queue().
      
      Cc: stable@vger.kernel.org
      Fixes: 5b52330b ("audit: fix auditd/kernel connection state tracking")
      Fixes: f4b3ee3c85551 ("audit: improve robustness of the audit queue handling")
      Reported-by: default avatarGaosheng Cui <cuigaosheng1@huawei.com>
      Tested-by: default avatarGaosheng Cui <cuigaosheng1@huawei.com>
      Reviewed-by: default avatarRichard Guy Briggs <rgb@redhat.com>
      Signed-off-by: default avatarPaul Moore <paul@paul-moore.com>
      Signed-off-by: default avatarCui GaoSheng <cuigaosheng1@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      1518b80b
    • Cui GaoSheng's avatar
      Revert "audit: bugfix for infinite loop when flush the hold queue" · a9140c08
      Cui GaoSheng authored
      hulk inclusion
      category: bugfix
      bugzilla: 186384 https://gitee.com/openeuler/kernel/issues/I4X1AI?from=project-issue
      
      
      CVE: NA
      
      --------------------------------
      
      This reverts commit 67ab712f.
      
      Signed-off-by: default avatarCui GaoSheng <cuigaosheng1@huawei.com>
      Reviewed-by: default avatarXiu Jianfeng <xiujianfeng@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      a9140c08
    • Daniel Borkmann's avatar
      veth: Do not record rx queue hint in veth_xmit · 2632c58b
      Daniel Borkmann authored
      
      stable inclusion
      from linux-4.19.226
      commit bd6e97e2b6f59a19894c7032a83f03ad38ede28e
      
      --------------------------------
      
      commit 710ad98c363a66a0cd8526465426c5c5f8377ee0 upstream.
      
      Laurent reported that they have seen a significant amount of TCP retransmissions
      at high throughput from applications residing in network namespaces talking to
      the outside world via veths. The drops were seen on the qdisc layer (fq_codel,
      as per systemd default) of the phys device such as ena or virtio_net due to all
      traffic hitting a _single_ TX queue _despite_ multi-queue device. (Note that the
      setup was _not_ using XDP on veths as the issue is generic.)
      
      More specifically, after edbea9220251 ("veth: Store queue_mapping independently
      of XDP prog presence") which made it all the way back to v4.19.184+,
      skb_record_rx_queue() would set skb->queue_mapping to 1 (given 1 RX and 1 TX
      queue by default for veths) instead of leaving at 0.
      
      This is eventually retained and callbacks like ena_select_queue() will also pick
      single queue via netdev_core_pick_tx()'s ndo_select_queue() once all the traffic
      is forwarded to that device via upper stack or other means. Similarly, for others
      not implementing ndo_select_queue() if XPS is disabled, netdev_pick_tx() might
      call into the skb_tx_hash() and check for prior skb_rx_queue_recorded() as well.
      
      In general, it is a _bad_ idea for virtual devices like veth to mess around with
      queue selection [by default]. Given dev->real_num_tx_queues is by default 1,
      the skb->queue_mapping was left untouched, and so prior to edbea9220251 the
      netdev_core_pick_tx() could do its job upon __dev_queue_xmit() on the phys device.
      
      Unbreak this and restore prior behavior by removing the skb_record_rx_queue()
      from veth_xmit() altogether.
      
      If the veth peer has an XDP program attached, then it would return the first RX
      queue index in xdp_md->rx_queue_index (unless configured in non-default manner).
      However, this is still better than breaking the generic case.
      
      Fixes: edbea9220251 ("veth: Store queue_mapping independently of XDP prog presence")
      Fixes: 638264dc ("veth: Support per queue XDP ring")
      Reported-by: default avatarLaurent Bernaille <laurent.bernaille@datadoghq.com>
      Signed-off-by: default avatarDaniel Borkmann <daniel@iogearbox.net>
      Cc: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
      Cc: Toshiaki Makita <toshiaki.makita1@gmail.com>
      Cc: Eric Dumazet <eric.dumazet@gmail.com>
      Cc: Paolo Abeni <pabeni@redhat.com>
      Cc: John Fastabend <john.fastabend@gmail.com>
      Cc: Willem de Bruijn <willemb@google.com>
      Acked-by: default avatarJohn Fastabend <john.fastabend@gmail.com>
      Reviewed-by: default avatarEric Dumazet <edumazet@google.com>
      Acked-by: default avatarToshiaki Makita <toshiaki.makita1@gmail.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Conflicts:
      	drivers/net/veth.c
      Signed-off-by: default avatarZiyang Xuan <william.xuanziyang@huawei.com>
      Reviewed-by: default avatarWei Yongjun <weiyongjun1@huawei.com>
      Signed-off-by: default avatarLaibin Qiu <qiulaibin@huawei.com>
      2632c58b
  2. Mar 15, 2022
  3. Mar 14, 2022