Launchpad has imported 6 comments from the remote bug at
https://bugs.acpica.org/show_bug.cgi?id=1545.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2021-08-31T16:14:47+00:00 Colin Ian King wrote:

Source: source/components/dispatcher/dswexec.c
Function: AcpiDsExecEndOp

The following call can be problematic if OpType is out of range:

        if (ACPI_SUCCESS (Status))
        {
            /*
             * Dispatch the request to the appropriate interpreter handler
             * routine. There is one routine per opcode "type" based upon the
             * number of opcode arguments and return type.
             */
            Status = AcpiGbl_OpTypeDispatch[OpType] (WalkState);
        }

It has been observed that an invalid OpType in the Linux kernel has
triggered a trap where and out of range OpType was caught at run time.
Newer versions of gcc generate a trap on an out of range dispatch call
with a ud2 opcode causing kernel oopses such as:

[ 11.507260] RIP: 0010:acpi_ds_exec_end_op+0x187/0x774
[ 11.508771] Code: 77 28 48 8b 04 c5 00 9b ea 91 48 89 df ff d0 0f 1f 00 41 89 
c4 e9 8f 00 00 00 0f b6 43 0d 8d 50 ff 48 63 d2 48 83 fa 09 76 02 <0f> 0b 83 c0 
6c 0f b7 7b 0a 48 89 da 48 98 48 8d 34 c3 e8 c0 3c 01
[ 11.511898] RSP: 0018:ffffaaeca1a776e0 EFLAGS: 00010286
[ 11.513428] RAX: 0000000000000000 RBX: ffff8f08a7573800 RCX: 0000000000000040
[ 11.514972] RDX: ffffffffffffffff RSI: ffffffff91ea9980 RDI: 00000000000002cb
[ 11.516100] RBP: ffffaaeca1a77710 R08: 0000000000000000 R09: ffff8f08a8c84af0
[ 11.517479] R10: 0000000000000000 R11: 0000000000000003 R12: 0000000000000000
[ 11.518985] R13: ffff8f08a8c84af0 R14: 0000000000000000 R15: 0000000000000000
[ 11.520425] FS: 00007f7fb403ed00(0000) GS:ffff8f348d5c0000(0000) 
knlGS:0000000000000000
[ 11.521931] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 11.523424] CR2: 00007f7fb38d1918 CR3: 0000000129b6a002 CR4: 00000000007706e0
[ 11.524924] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 11.526221] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 11.527636] PKRU: 55555554
[ 11.528820] Call Trace:
[ 11.529807] acpi_ps_parse_loop+0x587/0x660
[ 11.531198] acpi_ps_parse_aml+0x1af/0x552
[ 11.532595] acpi_ps_execute_method+0x208/0x2ca
[ 11.533972] acpi_ns_evaluate+0x34e/0x4f0
[ 11.535361] acpi_evaluate_object+0x18e/0x3b4
[ 11.536736] acpi_evaluate_dsm+0xb3/0x120
[ 11.537943] ? acpi_evaluate_dsm+0xb3/0x120
[ 11.539214] nfit_intel_shutdown_status+0xed/0x1b0 [nfit]
[ 11.540603] acpi_nfit_add_dimm+0x3cb/0x670 [nfit]
[ 11.541990] acpi_nfit_register_dimms+0x141/0x460 [nfit]
[ 11.543377] acpi_nfit_init+0x54f/0x620 [nfit]
[ 11.544755] acpi_nfit_add+0x192/0x1f0 [nfit]
[ 11.546116] acpi_device_probe+0x49/0x170

I strongly suggest sanity out-of-bounds checks on the OpType before
calling the dispatcher.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942215/comments/6

------------------------------------------------------------------------
On 2021-09-07T12:04:29+00:00 Colin Ian King wrote:

There is a similar array underflow error in the code here:

        if (!(WalkState->OpInfo->Flags & AML_NO_OPERAND_RESOLVE))
        {
            /* Resolve all operands */

            Status = AcpiExResolveOperands (WalkState->Opcode,
                &(WalkState->Operands [WalkState->NumOperands -1]),
                WalkState);
        }

WalkState->NumOperands - 1 in one specific case is -1 causing an oops.

See: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942215 -
comment #8.  A check something like the following is required:

if (walk_state->num_operands - 1 >= ARRAY_SIZE(walk_state->operands)) {
   ACPI_ERROR((AE_INFO, " many operands 0x%X for op_type 0x%X", 
walk_state->num_operands - 1, op_type));
   status = AE_AML_BAD_OPCODE;
   goto cleanup;
}

..perhaps a walk_state->num_operands < 1 check is required to as the
above fix handles the 0 - 1 > 0xffffffff wraparound as too many args.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942215/comments/12

------------------------------------------------------------------------
On 2021-09-07T14:57:06+00:00 Robert Moore wrote:

Colin,
I think there are many places where an invalid opcode will cause problems - it 
is simply such a serious problem that it is nearly impossible to catch all of 
the possible problems created.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942215/comments/14

------------------------------------------------------------------------
On 2021-09-07T15:38:25+00:00 Robert Moore wrote:

In any case, the the DSDT that is posted in comment #4 show the problem?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942215/comments/15

------------------------------------------------------------------------
On 2021-09-07T16:05:59+00:00 Colin Ian King wrote:

I realize that broken AML will exist, but I do think range checking on
invalid data that will cause array out of bounds errors is useful.  I
suspect we will see  more of these errors when distros enable run-time
sanitizer checks such as CONFIG_UBSAN in Linux.

It's also not impossible to do. In a previous role I worked in input bit
checking on an mpeg2 decoder so that no out of range corrupted or
invalid data would cause out of range lookups with minimal performance
overhead. Took me months, but it we did fix a whole set if bugs that
made the code more input resilient.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942215/comments/16

------------------------------------------------------------------------
On 2021-09-07T16:26:04+00:00 Colin Ian King wrote:

I realize that broken AML will exist, but I do think range checking on
invalid data that will cause array out of bounds errors is useful.  I
suspect we will see  more of these errors when distros enable run-time
sanitizer checks such as CONFIG_UBSAN in Linux.

It's also not impossible to do. In a previous role I worked in input bit
checking on an mpeg2 decoder so that no out of range corrupted or
invalid data would cause out of range lookups with minimal performance
overhead. Took me months, but it we did fix a whole set if bugs that
made the code more input resilient.

Yes, the DSDT tripped the issue in question.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1942215/comments/17


** Changed in: linux
       Status: Unknown => In Progress

** Changed in: linux
   Importance: Unknown => Wishlist

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1942215

Title:
  OOPs on boot: invalid opcode: 0000 [#1] SMP NOPTI

To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/1942215/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to