| 2020-05-20 09:13:56 |
Nivedita Singhvi |
bug |
|
|
added bug |
| 2020-05-20 09:14:25 |
Nivedita Singhvi |
linux (Ubuntu): importance |
Undecided |
Critical |
|
| 2020-05-20 09:15:40 |
Nivedita Singhvi |
nominated for series |
|
Ubuntu Bionic |
|
| 2020-05-20 09:15:40 |
Nivedita Singhvi |
bug task added |
|
linux (Ubuntu Bionic) |
|
| 2020-05-20 09:15:56 |
Nivedita Singhvi |
linux (Ubuntu Bionic): importance |
Undecided |
Critical |
|
| 2020-05-20 09:18:33 |
Nivedita Singhvi |
description |
[IMPACT]
Setting an MTU larger than the default 1500 results in an
error on the recent (4.15.0-92+) Bionic/Xenial -hwe kernels
when attempting to create ipvlan interfaces:
# ip link add test0 mtu 9000 link eno1 type ipvlan mode l2
RTNETLINK answers: Invalid argument
This breaks Docker and other applications which use a Jumbo
MTU (9000) when using ipvlans.
The bug is caused by the following recent commit to Bionic
& Xenial-hwe; which is pulled in via the stable patchset below,
which enforces a strict min/max MTU when MTUs are being set up
via rtnetlink for ipvlans:
Breaking commit:
-------------------
Ubuntu-hwe-4.15.0-92.93~16.04.1
* Bionic update: upstream stable patchset 2020-02-21 (LP: #1864261)
* net: rtnetlink: validate IFLA_MTU attribute in rtnl_create_link()
The above patch applies checks of dev->min_mtu and dev->max_mtu
to avoid a malicious user from crashing the kernel with a bad
value. It was patching the original patchset to centralize min/max
MTU checking from various different subsystems of the networking
kernel. However, in that patchset, the max_mtu had not been set
to the largest phys (64K) or jumbo (9000 bytes), and defaults to
1500. The recent commit above which enforces strict bounds checking
for MTU size exposes the bug of the max mtu not being set correctly.
Fix:
-------
The missing commit in the Bionic backport is the following commit:
ipvlan: use ETH_MAX_MTU as max mtu
commit 548feb33c598dfaf9f8e066b842441ac49b84a8a
[Test Case]
1. Install any kernel earlier than 4.15.0-92 (Bionic/Xenial-hwe)
2. # ip link add test1 mtu 9000 link eno1 type ipvlan mode l2
(where test1 eno1 is the physical interface you are adding
the ipvlan on)
3. # ip link
...
14: test1@eno1: <BROADCAST,MULTICAST> mtu 9000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
...
// check that your test1 ipvlan is created with mtu 9000
4. Install 4.15.0-92 kernel or later
5. # ip link add test1 mtu 9000 link eno1 type ipvlan mode l2
RTNETLINK answers: Invalid argument
6. With the above fix commit backported to the xenial-hwe/Bionic,
the jumbo mtu ipvlan creation works again, identical to before 92.
[Regression Potential]
This commit is in upstream mainline as of v4.18-rc2, and hence
is already in Cosmic and later, i.e. all post Bionic releases
currently. Hence there's low regression potential here.
It only impacts ipvlan functionality, and not other networking
systems, so core systems should not be affected by this. And
affects on setup so it either works or doesn't. Patch is trivial.
It only impacts Bionic/Xenial-hwe 4.15.0-92 onwards versions
(where the latent bug got exposed). |
[IMPACT]
Setting an MTU larger than the default 1500 results in an
error on the recent (4.15.0-92+) Bionic/Xenial -hwe kernels
when attempting to create ipvlan interfaces:
# ip link add test0 mtu 9000 link eno1 type ipvlan mode l2
RTNETLINK answers: Invalid argument
This breaks Docker and other applications which use a Jumbo
MTU (9000) when using ipvlans.
The bug is caused by the following recent commit to Bionic
& Xenial-hwe; which is pulled in via the stable patchset below,
which enforces a strict min/max MTU when MTUs are being set up
via rtnetlink for ipvlans:
Breaking commit:
-------------------
Ubuntu-hwe-4.15.0-92.93~16.04.1
* Bionic update: upstream stable patchset 2020-02-21 (LP: #1864261)
* net: rtnetlink: validate IFLA_MTU attribute in rtnl_create_link()
The above patch applies checks of dev->min_mtu and dev->max_mtu
to avoid a malicious user from crashing the kernel with a bad
value. It was patching the original patchset to centralize min/max
MTU checking from various different subsystems of the networking
kernel. However, in that patchset, the max_mtu had not been set
to the largest phys (64K) or jumbo (9000 bytes), and defaults to
1500. The recent commit above which enforces strict bounds checking
for MTU size exposes the bug of the max mtu not being set correctly
for the ipvlan driver (this has been previously fixed in bonding,
teaming drivers).
Fix:
-------
The missing commit in the Bionic backport is the following commit:
ipvlan: use ETH_MAX_MTU as max mtu
commit 548feb33c598dfaf9f8e066b842441ac49b84a8a
[Test Case]
1. Install any kernel earlier than 4.15.0-92 (Bionic/Xenial-hwe)
2. # ip link add test1 mtu 9000 link eno1 type ipvlan mode l2
(where test1 eno1 is the physical interface you are adding
the ipvlan on)
3. # ip link
...
14: test1@eno1: <BROADCAST,MULTICAST> mtu 9000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
...
// check that your test1 ipvlan is created with mtu 9000
4. Install 4.15.0-92 kernel or later
5. # ip link add test1 mtu 9000 link eno1 type ipvlan mode l2
RTNETLINK answers: Invalid argument
6. With the above fix commit backported to the xenial-hwe/Bionic,
the jumbo mtu ipvlan creation works again, identical to before 92.
[Regression Potential]
This commit is in upstream mainline as of v4.18-rc2, and hence
is already in Cosmic and later, i.e. all post Bionic releases
currently. Hence there's low regression potential here.
It only impacts ipvlan functionality, and not other networking
systems, so core systems should not be affected by this. And
affects on setup so it either works or doesn't. Patch is trivial.
It only impacts Bionic/Xenial-hwe 4.15.0-92 onwards versions
(where the latent bug got exposed). |
|
| 2020-05-20 09:23:05 |
Nivedita Singhvi |
description |
[IMPACT]
Setting an MTU larger than the default 1500 results in an
error on the recent (4.15.0-92+) Bionic/Xenial -hwe kernels
when attempting to create ipvlan interfaces:
# ip link add test0 mtu 9000 link eno1 type ipvlan mode l2
RTNETLINK answers: Invalid argument
This breaks Docker and other applications which use a Jumbo
MTU (9000) when using ipvlans.
The bug is caused by the following recent commit to Bionic
& Xenial-hwe; which is pulled in via the stable patchset below,
which enforces a strict min/max MTU when MTUs are being set up
via rtnetlink for ipvlans:
Breaking commit:
-------------------
Ubuntu-hwe-4.15.0-92.93~16.04.1
* Bionic update: upstream stable patchset 2020-02-21 (LP: #1864261)
* net: rtnetlink: validate IFLA_MTU attribute in rtnl_create_link()
The above patch applies checks of dev->min_mtu and dev->max_mtu
to avoid a malicious user from crashing the kernel with a bad
value. It was patching the original patchset to centralize min/max
MTU checking from various different subsystems of the networking
kernel. However, in that patchset, the max_mtu had not been set
to the largest phys (64K) or jumbo (9000 bytes), and defaults to
1500. The recent commit above which enforces strict bounds checking
for MTU size exposes the bug of the max mtu not being set correctly
for the ipvlan driver (this has been previously fixed in bonding,
teaming drivers).
Fix:
-------
The missing commit in the Bionic backport is the following commit:
ipvlan: use ETH_MAX_MTU as max mtu
commit 548feb33c598dfaf9f8e066b842441ac49b84a8a
[Test Case]
1. Install any kernel earlier than 4.15.0-92 (Bionic/Xenial-hwe)
2. # ip link add test1 mtu 9000 link eno1 type ipvlan mode l2
(where test1 eno1 is the physical interface you are adding
the ipvlan on)
3. # ip link
...
14: test1@eno1: <BROADCAST,MULTICAST> mtu 9000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
...
// check that your test1 ipvlan is created with mtu 9000
4. Install 4.15.0-92 kernel or later
5. # ip link add test1 mtu 9000 link eno1 type ipvlan mode l2
RTNETLINK answers: Invalid argument
6. With the above fix commit backported to the xenial-hwe/Bionic,
the jumbo mtu ipvlan creation works again, identical to before 92.
[Regression Potential]
This commit is in upstream mainline as of v4.18-rc2, and hence
is already in Cosmic and later, i.e. all post Bionic releases
currently. Hence there's low regression potential here.
It only impacts ipvlan functionality, and not other networking
systems, so core systems should not be affected by this. And
affects on setup so it either works or doesn't. Patch is trivial.
It only impacts Bionic/Xenial-hwe 4.15.0-92 onwards versions
(where the latent bug got exposed). |
[IMPACT]
Setting an MTU larger than the default 1500 results in an
error on the recent (4.15.0-92+) Bionic/Xenial -hwe kernels
when attempting to create ipvlan interfaces:
# ip link add test0 mtu 9000 link eno1 type ipvlan mode l2
RTNETLINK answers: Invalid argument
This breaks Docker and other applications which use a Jumbo
MTU (9000) when using ipvlans.
The bug is caused by the following recent commit to Bionic
& Xenial-hwe; which is pulled in via the stable patchset below,
which enforces a strict min/max MTU when MTUs are being set up
via rtnetlink for ipvlans:
Breaking commit:
-------------------
Ubuntu-hwe-4.15.0-92.93~16.04.1
* Bionic update: upstream stable patchset 2020-02-21 (LP: #1864261)
* net: rtnetlink: validate IFLA_MTU attribute in rtnl_create_link()
The above patch applies checks of dev->min_mtu and dev->max_mtu
to avoid a malicious user from crashing the kernel with a bad
value. It was patching the original patchset to centralize min/max
MTU checking from various different subsystems of the networking
kernel. However, in that patchset, the max_mtu had not been set
to the largest phys (64K) or jumbo (9000 bytes), and defaults to
1500. The recent commit above which enforces strict bounds checking
for MTU size exposes the bug of the max mtu not being set correctly
for the ipvlan driver (this has been previously fixed in bonding,
teaming drivers).
Fix:
-------
This was fixed in the upstream kernel as of v4.18-rc2 for ipvlans,
but was not backported to Bionic along with other patches. The missing commit in the Bionic backport:
ipvlan: use ETH_MAX_MTU as max mtu
commit 548feb33c598dfaf9f8e066b842441ac49b84a8a
[Test Case]
1. Install any kernel earlier than 4.15.0-92 (Bionic/Xenial-hwe)
2. # ip link add test1 mtu 9000 link eno1 type ipvlan mode l2
(where test1 eno1 is the physical interface you are adding
the ipvlan on)
3. # ip link
...
14: test1@eno1: <BROADCAST,MULTICAST> mtu 9000 qdisc noop state DOWN mode DEFAULT group default qlen 1000
...
// check that your test1 ipvlan is created with mtu 9000
4. Install 4.15.0-92 kernel or later
5. # ip link add test1 mtu 9000 link eno1 type ipvlan mode l2
RTNETLINK answers: Invalid argument
6. With the above fix commit backported to the xenial-hwe/Bionic,
the jumbo mtu ipvlan creation works again, identical to before 92.
[Regression Potential]
This commit is in upstream mainline as of v4.18-rc2, and hence
is already in Cosmic and later, i.e. all post Bionic releases
currently. Hence there's low regression potential here.
It only impacts ipvlan functionality, and not other networking
systems, so core systems should not be affected by this. And
affects on setup so it either works or doesn't. Patch is trivial.
It only impacts Bionic/Xenial-hwe 4.15.0-92 onwards versions
(where the latent bug got exposed). |
|
| 2020-05-20 09:30:07 |
Ubuntu Kernel Bot |
linux (Ubuntu): status |
New |
Incomplete |
|
| 2020-05-20 09:30:10 |
Ubuntu Kernel Bot |
linux (Ubuntu Bionic): status |
New |
Incomplete |
|
| 2020-05-20 09:30:12 |
Ubuntu Kernel Bot |
tags |
sts |
bionic sts |
|
| 2020-05-20 10:27:47 |
Dominique Poulain |
bug |
|
|
added subscriber Dominique Poulain |
| 2020-05-21 00:02:26 |
Nivedita Singhvi |
linux (Ubuntu Bionic): status |
Incomplete |
In Progress |
|
| 2020-05-21 00:02:33 |
Nivedita Singhvi |
linux (Ubuntu Bionic): assignee |
|
Nivedita Singhvi (niveditasinghvi) |
|
| 2020-05-21 13:24:13 |
Nivedita Singhvi |
linux (Ubuntu): status |
Incomplete |
Confirmed |
|
| 2020-05-21 13:24:30 |
Nivedita Singhvi |
linux (Ubuntu): status |
Confirmed |
In Progress |
|
| 2020-05-21 13:25:21 |
Nivedita Singhvi |
linux (Ubuntu): status |
In Progress |
Invalid |
|
| 2020-06-04 06:48:31 |
Khaled El Mously |
linux (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2020-06-10 17:45:19 |
Ubuntu Kernel Bot |
tags |
bionic sts |
bionic sts verification-needed-bionic |
|
| 2020-06-15 04:50:21 |
Nivedita Singhvi |
tags |
bionic sts verification-needed-bionic |
bionic sts verification-done-bionic |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2019-12380 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2019-16089 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2019-19036 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2019-19039 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2019-19318 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2019-19377 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2019-19642 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2019-19813 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2019-19816 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2020-0543 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2020-10711 |
|
| 2020-07-01 10:28:55 |
Launchpad Janitor |
cve linked |
|
2020-13143 |
|
