In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix load_unaligned_zeropad() reg indices In ex_handler_load_unaligned_zeropad() we erroneously extract the data and addr register indices from ex->type rather than ex->data. As ex->type will contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4): * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is extracted from bits [9:5]. Thus, we may attempt to dereference an arbitrary address as X0 may hold an arbitrary value. * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary behaviour within load_unaligned_zeropad() and its caller. Fix this by extracting both values from ex->data as originally intended. On an MTE-enabled QEMU image we are hitting the following crash: Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 Call trace: fixup_exception+0xc4/0x108 __do_kernel_fault+0x3c/0x268 do_tag_check_fault+0x3c/0x104 do_mem_abort+0x44/0xf4 el1_abort+0x40/0x64 el1h_64_sync_handler+0x60/0xa0 el1h_64_sync+0x7c/0x80 link_path_walk+0x150/0x344 path_openat+0xa0/0x7dc do_filp_open+0xb8/0x168 do_sys_openat2+0x88/0x17c __arm64_sys_openat+0x74/0xa0 invoke_syscall+0x48/0x148 el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0x88 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec el0t_64_sync+0x1b4/0x1b8 Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-013499 advisory.

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

    arm64: extable: fix load_unaligned_zeropad() reg indices

    In ex_handler_load_unaligned_zeropad() we erroneously extract the data and     addr register indices from ex->type rather than ex->data. As ex->type will     contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):
     * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is        extracted from bits [9:5]. Thus, we may attempt to dereference an        arbitrary address as X0 may hold an arbitrary value.
     * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is        extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary        behaviour within load_unaligned_zeropad() and its caller.

    Fix this by extracting both values from ex->data as originally intended.

    On an MTE-enabled QEMU image we are hitting the following crash:
     Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000      Call trace:
      fixup_exception+0xc4/0x108
      __do_kernel_fault+0x3c/0x268       do_tag_check_fault+0x3c/0x104       do_mem_abort+0x44/0xf4       el1_abort+0x40/0x64       el1h_64_sync_handler+0x60/0xa0       el1h_64_sync+0x7c/0x80       link_path_walk+0x150/0x344       path_openat+0xa0/0x7dc       do_filp_open+0xb8/0x168       do_sys_openat2+0x88/0x17c
      __arm64_sys_openat+0x74/0xa0       invoke_syscall+0x48/0x148       el0_svc_common+0xb8/0xf8       do_el0_svc+0x28/0x88       el0_svc+0x24/0x84       el0t_64_sync_handler+0x88/0xec       el0t_64_sync+0x1b4/0x1b8      Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Unity Linux 20 host has a package installed that is affected by a vulnerability as referenced in the UTSA-2026-010679 advisory.

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

    arm64: extable: fix load_unaligned_zeropad() reg indices

    In ex_handler_load_unaligned_zeropad() we erroneously extract the data and     addr register indices from ex->type rather than ex->data. As ex->type will     contain EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4):
     * We'll always treat X0 as the address register, since EX_DATA_REG_ADDR is        extracted from bits [9:5]. Thus, we may attempt to dereference an        arbitrary address as X0 may hold an arbitrary value.
     * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is        extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary        behaviour within load_unaligned_zeropad() and its caller.

    Fix this by extracting both values from ex->data as originally intended.

    On an MTE-enabled QEMU image we are hitting the following crash:
     Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000      Call trace:
      fixup_exception+0xc4/0x108
      __do_kernel_fault+0x3c/0x268       do_tag_check_fault+0x3c/0x104       do_mem_abort+0x44/0xf4       el1_abort+0x40/0x64       el1h_64_sync_handler+0x60/0xa0       el1h_64_sync+0x7c/0x80       link_path_walk+0x150/0x344       path_openat+0xa0/0x7dc       do_filp_open+0xb8/0x168       do_sys_openat2+0x88/0x17c
      __arm64_sys_openat+0x74/0xa0       invoke_syscall+0x48/0x148       el0_svc_common+0xb8/0xf8       do_el0_svc+0x28/0x88       el0_svc+0x24/0x84       el0t_64_sync_handler+0x88/0xec       el0t_64_sync+0x1b4/0x1b8      Code: f8695a69 71007d1f 540000e0 927df12a (f940014a)

Tenable has extracted the preceding description block directly from the Unity Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The Linux/Unix host has one or more packages installed that are impacted by a vulnerability without a vendor supplied patch available.

  - In the Linux kernel, the following vulnerability has been resolved: arm64: extable: fix     load_unaligned_zeropad() reg indices In ex_handler_load_unaligned_zeropad() we erroneously extract the     data and addr register indices from ex->type rather than ex->data. As ex->type will contain     EX_TYPE_LOAD_UNALIGNED_ZEROPAD (i.e. 4): * We'll always treat X0 as the address register, since     EX_DATA_REG_ADDR is extracted from bits [9:5]. Thus, we may attempt to dereference an arbitrary address as     X0 may hold an arbitrary value. * We'll always treat X4 as the data register, since EX_DATA_REG_DATA is     extracted from bits [4:0]. Thus we will corrupt X4 and cause arbitrary behaviour within     load_unaligned_zeropad() and its caller. Fix this by extracting both values from ex->data as originally     intended. On an MTE-enabled QEMU image we are hitting the following crash: Unable to handle kernel NULL     pointer dereference at virtual address 0000000000000000 Call trace: fixup_exception+0xc4/0x108
    __do_kernel_fault+0x3c/0x268 do_tag_check_fault+0x3c/0x104 do_mem_abort+0x44/0xf4 el1_abort+0x40/0x64     el1h_64_sync_handler+0x60/0xa0 el1h_64_sync+0x7c/0x80 link_path_walk+0x150/0x344 path_openat+0xa0/0x7dc     do_filp_open+0xb8/0x168 do_sys_openat2+0x88/0x17c __arm64_sys_openat+0x74/0xa0 invoke_syscall+0x48/0x148     el0_svc_common+0xb8/0xf8 do_el0_svc+0x28/0x88 el0_svc+0x24/0x84 el0t_64_sync_handler+0x88/0xec     el0t_64_sync+0x1b4/0x1b8 Code: f8695a69 71007d1f 540000e0 927df12a (f940014a) (CVE-2022-48762)

Note that Nessus relies on the presence of the package as reported by the vendor.

ID	Name	Product	Family	Severity
309272	Unity Linux 20.1070a Security Update: kernel (UTSA-2026-013499)	Nessus	Unity Linux Local Security Checks	medium
308872	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2026-010679)	Nessus	Unity Linux Local Security Checks	medium
245349	Linux Distros Unpatched Vulnerability : CVE-2022-48762	Nessus	Misc.	medium

Detections

Analytics

CVE-2022-48762

medium

Tenable Plugins

medium

medium

medium