| 2022-07-25 00:31:16 |
agent 8131 |
bug |
|
|
added bug |
| 2022-07-28 18:06:35 |
Lucas Kanashiro |
nominated for series |
|
Ubuntu Jammy |
|
| 2022-07-28 18:06:35 |
Lucas Kanashiro |
bug task added |
|
ruby3.0 (Ubuntu Jammy) |
|
| 2022-07-28 18:06:35 |
Lucas Kanashiro |
nominated for series |
|
Ubuntu Kinetic |
|
| 2022-07-28 18:06:35 |
Lucas Kanashiro |
bug task added |
|
ruby3.0 (Ubuntu Kinetic) |
|
| 2022-07-28 18:06:46 |
Lucas Kanashiro |
bug |
|
|
added subscriber Ubuntu Server |
| 2022-07-28 18:06:54 |
Lucas Kanashiro |
tags |
|
server-todo |
|
| 2022-07-28 18:07:00 |
Lucas Kanashiro |
ruby3.0 (Ubuntu Jammy): assignee |
|
Lucas Kanashiro (lucaskanashiro) |
|
| 2022-07-28 18:07:02 |
Lucas Kanashiro |
ruby3.0 (Ubuntu Kinetic): assignee |
|
Lucas Kanashiro (lucaskanashiro) |
|
| 2022-08-17 18:58:35 |
Lucas Kanashiro |
ruby3.0 (Ubuntu): status |
New |
Fix Released |
|
| 2022-08-17 18:58:36 |
Lucas Kanashiro |
cve linked |
|
2021-41816 |
|
| 2022-08-17 18:58:36 |
Lucas Kanashiro |
cve linked |
|
2021-41817 |
|
| 2022-08-17 18:58:36 |
Lucas Kanashiro |
cve linked |
|
2021-41819 |
|
| 2022-08-17 18:58:36 |
Lucas Kanashiro |
cve linked |
|
2022-28738 |
|
| 2022-08-17 18:58:36 |
Lucas Kanashiro |
cve linked |
|
2022-28739 |
|
| 2022-08-31 15:12:41 |
Robie Basak |
ruby3.0 (Ubuntu Jammy): importance |
Undecided |
High |
|
| 2022-08-31 15:12:43 |
Robie Basak |
ruby3.0 (Ubuntu Jammy): assignee |
Lucas Kanashiro (lucaskanashiro) |
|
|
| 2022-09-21 15:27:30 |
Christian Ehrhardt |
ruby3.0 (Ubuntu Kinetic): assignee |
Lucas Kanashiro (lucaskanashiro) |
|
|
| 2022-09-21 15:27:40 |
Christian Ehrhardt |
ruby3.0 (Ubuntu Jammy): assignee |
|
Utkarsh Gupta (utkarsh) |
|
| 2022-09-21 15:27:47 |
Christian Ehrhardt |
ruby3.0 (Ubuntu Jammy): status |
New |
Confirmed |
|
| 2022-11-14 11:44:59 |
Utkarsh Gupta |
description |
Array#slice! invalid memory access
Details are here: https://bugs.ruby-lang.org/issues/18138
Affected versions are 3.0.0, 3.0.1, 3.0.2.
Fixed in 3.0.3.
Options:
* update to 3.0.3 or higher
* backport this bug fix |
[Impact]
========
The array.c functions rb_ary_slice_bang / ary_slice_bang_by_rb_ary_splice allow a length to be passed to rb_ary_new4 that is too long and which leads to an invalid memory access. This has been fixed in Kinetic (and forward) and isn't present in releases before Jammy. So Jammy is all that's left to fix.
[Test Plan]
===========
$ lxc launch images:ubuntu/jammy jtemp --vm
$ lxc shell jtemp
# apt update && apt install valgrind ruby3.0
# touch lp1982703.rb
# echo "(1..5000).to_a.slice!(-2, 5000)" > lp1982703.rb
# valgrind ruby lp1982703.rb
You'll see:
```
==228628== Invalid read of size 8
==228628== at 0x48428C0: memmove (vg_replace_strmem.c:1271)
==228628== by 0x356542: ary_memcpy (array.c:316)
==228628== by 0x356542: rb_ary_tmp_new_from_values (array.c:785)
==228628== by 0x356542: rb_ary_new_from_values (array.c:795)
==228628== by 0x356542: ary_slice_bang_by_rb_ary_splice (array.c:4106)
==228628== by 0x35E1DB: rb_ary_slice_bang (array.c:4186)
```
and respective HEAP and LEAK SUMMARY.
[Where Problems Could Occur]
============================
The fix is a one-line, trivial patch which fixes the length calculation for Array#slice! by moving the respective check out of an if..elseif clause to its separate if clause - making sure it's checked always.
It's hard for things to go wrong further there because it was already resulting in an invalid memory access.
One thing that could go wrong is where people have made workarounds - for instance, instead of passing start, index values like Array#slice!(start, index), one would workaround this bug by changing that to Array#slice!(start..index). Even then, these things won't break because they're supposed to work irrespective but would be ideal to resort back to proper usage. |
|
| 2022-11-14 11:56:40 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~utkarsh/ubuntu/+source/ruby3.0/+git/ruby3.0/+merge/432956 |
|
| 2022-11-14 14:55:10 |
Lucas Kanashiro |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2022-11-16 14:52:32 |
Robie Basak |
ruby3.0 (Ubuntu Jammy): status |
Confirmed |
Fix Committed |
|
| 2022-11-16 14:52:34 |
Robie Basak |
bug |
|
|
added subscriber SRU Verification |
| 2022-11-16 14:52:36 |
Robie Basak |
tags |
server-todo |
server-todo verification-needed verification-needed-jammy |
|
| 2022-11-28 07:26:15 |
Christian Ehrhardt |
description |
[Impact]
========
The array.c functions rb_ary_slice_bang / ary_slice_bang_by_rb_ary_splice allow a length to be passed to rb_ary_new4 that is too long and which leads to an invalid memory access. This has been fixed in Kinetic (and forward) and isn't present in releases before Jammy. So Jammy is all that's left to fix.
[Test Plan]
===========
$ lxc launch images:ubuntu/jammy jtemp --vm
$ lxc shell jtemp
# apt update && apt install valgrind ruby3.0
# touch lp1982703.rb
# echo "(1..5000).to_a.slice!(-2, 5000)" > lp1982703.rb
# valgrind ruby lp1982703.rb
You'll see:
```
==228628== Invalid read of size 8
==228628== at 0x48428C0: memmove (vg_replace_strmem.c:1271)
==228628== by 0x356542: ary_memcpy (array.c:316)
==228628== by 0x356542: rb_ary_tmp_new_from_values (array.c:785)
==228628== by 0x356542: rb_ary_new_from_values (array.c:795)
==228628== by 0x356542: ary_slice_bang_by_rb_ary_splice (array.c:4106)
==228628== by 0x35E1DB: rb_ary_slice_bang (array.c:4186)
```
and respective HEAP and LEAK SUMMARY.
[Where Problems Could Occur]
============================
The fix is a one-line, trivial patch which fixes the length calculation for Array#slice! by moving the respective check out of an if..elseif clause to its separate if clause - making sure it's checked always.
It's hard for things to go wrong further there because it was already resulting in an invalid memory access.
One thing that could go wrong is where people have made workarounds - for instance, instead of passing start, index values like Array#slice!(start, index), one would workaround this bug by changing that to Array#slice!(start..index). Even then, these things won't break because they're supposed to work irrespective but would be ideal to resort back to proper usage. |
[Impact]
========
The array.c functions rb_ary_slice_bang / ary_slice_bang_by_rb_ary_splice allow a length to be passed to rb_ary_new4 that is too long and which leads to an invalid memory access. This has been fixed in Kinetic (and forward) and isn't present in releases before Jammy. So Jammy is all that's left to fix.
[Test Plan]
===========
$ lxc launch images:ubuntu/jammy jtemp --vm
$ lxc shell jtemp
# apt update && apt install valgrind ruby3.0
# echo '(1..5000).to_a.slice!(-2, 5000)' > lp1982703.rb
# valgrind ruby lp1982703.rb
You'll see:
```
==228628== Invalid read of size 8
==228628== at 0x48428C0: memmove (vg_replace_strmem.c:1271)
==228628== by 0x356542: ary_memcpy (array.c:316)
==228628== by 0x356542: rb_ary_tmp_new_from_values (array.c:785)
==228628== by 0x356542: rb_ary_new_from_values (array.c:795)
==228628== by 0x356542: ary_slice_bang_by_rb_ary_splice (array.c:4106)
==228628== by 0x35E1DB: rb_ary_slice_bang (array.c:4186)
```
and respective HEAP and LEAK SUMMARY.
[Where Problems Could Occur]
============================
The fix is a one-line, trivial patch which fixes the length calculation for Array#slice! by moving the respective check out of an if..elseif clause to its separate if clause - making sure it's checked always.
It's hard for things to go wrong further there because it was already resulting in an invalid memory access.
One thing that could go wrong is where people have made workarounds - for instance, instead of passing start, index values like Array#slice!(start, index), one would workaround this bug by changing that to Array#slice!(start..index). Even then, these things won't break because they're supposed to work irrespective but would be ideal to resort back to proper usage. |
|
| 2022-11-28 07:27:50 |
Christian Ehrhardt |
description |
[Impact]
========
The array.c functions rb_ary_slice_bang / ary_slice_bang_by_rb_ary_splice allow a length to be passed to rb_ary_new4 that is too long and which leads to an invalid memory access. This has been fixed in Kinetic (and forward) and isn't present in releases before Jammy. So Jammy is all that's left to fix.
[Test Plan]
===========
$ lxc launch images:ubuntu/jammy jtemp --vm
$ lxc shell jtemp
# apt update && apt install valgrind ruby3.0
# echo '(1..5000).to_a.slice!(-2, 5000)' > lp1982703.rb
# valgrind ruby lp1982703.rb
You'll see:
```
==228628== Invalid read of size 8
==228628== at 0x48428C0: memmove (vg_replace_strmem.c:1271)
==228628== by 0x356542: ary_memcpy (array.c:316)
==228628== by 0x356542: rb_ary_tmp_new_from_values (array.c:785)
==228628== by 0x356542: rb_ary_new_from_values (array.c:795)
==228628== by 0x356542: ary_slice_bang_by_rb_ary_splice (array.c:4106)
==228628== by 0x35E1DB: rb_ary_slice_bang (array.c:4186)
```
and respective HEAP and LEAK SUMMARY.
[Where Problems Could Occur]
============================
The fix is a one-line, trivial patch which fixes the length calculation for Array#slice! by moving the respective check out of an if..elseif clause to its separate if clause - making sure it's checked always.
It's hard for things to go wrong further there because it was already resulting in an invalid memory access.
One thing that could go wrong is where people have made workarounds - for instance, instead of passing start, index values like Array#slice!(start, index), one would workaround this bug by changing that to Array#slice!(start..index). Even then, these things won't break because they're supposed to work irrespective but would be ideal to resort back to proper usage. |
[Impact]
========
The array.c functions rb_ary_slice_bang / ary_slice_bang_by_rb_ary_splice allow a length to be passed to rb_ary_new4 that is too long and which leads to an invalid memory access. This has been fixed in Kinetic (and forward) and isn't present in releases before Jammy. So Jammy is all that's left to fix.
[Test Plan]
===========
$ lxc launch images:ubuntu/jammy jtemp --vm
$ lxc shell jtemp
# apt update && apt install valgrind ruby3.0
# echo '(1..5000).to_a.slice!(-2, 5000)' > lp1982703.rb
# valgrind ruby lp1982703.rb |& tee lp1982703.valgrind
# grep "Invalid read of size 8" -A4 lp1982703.valgrind
You'll see:
```
==228628== Invalid read of size 8
==228628== at 0x48428C0: memmove (vg_replace_strmem.c:1271)
==228628== by 0x356542: ary_memcpy (array.c:316)
==228628== by 0x356542: rb_ary_tmp_new_from_values (array.c:785)
==228628== by 0x356542: rb_ary_new_from_values (array.c:795)
==228628== by 0x356542: ary_slice_bang_by_rb_ary_splice (array.c:4106)
==228628== by 0x35E1DB: rb_ary_slice_bang (array.c:4186)
```
and respective HEAP and LEAK SUMMARY.
[Where Problems Could Occur]
============================
The fix is a one-line, trivial patch which fixes the length calculation for Array#slice! by moving the respective check out of an if..elseif clause to its separate if clause - making sure it's checked always.
It's hard for things to go wrong further there because it was already resulting in an invalid memory access.
One thing that could go wrong is where people have made workarounds - for instance, instead of passing start, index values like Array#slice!(start, index), one would workaround this bug by changing that to Array#slice!(start..index). Even then, these things won't break because they're supposed to work irrespective but would be ideal to resort back to proper usage. |
|
| 2022-11-29 13:21:08 |
Utkarsh Gupta |
tags |
server-todo verification-needed verification-needed-jammy |
server-todo verification-done-jammy verification-needed |
|
| 2022-12-01 09:35:42 |
Launchpad Janitor |
ruby3.0 (Ubuntu Jammy): status |
Fix Committed |
Fix Released |
|
| 2022-12-01 09:35:52 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
