[Fix]: integer overflow in JumpTable.SubStr

[nan01ab]

Description

Fix integer overflow in JumpTable.SubStr

Fixes #3495

Type of change

• Optimization (the change is only an optimization)
• Style (the change is only a code style for better maintenance or standard purpose)
• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

[cschuchardt88]

@shargon why isn't there a vm limit in this

[roman-khimov]

I'd also add some tests for INT64, like:

                byte(opcode.PUSHINT64), 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0x7F,
                byte(opcode.PUSH2),

It'll fail (in NeoGo it's at instruction 22 (SUBSTR): not an int32), but just to make sure.

[shargon]

Rebase needed

[shargon]

I think we don't need a HF, previously could be a DoS but not difference in the execution. Isn't it? @roman-khimov

[roman-khimov]

That's the question of "can we arrange a set of parameters that would fail with the new code, but succeed with the old one". This requires some probing. I'm not exactly sure of Rent details and how this can be related to machine memory available (I can malloc() more memory than I have physically), also how Slice() reacts to negative count.

I'd include it into Echidna for safety reasons, but if we can prove it can't be exploited to change execution result then OK, it can go without a HF.

[nan01ab]

I think we don't need a HF, previously could be a DoS but not difference in the execution. Isn't it? @roman-khimov

I agree. Don't need a HF

The base branch was changed.

The base branch was changed.

[shargon]

If doesn't use HF should go to master

[Jim8y]

If doesn't use HF should go to master

it was merged with hardfork prs,,,,lets discuss it in the meeting.

[cschuchardt88]

This is the already the default behavior in dotnet https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-options/language#checkforoverflowunderflow

[roman-khimov]

The default value for this option is false, that is, overflow checking is disabled.

https://dotnetfiddle.net/I7RINu

[cschuchardt88]

The default value for this option is false, that is, overflow checking is disabled.

https://dotnetfiddle.net/I7RINu

my bad -- integral-type arithmetic operations and conversions are executed in an unchecked context and Constant expressions are evaluated by default in a checked context.

[shargon]

I think is not required, but you think that it is, here is the solution, jump table allow it :)

[cschuchardt88]

@shargon
Object reference not set to an instance of an object.

on test Neo.UnitTests.SmartContract.UT_NotifyEventArgs.TestIssue3300

[shargon]

Snapshot is null?

[cschuchardt88]

Could be snapshot or GetInteroperable<HashIndexState>()

neo/src/Neo/SmartContract/Native/LedgerContract.cs

Lines 119 to 122 in eb96d14

	public uint CurrentIndex(DataCache snapshot)
	{
	return snapshot[CreateStorageKey(Prefix_CurrentBlock)].GetInteroperable<HashIndexState>().Index;
	}

[shargon]

If is snapshot we can return 0, otherwise we should fix the test

[cschuchardt88]

Would this work for CurrentIndex?

snapshot?[CreateStorageKey(Prefix_CurrentBlock)]?.GetInteroperable<HashIndexState>()?.Index ?? 0; 

[shargon]

We should not change the logic in native contracts for this