In the Linux kernel, the following vulnerability has been resolved:

RDMA/hfi1: Prevent panic when SDMA is disabled

If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is:

sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64

The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL.

In the Linux kernel, the following vulnerability has been resolved:

RDMA/hfi1: Prevent panic when SDMA is disabled

If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is:

sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64

The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL.

Affected: openEuler:20.03-LTS-SP4: kernel

The Linux Kernel, the operating system core itself. Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved:

can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ context

If a driver calls can_get_echo_skb() during a hardware IRQ (which is often, but not always, the case), the 'WARN_ON(in_irq)' in net/core/skbuff.c#skb_release_head_state() might be triggered, under network congestion circumstances, together with the potential risk of a NULL pointer dereference.

The root cause of this issue is the call to kfree_skb() instead of dev_kfree_skb_irq() in net/core/dev.c#enqueue_to_backlog().

This patch prevents the skb to be freed within the call to netif_rx() by incrementing its reference count with skb_get(). The skb is finally freed by one of the in-irq-context safe functions: dev_consume_skb_any() or dev_kfree_skb_any(). The "any" version is used because some drivers might call can_get_echo_skb() in a normal context.

The reason for this issue to occur is that initially, in the core network stack, loopback skb were not supposed to be received in hardware IRQ context. The CAN stack is an exeption.

This bug was previously reported back in 2017 in [1] but the proposed patch never got accepted.

While [1] directly modifies net/core/dev.c, we try to propose here a smoother modification local to CAN network stack (the assumption behind is that only CAN devices are affected by this issue).

[1] http://lore.kern…

hw: cpu: AMD CPUs may transiently execute beyond unconditional direct branch kernel: ext4: kernel bug in ext4_write_inline_data_end() kernel: malicious data for FBIOPUT_VSCREENINFO ioctl may cause OOB write memory kernel: hwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs kernel: mlxsw: thermal: Fix out-of-bounds memory accesses kernel: mlxsw: spectrum: Protect driver from buggy firmware kernel: net: stmmac: fix tc flower deletion for VLAN priority Rx steering kernel: can: etas_es58x: es58x_rx_err_msg(): fix memory leak in error path kernel: possible race condition in drivers/tty/tty_buffers.c kernel: KVM: NULL pointer dereference in kvm_mmu_invpcid_gva kernel: use-after-free in free_pipe_info() could lead to privilege escalation kernel: KVM: nVMX: missing IBPB when exiting from nested guest can lead to Spectre v2 attacks kernel: netfilter: nf_conntrack_irc message handling issue kernel: race condition in xfrm_probe_algs can lead to OOB read/write kernel: out-of-bounds read in fib_nh_match of the file net/ipv4/fib_semantics.c kernel: race condition in hugetlb_no_page() in mm/hugetlb.c kernel: memory leak in ipv6_renew_options() kernel: data races around icsk->icsk_af_ops in do_ipv6_setsockopt kernel: data races around sk->sk_prot kernel: memory leak in l2cap_recv_acldata of the file net/bluetooth/l2cap_core.c kernel: denial of service in follow_page_pte in mm/gup.c due to poisoned pte entry kernel: use-after-free after failed devlink relo…

Security update for the Linux Kernel

Affected: Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux-aws-hwe, Ubuntu:Pro:16.04:LTS: linux-azure, Ubuntu:Pro:16.04:LTS: linux-gcp, Ubuntu:Pro:16.04:LTS: linux-hwe, Ubuntu:Pro:16.04:LTS: linux-oracle, Ubuntu:Pro:16.04:LTS: linux and 144 more

In the Linux kernel, the following vulnerability has been resolved: RDMA/hfi1: Prevent panic when SDMA is disabled If the hfi1 module is loaded with HFI1_CAP_SDMA off, a call to hfi1_write_iter() will dereference a NULL pointer and panic. A typical stack frame is: sdma_select_user_engine [hfi1] hfi1_user_sdma_process_request [hfi1] hfi1_write_iter [hfi1] do_iter_readv_writev do_iter_write vfs_writev do_writev do_syscall_64 The fix is to test for SDMA in hfi1_write_iter() and fail the I/O with EINVAL.