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

vfio: Split migration ops from main device ops

vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op.

However, currently mlx5 driver sets the above ops without regards to its migration caps.

This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case.

The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable.

As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags.

HISI driver was changed as well to match this scheme.

This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps.

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

vfio: Split migration ops from main device ops

vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op.

However, currently mlx5 driver sets the above ops without regards to its migration caps.

This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case.

The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable.

As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags.

HISI driver was changed as well to match this scheme.

This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps.

kernel: seg6: fix the iif in the IPv6 socket control block Kernel: race when faulting a device private page in memory manager kernel: use-after-free in l1oip timer handlers kernel: Rate limit overflow messages in r8152 in intr_callback kernel: vmwgfx: use-after-free in vmw_cmd_res_check kernel: vmwgfx: use-after-free in vmw_execbuf_tie_context hw: Intel: Gather Data Sampling (GDS) side channel vulnerability kernel: Information leak in l2cap_parse_conf_req in net/bluetooth/l2cap_core.c kernel: perf: Fix perf_pending_task() UaF kernel: gpiolib: fix memory leak in gpiochip_setup_dev() kernel: memcg: fix possible use-after-free in memcg_write_event_control() kernel: mm/khugepaged: invoke MMU notifiers in shmem/file collapse paths kernel: char: tpm: Protect tpm_pm_suspend with locks kernel: ixgbevf: Fix resource leak in ixgbevf_init_module() kernel: dax: make sure inodes are flushed before destroy cache kernel: watch_queue: Actually free the watch kernel: watch_queue: Fix NULL dereference in error cleanup kernel: rtc: pl031: fix rtc features null pointer dereference kernel: tpm: fix reference counting for struct tpm_chip kernel: NFSv4: Don't hold the layoutget locks across multiple RPC calls kernel: xprtrdma: treat all calls not a bcall when bc_serv is NULL kernel: net: ipv6: unexport __init-annotated seg6_hmac_init() kernel: af_unix: Fix a data-race in unix_dgram_peer_wake_me(). kernel: regulator: scmi: Fix refcount leak in scmi_regulator_probe kernel: mm/mempolicy: fix uninit-v…

Security update for the Linux Kernel

Affected: Ubuntu:16.04:LTS: linux-hwe-edge, Ubuntu:18.04:LTS: linux-aws-5.0, Ubuntu:18.04:LTS: linux-aws-5.3, Ubuntu:18.04:LTS: linux-azure, Ubuntu:18.04:LTS: linux-azure-5.3, Ubuntu:18.04:LTS: linux-azure-edge, Ubuntu:18.04:LTS: linux-gcp, Ubuntu:18.04:LTS: linux-gcp-5.3, Ubuntu:18.04:LTS: linux-gke-4.15, Ubuntu:18.04:LTS: linux-gke-5.4 and 71 more

In the Linux kernel, the following vulnerability has been resolved: vfio: Split migration ops from main device ops vfio core checks whether the driver sets some migration op (e.g. set_state/get_state) and accordingly calls its op. However, currently mlx5 driver sets the above ops without regards to its migration caps. This might lead to unexpected usage/Oops if user space may call to the above ops even if the driver doesn't support migration. As for example, the migration state_mutex is not initialized in that case. The cleanest way to manage that seems to split the migration ops from the main device ops, this will let the driver setting them separately from the main ops when it's applicable. As part of that, validate ops construction on registration and include a check for VFIO_MIGRATION_STOP_COPY since the uAPI claims it must be set in migration_flags. HISI driver was changed as well to match this scheme. This scheme may enable down the road to come with some extra group of ops (e.g. DMA log) that can be set without regards to the other options based on driver caps.

Ein lokaler Angreifer kann mehrere Schwachstellen in Linux Kernel ausnutzen, um einen Denial of Service Angriff durchzuführen.