TOML: check nesting depth (CVE-2023-3894)

[pjfanning]

• TOML code has no ReadContext so I'm just tracking depth using an int

[yawkat]

this seems like a better fix than #395. the only thing i'm concerned about is the difference of toml to the other formats. someone using only the streaming apis might set the max stream depth fairly high because they think they cannot run into the data binding issues it exists to avoid. however with toml, the depth limit is critical for streaming as well (since there is no real streaming for toml), not just for binding.

but this is probably not a realistic issue, so this still seems superior.

[yawkat]

@pjfanning i dont think the nesting check is necessary? it should be caught by the parser, every start token will have a pollExpected with the corresponding end token

[pjfanning]

@yawkat I'll probably remove the check. I just wanted to see if there were any existing tests where the depth misbehaves. I'll leave the check there for the moment but as I say, I'm likely to remove it before merging.

[yawkat]

maybe it can be an assert and oss-fuzz can tell us if there's any case where my assumption is violated :)

[cowtowncoder]

LGTM, but wanted to make sure this is to be merged -- anything else to wait for, change? LMK and I'll merge it to 2.15, master.

[pjfanning]

it's ok to merge - I'll follow up with more tests in another PR

[cowtowncoder]

Ok managed to merge to master; was bit hairy but all tests pass so I think that's ok.