fix: nil pointer panic on NewIntFromBigInt (backport #9627)

[mergify]

This is an automatic backport of pull request #9627 done by Mergify.
Cherry-pick of 7f90374 has failed:

On branch mergify/bp/release/v0.42.x/pr-9627
Your branch is up to date with 'origin/release/v0.42.x'.

You are currently cherry-picking commit 7f9037490.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   types/int.go
	modified:   types/int_test.go

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   CHANGELOG.md

To fix up this pull request, you can check it out locally. See documentation: https://help.github.com/articles/checking-out-pull-requests-locally/

---

Mergify commands and options

More conditions and actions can be found in the documentation.

You can also trigger Mergify actions by commenting on this pull request:

• @Mergifyio refresh will re-evaluate the rules
• @Mergifyio rebase will rebase this PR on its base branch
• @Mergifyio update will merge the base branch into this PR
• @Mergifyio backport <destination> will backport this PR on <destination> branch

Additionally, on Mergify dashboard you can:

• look at your merge queues
• generate the Mergify configuration with the config editor.

Finally, you can contact us on https://mergify.io/

[tomtau]

is this a consensus-breaking change?

[tac0turtle]

is this a consensus-breaking change?

I believe so, at least it is client side breaking. @fedekunze can you test on a live chain?

[alexanderbez]

is this a consensus-breaking change?

Ehh that's difficult to say. What would once panic, would now error. So I suppose technically yes, but I think we can get this in w/o calling it state-breaking.

[tomtau]

Ehh that's difficult to say. What would once panic, would now error. So I suppose technically yes, but I think we can get this in w/o calling it state-breaking.

assuming NewIntFromBigInt gets called in tx deserialization and one manages to smuggle in (i.e. propose a block that includes this tx) a tx with a payload where this manifests... how will this differ during DeliverTX / runTx processing with and without this patch given the panic recovery middleware (or will it even reach that DeliverTX / runTx stage? won't the nodes without this patch just fail to sign on those messages, i.e. it's a potential DoS?)?

[tomtau]

assuming NewIntFromBigInt gets called in tx deserialization

this doesn't seem to be the case in SDK though -- I only see it gets called in Dec's TruncateInt and RoundInt which shouldn't pass in nil pointers (given Dec is constructed with NewDec etc.), but it'd be good to double check

[alexanderbez]

We can/should be safe here and just call this state machine breaking. Other apps may be calling this in their message execution path.

[amaury1093]

We can/should be safe here and just call this state machine breaking.

In this case I wouldn't backport it to a 0.42 patch release. I'm closing this then.