Skip to content
Snippets Groups Projects
Select Git revision
  • 0dd8c3626a80547e7f2e37af881bfcfec81414c5
  • branchX default protected
  • Inventory
  • UIControls
  • fsv2
  • tonetest
  • from_nb
  • tonemapping
  • opt-shadows
  • BX-634
  • xCSG
  • hc
  • gizmos
  • gui2CSSLexer
  • msExporter
  • gui2
  • gui2Fix
  • master protected
  • pk
  • mesh_optimize
  • light_wip
  • version_X.11.2 protected
  • version_X.11.1 protected
  • version_X.11.1-dev protected
  • version_X.11.0-dev protected
  • version_X.10.1 protected
  • version_X.10.1-dev protected
  • version_X.10.0-dev protected
  • version_X.9.5 protected
  • version_X.9.4 protected
  • version_X.9.3 protected
  • version_X.9.3-dev protected
  • version_X.9.2-dev protected
  • version_X.9.1-dev protected
  • version_X.9.0-dev protected
  • version_X.8.2 protected
  • version_X.8.2-dev protected
  • version_X.8.1-dev protected
  • version_X.8.0-dev protected
  • version_X.7.1 protected
  • version_X.7.0 protected
41 results

vs2013

user avatar
Miss Islington (bot) authored and GitHub committed
Converting a large enough `int` to a decimal string raises `ValueError` as expected. However, the raise comes _after_ the quadratic-time base-conversion algorithm has run to completion. For effective DOS prevention, we need some kind of check before entering the quadratic-time loop. Oops! =)

The quick fix: essentially we catch _most_ values that exceed the threshold up front. Those that slip through will still be on the small side (read: sufficiently fast), and will get caught by the existing check so that the limit remains exact.

The justification for the current check. The C code check is:
```c
max_str_digits / (3 * PyLong_SHIFT) <= (size_a - 11) / 10
```

In GitHub markdown math-speak, writing $M$ for `max_str_digits`, $L$ for `PyLong_SHIFT` and $s$ for `size_a`, that check is:
$$\left\lfloor\frac{M}{3L}\right\rfloor \le \left\lfloor\frac{s - 11}{10}\right\rfloor$$

From this it follows that
$$\frac{M}{3L} < \frac{s-1}{10}$$
hence that
$$\frac{L(s-1)}{M} > \frac{10}{3} > \log_2(10).$$
So
$$2^{L(s-1)} > 10^M.$$
But our input integer $a$ satisfies $|a| \ge 2^{L(s-1)}$, so $|a|$ is larger than $10^M$. This shows that we don't accidentally capture anything _below_ the intended limit in the check.

<!-- gh-issue-number: gh-95778 -->
* Issue: gh-95778
<!-- /gh-issue-number -->

Co-authored-by: default avatarGregory P. Smith [Google LLC] <greg@krypto.org>
(cherry picked from commit b1261968)

Co-authored-by: default avatarMark Dickinson <dickinsm@gmail.com>
8a776d1d
History
Name Last commit Last update
..