Affected: Alpaquita:23: linux-lts, Alpaquita:stream: linux-lts

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

arm64: mm: fix VA-range sanity check

Both create_mapping_noalloc() and update_mapping_prot() sanity-check their 'virt' parameter, but the check itself doesn't make much sense. The condition used today appears to be a historical accident.

The sanity-check condition:

if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }

... can only be true for the KASAN shadow region or the module region, and there's no reason to exclude these specifically for creating and updateing mappings.

When arm64 support was first upstreamed in commit:

c1cc1552616d0f35 ("arm64: MMU initialisation")

... the condition was:

if (virt < VMALLOC_START) { [ ... warning here ... ] return; }

At the time, VMALLOC_START was the lowest kernel address, and this was checking whether 'virt' would be translated via TTBR1.

Subsequently in commit:

14c127c957c1c607 ("arm64: mm: Flip kernel VA space")

... the condition was changed to:

if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }

This appear to have been a thinko. The commit moved the linear map to the bottom of the kernel address space, with VMALLOC_START being at the halfway point. The old condition would warn for changes to the linear map below this, and at the time VA_START was the end of the linear map.

Subsequently we cleaned up the naming of VA_START in commit:

77ad4ce69321abbe ("arm64…

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

arm64: mm: fix VA-range sanity check

Both create_mapping_noalloc() and update_mapping_prot() sanity-check their 'virt' parameter, but the check itself doesn't make much sense. The condition used today appears to be a historical accident.

The sanity-check condition:

if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }

... can only be true for the KASAN shadow region or the module region, and there's no reason to exclude these specifically for creating and updateing mappings.

When arm64 support was first upstreamed in commit:

c1cc1552616d0f35 ("arm64: MMU initialisation")

... the condition was:

if (virt < VMALLOC_START) { [ ... warning here ... ] return; }

At the time, VMALLOC_START was the lowest kernel address, and this was checking whether 'virt' would be translated via TTBR1.

Subsequently in commit:

14c127c957c1c607 ("arm64: mm: Flip kernel VA space")

... the condition was changed to:

if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; }

This appear to have been a thinko. The commit moved the linear map to the bottom of the kernel address space, with VMALLOC_START being at the halfway point. The old condition would warn for changes to the linear map below this, and at the time VA_START was the end of the linear map.

Subsequently we cleaned up the naming of VA_START in commit:

77ad4ce69321abbe ("arm64…

kernel: xen-netfront: Fix NULL sring after live migration kernel: fscache: Fix oops due to race with cookie_lru and use_cookie kernel: tracing: Free buffers when a used dynamic event is removed kernel: net: tun: Fix use-after-free in tun_detach() kernel: hwmon: (ibmpex) Fix possible UAF when ibmpex_register_bmc() fails kernel: erofs/zmap.c: Fix incorrect offset calculation kernel: arm64/mm: fix incorrect file_map_count for non-leaf pmd/pud kernel: s390: avoid using global register for current_stack_pointer kernel: erofs: fix missing xas_retry() in fscache mode kernel: rpmsg: qcom_smd: Fix refcount leak in qcom_smd_parse_edge kernel: remoteproc: k3-r5: Fix refcount leak in k3_r5_cluster_of_init kernel: of: check previous kernel's ima-kexec-buffer against memory bounds kernel: coresight: Clear the connection field properly kernel: Linux kernel: Denial of Service in coresight: trbe kernel: rpmsg: char: Avoid double destroy of default endpoint kernel: coresight: cti: Fix hang in cti_disable_hw() kernel: lib/fonts: fix undefined behavior in bit shift for get_default_font kernel: Kernel: Denial of Service in pci_endpoint_test due to zero-length DMA mapping kernel: Linux kernel: Denial of Service in erofs due to memory leak kernel: erofs: fix missing unmap if z_erofs_get_extent_compressedlen() fails kernel: pipe: wakeup wr_wait after setting max_usage kernel: ntb: intel: Fix the NULL vs IS_ERR() bug for debugfs_create_dir() kernel: qed/qed_sriov: guard against NULL derefs from qed_…

Security update for the Linux Kernel

Affected: Ubuntu:Pro:14.04:LTS: linux, Ubuntu:Pro:14.04:LTS: linux-aws, Ubuntu:Pro:14.04:LTS: linux-azure, Ubuntu:Pro:14.04:LTS: linux-lts-xenial, Ubuntu:Pro:16.04:LTS: linux, Ubuntu:Pro:16.04:LTS: linux-aws, 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 and 171 more

In the Linux kernel, the following vulnerability has been resolved: arm64: mm: fix VA-range sanity check Both create_mapping_noalloc() and update_mapping_prot() sanity-check their 'virt' parameter, but the check itself doesn't make much sense. The condition used today appears to be a historical accident. The sanity-check condition: if ((virt >= PAGE_END) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } ... can only be true for the KASAN shadow region or the module region, and there's no reason to exclude these specifically for creating and updateing mappings. When arm64 support was first upstreamed in commit: c1cc1552616d0f35 ("arm64: MMU initialisation") ... the condition was: if (virt < VMALLOC_START) { [ ... warning here ... ] return; } At the time, VMALLOC_START was the lowest kernel address, and this was checking whether 'virt' would be translated via TTBR1. Subsequently in commit: 14c127c957c1c607 ("arm64: mm: Flip kernel VA space") ... the condition was changed to: if ((virt >= VA_START) && (virt < VMALLOC_START)) { [ ... warning here ... ] return; } This appear to have been a thinko. The commit moved the linear map to the bottom of the kernel address space, with VMALLOC_START being at the halfway point. The old condition would warn for changes to the linear map below this, and at the time VA_START was the end of the linear map. Subsequently we cleaned up the naming of VA_START in commit: 77ad4ce69321abbe ("arm64: memory: rename…

Ein Angreifer kann mehrere Schwachstellen im Linux-Kernel ausnutzen, um nicht näher spezifizierte Angriffe durchzuführen, die möglicherweise zu einer Denial-of-Service- Bedingung führen oder eine Speicherbeschädigung verursachen können.