Chromium

Ah this is kind of funny: we found this through our sandbox fuzzer, but it doesn't require any up-front heap corruption (as would normally be the case for a V8 sandbox violation). So this actually is a "real" vulnerability, and I'm therefore not adjusting the labels (as I would for a "regular" sandbox violation). It's still also a sandbox violation though, and I think the first one that can directly be triggered from JavaScript.

Simplified repro

function g() { }

function f() {
  // We need a CallOp that is 516 bytes large. CallOp itself is 24 bytes. So we
  // need 516-24=492 bytes of inputs, with 4 bytes per input, this amounts to
  // 492/4 = 123 inputs.

  // JS calls in Turboshaft always have 6 additional inputs (target, frame
  // state, context, number of arguments...), so we write a JS call with 117
  // inputs to reach the 123 inputs required for CallOp.
  g(  1,   2,   3,   4,   5,   6,   7,   8,   9,  10,  11,  12,  13,  14,
     15,  16,  17,  18,  19,  20,  21,  22,  23,  24,  25,  26,  27,  28,
     29,  30,  31,  32,  33,  34,  35,  36,  37,  38,  39,  40,  41,  42,
     43,  44,  45,  46,  47,  48,  49,  50,  51,  52,  53,  54,  55,  56,
     57,  58,  59,  60,  61,  62,  63,  64,  65,  66,  67,  68,  69,  70,
     71,  72,  73,  74,  75,  76,  77,  78,  79,  80,  81,  82,  83,  84,
     85,  86,  87,  88,  89,  90,  91,  92,  93,  94,  95,  96,  97,  98,
     99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112,
    113, 114, 115, 116, 117);
}

%PrepareFunctionForOptimization(f);
f();
%OptimizeFunctionOnNextCall(f);
f();

Replies to Comment 11:

1. https://chromium-review.googlesource.com/c/v8/v8/+/5400799

2. Not on Canary yet (it landed earlier today in V8, should be in Chrome soonish, so it makes sense to wait a few days to merge)

3. no

4. no

5. no

Additional comment: I'm not sure how exploitable this is, and I'd expect that the risk is more on the stability side rather than security side. That being said, I'm not aware of any crashes that are caused by this. So, I'm not sure how important it is to backmerge "far". Backmerging to Beta seems like it doesn't cost much so why not. Further than that, I don't know.

Thanks for your input here, Darius -- much appreciated. Based on Samuel's assessment in comment #6 and that we are going to be considering the sandbox as somewhat of an (slowly expanding) security boundary soon and bypasses will soon be VRP eligible (with a specific scope), also also given what we have seen achieved in pwn2own recently with some sandbox bypasses, I'm think it would be a good idea of consider this one for backmerge. That being said, since we are in the middle of Stable 123 and Extended 122 presently, I think erring on the side of caution and backmering only to Beta as you suggested is a good idea and compromise in the risk::reward considerations.

All that being said, yes, let's also make sure this gets sufficient bake time on Canary and I'll revisit in a couple of days.

Replies to Comment 15:

1. security/stability issue
2. https://chromium-review.googlesource.com/c/v8/v8/+/5400799
3. on canary since yesterday
4. no
5. /
6. no

M124 merge approved for https://crrev.com/c/5400799, please merge to M124 Beta / branch 6367 at your earliest convenience / by EOD Monday so this fix can be included in Tuesday's M124 Stable Cut -- thank you

This bug has been closed for more than 14 weeks. Removing issue access restrictions.