Linux/Unix 主机中安装的一个或多个程序包受到一个漏洞影响，而供应商没有提供补丁程序。

  - 已修复 Linux 内核中的下列漏洞：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)

请注意，Nessus 依赖供应商报告的程序包是否存在进行判断。

Linux/Unix 主機上安裝了一個或多個受到弱點影響的套件，且供應商未提供可用的修補程式。

  - 已解決 Linux 核心中的下列弱點：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)

請注意，Nessus 依賴供應商報告的套件存在。

Linux/Unix ホストには、ベンダーが提供するパッチが利用できない脆弱性の影響を受ける複数のパッケージがインストールされています。

  - Linux カーネルでは、以下の脆弱性が解決されています: 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)

Nessus は、ベンダーによって報告されたパッケージの存在に依存していることに注意してください。

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.

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 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.

ID	Name	Product	Family	Published	Updated	Severity
245349	Linux Distros 未修补的漏洞：CVE-2022-48762	Nessus	Misc.	8/7/2025	7/17/2026	medium
245349	Linux Distros 未修補的弱點：CVE-2022-48762	Nessus	Misc.	8/7/2025	7/17/2026	medium
245349	Linux Distros のパッチ未適用の脆弱性: CVE-2022-48762	Nessus	Misc.	8/7/2025	7/17/2026	medium
245349	Linux Distros Unpatched Vulnerability : CVE-2022-48762	Nessus	Misc.	8/7/2025	7/17/2026	medium
308872	Unity Linux 20.1060e / 20.1070e Security Update: kernel (UTSA-2026-010679)	Nessus	Unity Linux Local Security Checks	4/21/2026	4/21/2026	medium
309272	Unity Linux 20.1070a Security Update: kernel (UTSA-2026-013499)	Nessus	Unity Linux Local Security Checks	4/22/2026	4/22/2026	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium

medium

medium