2018-04-05 15:57:37 |
Eric Desrochers |
bug |
|
|
added bug |
2018-04-05 15:58:38 |
Eric Desrochers |
tags |
|
sts |
|
2018-04-05 15:59:34 |
Eric Desrochers |
linux (Ubuntu): assignee |
|
Eric Desrochers (slashd) |
|
2018-04-05 15:59:37 |
Eric Desrochers |
linux (Ubuntu): status |
New |
In Progress |
|
2018-04-05 15:59:40 |
Eric Desrochers |
linux (Ubuntu): importance |
Undecided |
Medium |
|
2018-04-05 15:59:48 |
Eric Desrochers |
nominated for series |
|
Ubuntu Bionic |
|
2018-04-05 15:59:48 |
Eric Desrochers |
bug task added |
|
linux (Ubuntu Bionic) |
|
2018-04-05 15:59:48 |
Eric Desrochers |
nominated for series |
|
Ubuntu Xenial |
|
2018-04-05 15:59:48 |
Eric Desrochers |
bug task added |
|
linux (Ubuntu Xenial) |
|
2018-04-05 15:59:48 |
Eric Desrochers |
nominated for series |
|
Ubuntu Artful |
|
2018-04-05 15:59:48 |
Eric Desrochers |
bug task added |
|
linux (Ubuntu Artful) |
|
2018-04-05 15:59:58 |
Eric Desrochers |
linux (Ubuntu Artful): assignee |
|
Eric Desrochers (slashd) |
|
2018-04-05 16:00:00 |
Eric Desrochers |
linux (Ubuntu Xenial): assignee |
|
Eric Desrochers (slashd) |
|
2018-04-05 16:00:01 |
Eric Desrochers |
linux (Ubuntu Artful): importance |
Undecided |
Medium |
|
2018-04-05 16:00:03 |
Eric Desrochers |
linux (Ubuntu Xenial): importance |
Undecided |
Medium |
|
2018-04-05 16:00:06 |
Eric Desrochers |
linux (Ubuntu Artful): status |
New |
In Progress |
|
2018-04-05 16:00:08 |
Eric Desrochers |
linux (Ubuntu Xenial): status |
New |
In Progress |
|
2018-04-05 16:02:23 |
Eric Desrochers |
description |
Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK.
Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about.
static inline bool netif_oper_up(const struct net_device *dev)
{
return (dev->operstate == IF_OPER_UP ||
dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}
Code Ref:
1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739
2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468
3. https://www.kernel.org/doc/Documentation/networking/operstates.txt
Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated. |
It has been brought to my attention the following :
------------------------------------------------
Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK.
Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about.
static inline bool netif_oper_up(const struct net_device *dev)
{
return (dev->operstate == IF_OPER_UP ||
dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}
Code Ref:
1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739
2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468
3. https://www.kernel.org/doc/Documentation/networking/operstates.txt
Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated.
------------------------------------------------ |
|
2018-04-05 16:29:43 |
Eric Desrochers |
nominated for series |
|
Ubuntu Trusty |
|
2018-04-05 16:29:43 |
Eric Desrochers |
bug task added |
|
linux (Ubuntu Trusty) |
|
2018-04-05 16:29:50 |
Eric Desrochers |
linux (Ubuntu Trusty): status |
New |
In Progress |
|
2018-04-05 16:29:52 |
Eric Desrochers |
linux (Ubuntu Trusty): importance |
Undecided |
Medium |
|
2018-04-05 16:29:54 |
Eric Desrochers |
linux (Ubuntu Trusty): assignee |
|
Eric Desrochers (slashd) |
|
2018-04-05 18:05:48 |
Eric Desrochers |
description |
It has been brought to my attention the following :
------------------------------------------------
Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK.
Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about.
static inline bool netif_oper_up(const struct net_device *dev)
{
return (dev->operstate == IF_OPER_UP ||
dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}
Code Ref:
1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739
2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468
3. https://www.kernel.org/doc/Documentation/networking/operstates.txt
Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated.
------------------------------------------------ |
It has been brought to our attention the following bug :
------------------------------------------------
Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK.
Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about.
static inline bool netif_oper_up(const struct net_device *dev)
{
return (dev->operstate == IF_OPER_UP ||
dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}
Code Ref:
1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739
2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468
3. https://www.kernel.org/doc/Documentation/networking/operstates.txt
Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated.
------------------------------------------------ |
|
2018-04-05 18:09:59 |
Eric Desrochers |
bug |
|
|
added subscriber Jay Vosburgh |
2018-04-05 19:38:39 |
Eric Desrochers |
description |
It has been brought to our attention the following bug :
------------------------------------------------
Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK.
Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about.
static inline bool netif_oper_up(const struct net_device *dev)
{
return (dev->operstate == IF_OPER_UP ||
dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}
Code Ref:
1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739
2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468
3. https://www.kernel.org/doc/Documentation/networking/operstates.txt
Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated.
------------------------------------------------ |
[Impact]
"ip a" command on a guest VM shows UNKNOWN status.
[Test Case]
* Environment : Running a guest VM with a virtio-net adaptor interface, running on DPDK.
* Perform "ip a" inside the guest VM shows state "UNKNOWN" as follow example:
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN group default qlen 1000
.....
[Regression Potential]
* Regression is low, the patch fix the operstate logic for virtio when no VIRTIO_NET_F_STATUS.[1]
* The patch has been first accepted in net-next, then move into Linus's git.
[1] - VIRTIO_NET_F_STATUS
Allow the host to inform us that the link is down by adding a VIRTIO_NET_F_STATUS which indicates that device status is available in virtio_net config.
[Other Info]
* Linus: https://github.com/torvalds/linux/commit/bda7fab54828bbef2164bb23c0f6b1a7d05cc718
* Net-next:
https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/commit/?id=bda7fab54828bbe
[Original Description]
It has been brought to our attention the following bug :
------------------------------------------------
Environment: The guest VM is using a canonical ubuntu image, and the eth0 is a virtio-net adaptor, running on DPDK.
Background: "ip a" command relies on the operstate variable of the net_device structure maintained by the kernel. This is based on the operational state as defined in the IF MIB (RFC 2863). Device drivers are expected to update this member. But many older drivers don’t seem to be using this. So in general, IF_OPER_UP and IF_OPER_UNKNOWN are treated as equal, in some sense, to maintain backward compatibility. Even if we look at https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468, the function to check if interface is up, is written as follows, which says that OPER_UNKNOWN is not something to be alarmed about, and just reflective of a state that some drivers don’t care to update about.
static inline bool netif_oper_up(const struct net_device *dev)
{
return (dev->operstate == IF_OPER_UP ||
dev->operstate == IF_OPER_UNKNOWN /* backward compat */);
}
Code Ref:
1. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L1739
2. https://elixir.free-electrons.com/linux/v4.15-rc2/source/include/linux/netdevice.h#L3468
3. https://www.kernel.org/doc/Documentation/networking/operstates.txt
Now, for traditional kernel mode network adapter drivers, this state is supposed to be manipulated by the driver. And we can safely assume that most current kernel model drivers do keep this updated.
------------------------------------------------ |
|
2018-04-09 20:57:56 |
Seth Forshee |
linux (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
2018-04-19 16:41:24 |
Stefan Bader |
linux (Ubuntu Artful): status |
In Progress |
Fix Committed |
|
2018-04-19 16:41:28 |
Stefan Bader |
linux (Ubuntu Xenial): status |
In Progress |
Fix Committed |
|
2018-04-19 16:41:31 |
Stefan Bader |
linux (Ubuntu Trusty): status |
In Progress |
Fix Committed |
|
2018-04-23 23:51:27 |
Launchpad Janitor |
linux (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
2018-04-23 23:51:27 |
Launchpad Janitor |
cve linked |
|
2017-5715 |
|
2018-04-23 23:51:27 |
Launchpad Janitor |
cve linked |
|
2017-5753 |
|
2018-04-23 23:51:27 |
Launchpad Janitor |
cve linked |
|
2017-5754 |
|
2018-04-25 14:33:59 |
Brad Figg |
tags |
sts |
sts verification-needed-trusty |
|
2018-04-27 19:02:29 |
Brad Figg |
tags |
sts verification-needed-trusty |
sts verification-needed-artful verification-needed-trusty |
|
2018-04-27 19:12:16 |
Brad Figg |
tags |
sts verification-needed-artful verification-needed-trusty |
sts verification-needed-artful verification-needed-trusty verification-needed-xenial |
|
2018-05-04 12:24:02 |
Eric Desrochers |
tags |
sts verification-needed-artful verification-needed-trusty verification-needed-xenial |
sts verification-done-artful verification-done-trusty verification-done-xenial |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
linux (Ubuntu Trusty): status |
Fix Committed |
Fix Released |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2017-12134 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2017-13220 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2017-13305 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2017-17449 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2017-18079 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2017-18203 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2017-18204 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2017-18208 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2017-18221 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2018-3639 |
|
2018-05-21 23:59:29 |
Launchpad Janitor |
cve linked |
|
2018-8822 |
|
2018-05-22 00:00:38 |
Launchpad Janitor |
linux (Ubuntu Xenial): status |
Fix Committed |
Fix Released |
|
2018-05-22 00:00:38 |
Launchpad Janitor |
cve linked |
|
2017-16995 |
|
2018-05-22 00:00:38 |
Launchpad Janitor |
cve linked |
|
2017-17862 |
|
2018-05-22 00:00:38 |
Launchpad Janitor |
cve linked |
|
2018-1000004 |
|
2018-05-22 00:04:32 |
Launchpad Janitor |
linux (Ubuntu Artful): status |
Fix Committed |
Fix Released |
|
2018-05-22 00:04:32 |
Launchpad Janitor |
cve linked |
|
2017-17975 |
|
2019-02-14 13:11:26 |
Brad Figg |
tags |
sts verification-done-artful verification-done-trusty verification-done-xenial |
sts verification-done-artful verification-done-trusty verification-done-xenial verification-needed-bionic |
|
2019-02-14 15:51:38 |
Andy Whitcroft |
tags |
sts verification-done-artful verification-done-trusty verification-done-xenial verification-needed-bionic |
kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial |
|
2019-02-14 16:09:31 |
Brad Figg |
tags |
kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial |
kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial verification-needed-bionic |
|
2019-02-14 16:15:47 |
Andy Whitcroft |
tags |
kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial verification-needed-bionic |
kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial |
|
2019-02-14 16:18:42 |
Andy Whitcroft |
tags |
kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-trusty verification-done-xenial |
kernel-fixup-verification-needed-bionic sts verification-done-artful verification-done-bionic verification-done-trusty verification-done-xenial |
|