[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
This bug was fixed in the package linux - 4.10.0-22.24 --- linux (4.10.0-22.24) zesty; urgency=low * linux: 4.10.0-22.24 -proposed tracker (LP: #1691146) * Fix NVLINK2 TCE route (LP: #1690155) - powerpc/powernv: Fix TCE kill on NVLink2 * CVE-2017-0605 - tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline() * perf: qcom: Add L3 cache PMU driver (LP: #1689856) - [Config] CONFIG_QCOM_L3_PMU=y - perf: qcom: Add L3 cache PMU driver * No PMU support for ACPI-based arm64 systems (LP: #1689661) - drivers/perf: arm_pmu: rework per-cpu allocation - drivers/perf: arm_pmu: manage interrupts per-cpu - drivers/perf: arm_pmu: split irq request from enable - drivers/perf: arm_pmu: remove pointless PMU disabling - drivers/perf: arm_pmu: define armpmu_init_fn - drivers/perf: arm_pmu: fold init into alloc - drivers/perf: arm_pmu: factor out pmu registration - drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs() - drivers/perf: arm_pmu: handle no platform_device - drivers/perf: arm_pmu: rename irq request/free functions - drivers/perf: arm_pmu: split cpu-local irq request/free - drivers/perf: arm_pmu: move irq request/free into probe - drivers/perf: arm_pmu: split out platform device probe logic - arm64: add function to get a cpu's MADT GICC table - [Config] CONFIG_ARM_PMU_ACPI=y - drivers/perf: arm_pmu: add ACPI framework - arm64: pmuv3: handle !PMUv3 when probing - arm64: pmuv3: use arm_pmu ACPI framework * [SRU][Zesty]QDF2400 kernel oops on ipmitool fru write 0 fru.bin (LP: #1689886) - ipmi: Fix kernel panic at ipmi_ssif_thread() * tty: pl011: fix earlycon work-around for QDF2400 erratum 44 (LP: #1689818) - tty: pl011: fix earlycon work-around for QDF2400 erratum 44 - tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44 * kernel-wedge fails in artful due to leftover squashfs-modules d-i files (LP: #1688259) - Remove squashfs-modules files from d-i - [Config] as squashfs-modules is builtin kernel-image must Provides: it * arm64/ACPI support for SBSA watchdog (LP: #1688114) - clocksource: arm_arch_timer: clean up printk usage - clocksource: arm_arch_timer: rename type macros - clocksource: arm_arch_timer: rename the PPI enum - clocksource: arm_arch_timer: move enums and defines to header file - clocksource: arm_arch_timer: add a new enum for spi type - clocksource: arm_arch_timer: rework PPI selection - clocksource: arm_arch_timer: split dt-only rate handling - clocksource: arm_arch_timer: refactor arch_timer_needs_probing - clocksource: arm_arch_timer: move arch_timer_needs_of_probing into DT init call - clocksource: arm_arch_timer: add structs to describe MMIO timer - clocksource: arm_arch_timer: split MMIO timer probing. - [Config] CONFIG_ACPI_GTDT=y - acpi/arm64: Add GTDT table parse driver - clocksource: arm_arch_timer: simplify ACPI support code. - acpi/arm64: Add memory-mapped timer support in GTDT driver - clocksource: arm_arch_timer: add GTDT support for memory-mapped timer - acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver * kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129 (LP: #1674838) - Revert "mm/ksm: handle protnone saved writes when making page write protect" - Revert "mm, ksm: convert write_protect_page() to use page_vma_mapped_walk()" - Revert "mm: introduce page_vma_mapped_walk()" - mm/ksm: handle protnone saved writes when making page write protect * arm64: Add CNTFRQ_EL0 handler (LP: #1688164) - arm64: Add CNTFRQ_EL0 trap handler * Support IPMI system interface on Cavium ThunderX (LP: #1688132) - i2c: thunderx: Enable HWMON class probing * Update ENA driver to 1.1.2 from net-next (LP: #1664312) - net/ena: remove ntuple filter support from device feature list - net/ena: fix queues number calculation - net/ena: fix ethtool RSS flow configuration - net/ena: fix RSS default hash configuration - net/ena: fix NULL dereference when removing the driver after device reset failed - net/ena: refactor ena_get_stats64 to be atomic context safe - net/ena: fix potential access to freed memory during device reset - net/ena: use READ_ONCE to access completion descriptors - net/ena: reduce the severity of ena printouts - net/ena: change driver's default timeouts - net/ena: change condition for host attribute configuration - net/ena: update driver version to 1.1.2 * Zesty update to 4.10.15 stable release (LP: #1689258) - timerfd: Protect the might cancel mechanism proper - Handle mismatched open calls - hwmon: (it87) Avoid registering the same chip on both SIO addresses - dm ioctl: prevent stack leak in dm ioctl call - Linux 4.10.15 * Zesty update to 4.10.14 stable release (LP: #1688499) - ping:
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
This bug was fixed in the package linux - 4.10.0-22.24 --- linux (4.10.0-22.24) zesty; urgency=low * linux: 4.10.0-22.24 -proposed tracker (LP: #1691146) * Fix NVLINK2 TCE route (LP: #1690155) - powerpc/powernv: Fix TCE kill on NVLink2 * CVE-2017-0605 - tracing: Use strlcpy() instead of strcpy() in __trace_find_cmdline() * perf: qcom: Add L3 cache PMU driver (LP: #1689856) - [Config] CONFIG_QCOM_L3_PMU=y - perf: qcom: Add L3 cache PMU driver * No PMU support for ACPI-based arm64 systems (LP: #1689661) - drivers/perf: arm_pmu: rework per-cpu allocation - drivers/perf: arm_pmu: manage interrupts per-cpu - drivers/perf: arm_pmu: split irq request from enable - drivers/perf: arm_pmu: remove pointless PMU disabling - drivers/perf: arm_pmu: define armpmu_init_fn - drivers/perf: arm_pmu: fold init into alloc - drivers/perf: arm_pmu: factor out pmu registration - drivers/perf: arm_pmu: simplify cpu_pmu_request_irqs() - drivers/perf: arm_pmu: handle no platform_device - drivers/perf: arm_pmu: rename irq request/free functions - drivers/perf: arm_pmu: split cpu-local irq request/free - drivers/perf: arm_pmu: move irq request/free into probe - drivers/perf: arm_pmu: split out platform device probe logic - arm64: add function to get a cpu's MADT GICC table - [Config] CONFIG_ARM_PMU_ACPI=y - drivers/perf: arm_pmu: add ACPI framework - arm64: pmuv3: handle !PMUv3 when probing - arm64: pmuv3: use arm_pmu ACPI framework * [SRU][Zesty]QDF2400 kernel oops on ipmitool fru write 0 fru.bin (LP: #1689886) - ipmi: Fix kernel panic at ipmi_ssif_thread() * tty: pl011: fix earlycon work-around for QDF2400 erratum 44 (LP: #1689818) - tty: pl011: fix earlycon work-around for QDF2400 erratum 44 - tty: pl011: use "qdf2400_e44" as the earlycon name for QDF2400 E44 * kernel-wedge fails in artful due to leftover squashfs-modules d-i files (LP: #1688259) - Remove squashfs-modules files from d-i - [Config] as squashfs-modules is builtin kernel-image must Provides: it * arm64/ACPI support for SBSA watchdog (LP: #1688114) - clocksource: arm_arch_timer: clean up printk usage - clocksource: arm_arch_timer: rename type macros - clocksource: arm_arch_timer: rename the PPI enum - clocksource: arm_arch_timer: move enums and defines to header file - clocksource: arm_arch_timer: add a new enum for spi type - clocksource: arm_arch_timer: rework PPI selection - clocksource: arm_arch_timer: split dt-only rate handling - clocksource: arm_arch_timer: refactor arch_timer_needs_probing - clocksource: arm_arch_timer: move arch_timer_needs_of_probing into DT init call - clocksource: arm_arch_timer: add structs to describe MMIO timer - clocksource: arm_arch_timer: split MMIO timer probing. - [Config] CONFIG_ACPI_GTDT=y - acpi/arm64: Add GTDT table parse driver - clocksource: arm_arch_timer: simplify ACPI support code. - acpi/arm64: Add memory-mapped timer support in GTDT driver - clocksource: arm_arch_timer: add GTDT support for memory-mapped timer - acpi/arm64: Add SBSA Generic Watchdog support in GTDT driver * kernel BUG at /build/linux-7LGLH_/linux-4.10.0/include/linux/swapops.h:129 (LP: #1674838) - Revert "mm/ksm: handle protnone saved writes when making page write protect" - Revert "mm, ksm: convert write_protect_page() to use page_vma_mapped_walk()" - Revert "mm: introduce page_vma_mapped_walk()" - mm/ksm: handle protnone saved writes when making page write protect * arm64: Add CNTFRQ_EL0 handler (LP: #1688164) - arm64: Add CNTFRQ_EL0 trap handler * Support IPMI system interface on Cavium ThunderX (LP: #1688132) - i2c: thunderx: Enable HWMON class probing * Update ENA driver to 1.1.2 from net-next (LP: #1664312) - net/ena: remove ntuple filter support from device feature list - net/ena: fix queues number calculation - net/ena: fix ethtool RSS flow configuration - net/ena: fix RSS default hash configuration - net/ena: fix NULL dereference when removing the driver after device reset failed - net/ena: refactor ena_get_stats64 to be atomic context safe - net/ena: fix potential access to freed memory during device reset - net/ena: use READ_ONCE to access completion descriptors - net/ena: reduce the severity of ena printouts - net/ena: change driver's default timeouts - net/ena: change condition for host attribute configuration - net/ena: update driver version to 1.1.2 * Zesty update to 4.10.15 stable release (LP: #1689258) - timerfd: Protect the might cancel mechanism proper - Handle mismatched open calls - hwmon: (it87) Avoid registering the same chip on both SIO addresses - dm ioctl: prevent stack leak in dm ioctl call - Linux 4.10.15 * Zesty update to 4.10.14 stable release (LP: #1688499) - ping:
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
** Tags removed: verification-needed-zesty
** Tags added: verification-done-zesty
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Zesty:
Fix Committed
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38 testmachine kernel: dump_stack+0x63/0x81
Apr 12
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
This bug is awaiting verification that the kernel in -proposed solves
the problem. Please test the kernel and update this bug with the
results. If the problem is solved, change the tag 'verification-needed-
zesty' to 'verification-done-zesty'. If the problem still exists, change
the tag 'verification-needed-zesty' to 'verification-failed-zesty'.
If verification is not done by 5 working days from today, this fix will
be dropped from the source code, and this bug will be closed.
See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how
to enable and use -proposed. Thank you!
** Tags added: verification-needed-zesty
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Zesty:
Fix Committed
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
** Changed in: linux (Ubuntu Zesty)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Zesty:
Fix Committed
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38 testmachine kernel: dump_stack+0x63/0x81
Apr 12
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
** Changed in: linux (Ubuntu)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
Fix Committed
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38 testmachine kernel: dump_stack+0x63/0x81
Apr 12 11:31:38
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
and applied in v4.11-rc8:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e0535ce58b92d7baf0b33284a6c4f8f0338f943e
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
the proposed fix has been queue for -stable in v3, now as a single patch:
http://marc.info/?t=14926902325
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38 testmachine kernel:
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
2017-7979 was assigned (http://cve.mitre.org/cgi-
bin/cvename.cgi?name=CVE-2017-7979), but is not yet known to LP it
seems..
** CVE added: http://www.cve.mitre.org/cgi-
bin/cvename.cgi?name=2017-7979
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
CVE requested, will include once I get a reply.
Note that Canonical is listed as CNA for "Ubuntu/Linux issues" at
http://cve.mitre.org/cve/cna.html - maybe that list needs an update
then?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
Hi Fabian, Ubuntu is currently not assigning CVE numbers; MITRE can be
best contacted at https://cveform.mitre.org/
Thanks
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38 testmachine
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
** Tags removed: kernel-da-key
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38 testmachine kernel: dump_stack+0x63/0x81
Apr 12 11:31:38 testmachine kernel: __warn+0xcb/0xf0
Apr
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
@seth-arnold: no, not yet. shall we request one from Mitre or does
Ubuntu/Canonical have a pool to assign one?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38 testmachine kernel:
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
New threads at
http://marc.info/?l=linux-netdev=149251041420195=2
http://marc.info/?l=linux-netdev=149251041420194=2
Does this issue have a CVE number or numbers yet?
Thanks
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel:
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
** Attachment added: "journal-1"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1682368/+attachment/4861894/+files/journal-1
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
** Attachment added: "journal-2"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1682368/+attachment/4861895/+files/journal-2
** Information type changed from Public to Public Security
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
** Attachment added: "transcript"
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1682368/+attachment/4861893/+files/transcript
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
this is easily reproducible and triggers at least a DoS on a freshly
installed 17.04 system, from within an unprivileged LXD container. see
the transcript for the executed commands, and journal-1 and journal-2
for the first and second kernel traces (caused by the second to last and
last "tc" commands executed in the container).
the end result is a complete hang/crash of the system.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU:
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Also affects: linux (Ubuntu Zesty)
Importance: Medium
Status: Confirmed
** Changed in: linux (Ubuntu Zesty)
Status: Confirmed => In Progress
** Changed in: linux (Ubuntu Zesty)
Assignee: (unassigned) => Fabian Grünbichler (f-gruenbichler)
** Tags added: kernel-da-key zesty
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
In Progress
Status in linux source package in Zesty:
In Progress
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
See https://bugzilla.proxmox.com/show_bug.cgi?id=1351 and
https://forum.proxmox.com/threads/proxmox-
ve-5-0-beta1-released.33731/page-4#post-167127 for downstream reports by
users.
** Bug watch added: bugzilla.proxmox.com/ #1351
https://bugzilla.proxmox.com/show_bug.cgi?id=1351
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
Confirmed
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
** Changed in: linux (Ubuntu)
Status: Incomplete => Confirmed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
Confirmed
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38 testmachine kernel: dump_stack+0x63/0x81
Apr 12 11:31:38 testmachine kernel: __warn+0xcb/0xf0
Apr 12 11:31:38
[Kernel-packages] [Bug 1682368] Re: refcount underflow / kernel NULL dereference after attempting to add basic tc filter
SRU request sent to kernel-team list.
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1682368
Title:
refcount underflow / kernel NULL dereference after attempting to add
basic tc filter
Status in linux package in Ubuntu:
Incomplete
Bug description:
== SRU Justification ==
Impact: adding a tc filter sometimes fails, potentially followed by
kernel hangs and kernel NULL pointer dereference
Fix: proposed upstream by Wolfgang Bumiller [1,2]
Regression Potential: Since nobody else noticed this issue in 4.11 >=
rc1 or Ubuntu 4.10 >= 15.17, and the fix only touches the broken code,
the regression potential should be minimal ;)
1: http://marc.info/?l=linux-netdev=149200746116365
2: http://marc.info/?l=linux-netdev=149200742616349
---
Commit 1045ba77a which was backported for #1674087 in
fc0cef7a8ec1e63ee3405f642983dd86e04ab6cc (first released with
Ubuntu-4.10.0-15.17) introduces the problematic code. Note that while
the traces below were generated using a custom patched kernel, the
same issue is reproducible using Ubuntu Zesty's 4.10.0-15.17 (and
later) kernels.
The full cover letter of the proposed fix by my colleague Wolfgang
Bumiller follows:
Commit 1045ba77a ("net sched actions: Add support for user cookies")
added code to net/sched/act_api.c's tcf_action_init_1 using the `tb`
nlattr array unconditionally, while it was otherwise used as well as
initialized only when `name == NULL`:
if (name == NULL) {
err = nla_parse_nested(tb, TCA_ACT_MAX, nla, NULL);
In the other case `nla` is instead passed over to ->init to be parsed
there (using a different set of TCA_ enum values, iow. TCA_ACT_COOKIE
then "clashes" with some other value). This lead to the following three
example commands resulting in errors (sometimes followed by more traces
and hangups some time later (although the hangups happened seconds or
sometimes minutes later, sometimes not at all - results differed between
different kernel versions (linux git-master vs ubuntu's mainline 4.11
rc6 vs. pve 4.10.5 (based off ubuntu's zesty kernel where the commit is
cherry-picked)...))):
# ip link add ve0 type veth peer name ve0b
# tc qdisc add dev ve0 handle : ingress
# tc filter add dev ve0 parent : prio 50 basic police rate 1000bps burst
1000b drop
The 3rd command would sometimes succeed, sometimes error with:
RTNETLINK answers: Invalid argument
We have an error talking to the kernel
and sometimes error with:
RTNETLINK answers: Cannot allocate memory
We have an error talking to the kernel
In the latter case I assume `cklen` became negative, which passes the
TC_COOKIE_MAX_SIZE check since it is signed but becomes unsigned later
in kmemdup() (see the crash dump below)
When the `tc filter add` command fails a backtrace shows up in dmesg,
added below.
I'm not sure why the TC_ACT_COOKIE code was added to tcf_action_init_1
where it is now. It makes me think that it's supposed to be available
universally, but the `name == NULL` check for how nla is used or passed
to ->init() shows that the there are various different TC_ACT_* enums in
use at this point, hence the 'RFC' part of the patches, I'm not that
familiar with the code yet.
Backtrace when running `tc filter add`:
Apr 12 11:31:38 testmachine kernel: [ cut here ]
Apr 12 11:31:38 testmachine kernel: WARNING: CPU: 7 PID: 16596 at
mm/page_alloc.c:3541 __alloc_pages_slowpath+0x9fe/0xba0
Apr 12 11:31:38 testmachine kernel: Modules linked in: act_police
cls_basic sch_ingress veth nfsv3 nfs_acl nfs lockd grace ip6t_REJECT
nf_reject_ipv6 nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables
xt_mac ipt_REJECT nf_reject_ipv4 xt_physdev xt_comment nf_conntrack_ipv4
nf_defrag_ipv4 xt_tcpudp xt_mark xt_set xt_addrtype xt_multiport xt_conntrack
nf_conntrack ip_set_hash_net ip_set arc4 md4 nls_utf8 cifs ccm fscache ipta
Apr 12 11:31:38 testmachine kernel: snd_hda_codec_realtek
snd_hda_codec_generic aesni_intel aes_x86_64 crypto_simd drm_kms_helper
glue_helper cryptd drm snd_hda_intel intel_cstate snd_hda_codec i2c_algo_bit
fb_sys_fops snd_hda_core joydev syscopyarea snd_hwdep sysfillrect input_leds
sysimgblt intel_rapl_perf snd_pcm snd_timer snd pcspkr soundcore mei_me lpc_ich
mei shpchp tpm_infineon mac_hid wmi acpi_pad video vhost_net vhost macv
Apr 12 11:31:38 testmachine kernel: CPU: 7 PID: 16596 Comm: tc Tainted: P
O4.10.5-1-pve #1
Apr 12 11:31:38 testmachine kernel: Hardware name: ASUS All Series/Z97-A,
BIOS 2801 11/11/2015
Apr 12 11:31:38 testmachine kernel: Call Trace:
Apr 12 11:31:38 testmachine kernel: dump_stack+0x63/0x81
Apr 12 11:31:38 testmachine kernel: __warn+0xcb/0xf0
Apr 12 11:31:38 testmachine kernel:
