NULL pointer dereference when configuring multi-function with devfn != 0 before devfn == 0

Bug #1903682 reported by bugproxy
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Ubuntu on IBM z Systems
Fix Released
Medium
Skipper Bug Screeners
linux (Ubuntu)
Fix Released
Undecided
Frank Heimes
Focal
Fix Released
Medium
Unassigned
Groovy
Fix Released
Medium
Unassigned
Hirsute
Fix Released
Undecided
Frank Heimes

Bug Description

SRU Justification:
==================

[Impact]

* While handling multifunction devices in zPCI the UID of the PCI function with function number 0 (that always exists according to the PCI spec) is taken as domain number.

* Therefore if hot plugging functions with a function number larger than 0 are used before function 0, these need to be held in standby before creating the domain and bus.

* This has been tested during development of this feature using a patched QEMU and in DPM, but unfortunately never in classic/traditional HMC mode.

* On a classic/traditional mode machine with a multi-function device, and hot plug ("Reassign I/O Path") of the FID of the second port of the LPAR, any additional hotplug (and even just deconfiguring a PCI device) will hang - and hotplug now makes the entire Linux instance unresponsive.

* The reason for this is a NULL pointer dereference - inc case configuring multi-function with devfn != 0 before devfn == 0.

* This issue was introduced with the topology-aware PCI enumeration code.

[Fix]

* 0b2ca2c7d0c9e2731d01b6c862375d44a7e13923 0b2ca2c7d0c9 "s390/pci: fix hot-plug of PCI function missing bus"

[Test Case]

* IBM Z or LinuxONE hardware, equipped with hot-pluggable, multi-functional PCIe cards (like for example RoCE Express 2 adapters) in classic/traditional mode.

* An Ubuntu OS running in LPAR, that comes with a kernel that includes the topology-aware PCI enumeration code (like for example 20.04.1 w/o further updates or 20.10 GA kernel).

* Now on a system that is in classic/traditional mode, hot plug ("Reassign I/O Path") a multi-function device, but using the FID of the second port.

[Regression Potential]

* There is at least some regression risk, but I consider it as low, because:

* Even is the modification is a single if statement (that spans two lines) in 'zpci_event_availability' it could harm the zPCI event management even more, in worst case it could break hot plug not only for systems in classic/traditional mode, but also in DPM mode (and making the system hang) or for all ports.

* In such a case no enabling / disabling of devices would be possible.

* But the fix is very simple and straight-forward, it checks zdev->zbus->bus for being NULL and in such a case break the function - means breaking instead of calling the PCI common code pci_scan_single_device() with the NULL pointer.

* PCIe devices are usually more optional devices on s390x (compared to CCW and OSA devices for network) and this affects the zPCI subsystem only, which is unique to s390x.

[Other]

* The patch got upstream accepted with kernel v5.10-rc3, hence it will land sooner or later in Hirsute.

* It was initially planned to address groovy via 5.8 upstream stable update, and in fact the patch was already marked for this, but it didn't made it because 5.8 reached it's EOL already.

* Hence in addition to the already submitted SRU for focal, this is now a separate SRU for groovy.
__________

Background:

When handling multifunction devices in zPCI we take the
UID of the PCI function with function number 0
(that always exists according to the PCI spec)
as domain number.
Therefore when hot plugging functions with function
number larger than 0 before function 0, we need
to hold these in standby before creating the
domain and bus.

This has been tested during feature development
using a patched QEMU and with DPM but never in Classic
Mode.

Reproduction:

This issue was introduced with the Topology aware PCI
Enumeration code so test with a Linux supporting
that feature. E.g. Upstream, Devel Driver etc.

On a Classic Mode machine with a multi-function device,
hot plug ("Reassign I/O Path") only the FID of the
second port to the LPAR.

Symptom:

After this any additional hotplug and even just
deconfiguring a PCI device will hang. A hotplug
makes the entire Linux instance unresponsive.

Analysis:

The problem occurs in Classic Mode but not with
previous testing as the LPAR hypervisor does
hot plug/Reassign I/O Path as a two step process:

1. zPCI event with PEC 0x0302 to plug the zPCI function in Standby
2. zPCI event with PEC 0x0301 to configure the zPCI function

For the first event we create the zdev in clp_add_pci_device()
in Standby which is all fine so far.
The problem then occurs in step 2 as we then find
the existing zdev and try to configure it.
This however does not work as the PCI bus
is not yet created (as we still don't know the UID of
function 0 that will become its domain).
The bus pointer zdev->zbus->bus pointer is thus still
NULL but will be accessed by common code which
inevitably results in disaster including
the above mentioned hang and (possibly) the below
RCU stall:

[ 689.724703] rcu: INFO: rcu_sched self-detected stall on CPU
[ 689.724712] rcu: 16-....: (42004 ticks this GP) idle=6ee/1/0x4000000000000002 softirq=1234/1234 fqs=14001
[ 689.724742] (t=42006 jiffies g=89 q=3770)
[ 689.724743] Task dump for CPU 16:
[ 689.724745] task:kmcheck state:R running task stack: 0 pid: 205 ppid: 2 flags:0x00000004
[ 689.724747] Call Trace:
[ 689.724757] [<0000000ccde0b5c4>] show_stack+0x8c/0xd8
[ 689.724762] [<0000000ccd0dabc4>] sched_show_task.part.0+0xe4/0x110
[ 689.724764] [<0000000ccde0ea5e>] rcu_dump_cpu_stacks+0xde/0x120
[ 689.724767] [<0000000ccd1465c6>] print_cpu_stall+0x266/0x330
[ 689.724768] [<0000000ccd14a428>] rcu_sched_clock_irq+0x618/0x670
[ 689.724771] [<0000000ccd15cd7a>] update_process_times+0xba/0xf0
[ 689.724775] [<0000000ccd1766fa>] tick_sched_timer+0x9a/0x220
[ 689.724777] [<0000000ccd15d962>] __hrtimer_run_queues+0x182/0x3a0
[ 689.724779] [<0000000ccd1602f8>] hrtimer_interrupt+0x138/0x450
[ 689.724782] [<0000000ccd0451c0>] do_IRQ+0x90/0xa0
[ 689.724784] [<0000000ccde2be96>] ext_int_handler+0x17e/0x184
[ 689.724790] [<0000000ccd9f373e>] pci_get_slot+0x5e/0xa0
[ 689.724794] [<0000000ccd9dc182>] pci_scan_single_device+0x32/0x2a0
[ 689.724797] [<0000000ccd0868f2>] __zpci_event_availability+0x192/0x360
[ 689.724800] [<0000000ccdd40c16>] chsc_process_crw+0x2e6/0x300
[ 689.724802] [<0000000ccdd4b088>] crw_collect_info+0x2b8/0x320
[ 689.724804] [<0000000ccd0caf3a>] kthread+0x14a/0x170
[ 689.724805] [<0000000ccde2b814>] ret_from_fork+0x24/0x2c

The fix is very simple, we check zdev->zbus->bus
for being NULL and in that case bail from the
case 0x0301 before calling the PCI common code
pci_scan_single_device() with the NULL pointer.

The only subtlety is that we still need to
do the zpci_enable_device() because the
code in arch/s390/pci/pci_bus.c assumes
that it can immediately do a scan of
all devfn != 0 PCI functions once
PCI function 0 is found.

It thereby mimics what happens
when we only find the FID for a function with
devfn != 0 in the CLP List PCI Functions.

This is implemented in the following upstream
commit:

0b2ca2c7d0c9e2731d01b6c862375d44a7e13923 s390/pci: fix hot-plug of PCI function missing bus

It is included in v5.10-rc3 and has been tagged for
stable > v5.8 i.e. all upstream versions with
the PCI enumeration changes.
Also it carries the appropriate Fixes tag.

I have verified that it cherry-picks cleanly
on current focal master-next and expect
it to cleanly cherry-pick on newer Ubuntu
Kernels too.

CVE References

bugproxy (bugproxy)
tags: added: architecture-s39064 bugnameltc-189163 severity-medium targetmilestone-inin2010
Changed in ubuntu:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
affects: ubuntu → linux (Ubuntu)
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
importance: Undecided → Medium
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
assignee: nobody → Skipper Bug Screeners (skipper-screen-team)
Changed in linux (Ubuntu):
assignee: Skipper Bug Screeners (skipper-screen-team) → Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: New → Triaged
Frank Heimes (fheimes)
Changed in linux (Ubuntu Hirsute):
assignee: Frank Heimes (fheimes) → nobody
Changed in linux (Ubuntu Focal):
assignee: nobody → Frank Heimes (fheimes)
Revision history for this message
Frank Heimes (fheimes) wrote :

Ok, I can see that the commit got accepted with 5.10-rc3, hence it will land in hirsute.
And because the patch was tagged as stable for 5.8, it will land in groovy's kernel 5.8 (I'll check the 'Groovy update: v5.8.x upstream stable release' kernel team tracking tickets and will align the status).

Remaining todo is to cherry-pick and manually SRU to focal/5.4.

Changed in linux (Ubuntu Hirsute):
status: New → Fix Committed
Changed in linux (Ubuntu Groovy):
status: New → Triaged
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2020-11-10 07:36 EDT-------
(In reply to comment #7)
> Ok, I can see that the commit got accepted with 5.10-rc3, hence it will land
> in hirsute.
> And because the patch was tagged as stable for 5.8, it will land in groovy's
> kernel 5.8 (I'll check the 'Groovy update: v5.8.x upstream stable release'
> kernel team tracking tickets and will align the status).
>
> Remaining todo is to cherry-pick and manually SRU to focal/5.4.

Great, that matches my expectation too.

Revision history for this message
Frank Heimes (fheimes) wrote : Re: [UBUNTU 20.10] NULL pointer dereference when configuring multi-function with devfn != 0 before devfn == 0

I've build patches kernel packages and shared them here for further reference and testing:
https://people.canonical.com/~fheimes/lp1903682/

Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2020-11-11 11:10 EDT-------
(In reply to comment #9)
> I've build patches kernel packages and shared them here for further
> reference and testing:
> https://people.canonical.com/~fheimes/lp1903682/

I've just repeated the original test with this kernel and
everything works as it should, thanks!

Revision history for this message
Frank Heimes (fheimes) wrote : Re: [UBUNTU 20.10] NULL pointer dereference when configuring multi-function with devfn != 0 before devfn == 0

Many thanks Niklas for the quick test!

Frank Heimes (fheimes)
summary: - [UBUNTU 20.10] NULL pointer dereference when configuring multi-function
- with devfn != 0 before devfn == 0
+ NULL pointer dereference when configuring multi-function with devfn != 0
+ before devfn == 0
Revision history for this message
Frank Heimes (fheimes) wrote :

Kernel SRU request submitted for focal:
https://lists.ubuntu.com/archives/kernel-team/2020-November/thread.html#114798
changing status to 'In Progress' for focal.

description: updated
Changed in linux (Ubuntu Focal):
status: New → In Progress
assignee: Frank Heimes (fheimes) → nobody
Changed in linux (Ubuntu Groovy):
assignee: nobody → Frank Heimes (fheimes)
Changed in linux (Ubuntu Hirsute):
status: Fix Committed → Triaged
assignee: nobody → Frank Heimes (fheimes)
Stefan Bader (smb)
Changed in linux (Ubuntu Focal):
importance: Undecided → Medium
status: In Progress → Fix Committed
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: Triaged → In Progress
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote :

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-focal' to 'verification-done-focal'. If the problem still exists, change the tag 'verification-needed-focal' to 'verification-failed-focal'.

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-focal
Revision history for this message
bugproxy (bugproxy) wrote : Comment bridged from LTC Bugzilla

------- Comment From <email address hidden> 2020-12-01 04:45 EDT-------
@Frank Heinz-Werner said you had trouble finding the upstream stable commit for
this.

The original upstream commit is

0b2ca2c7d0c9e2731d01b6c862375d44a7e13923 s390/pci: fix hot-plug of PCI function missing bus

This was pulled into 5.9 stable as part of the following
commit:

https://git.kernel.org/pub/scm/linux/kernel/git/stable/stable-queue.git/commit/?id=c7a8c5e06c4e554a91eeb2df5202e56a9e2acd83

Revision history for this message
Frank Heimes (fheimes) wrote :

Hi Niklas,
I found the ticket upstream accepted with hash 0b2ca2c7d0c9
and the provenance in 'git show 0b2ca2c7d0c9' mentions:
    Cc: <email address hidden> # 5.8
So I'm expecting that in 5.8 (rather than in 5.9) stable - and 5.8 is the kernel used in groovy/20.10.
So I was looking - and couldn't find the patch - in 5.8 stable yet.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-12-01 06:43 EDT-------
(In reply to comment #16)
> Hi Niklas,
> I found the ticket upstream accepted with hash 0b2ca2c7d0c9
> and the provenance in 'git show 0b2ca2c7d0c9' mentions:
> Cc: <email address hidden> # 5.8
> So I'm expecting that in 5.8 (rather than in 5.9) stable - and 5.8 is the
> kernel used in groovy/20.10.
> So I was looking - and couldn't find the patch - in 5.8 stable yet.

Good point, I only got Greg's mail about inclusion in 5.9 stable...
hmm let me see if I can find out why it's not in 5.8 stable.

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-12-01 06:51 EDT-------
Ahh, got it 5.8 stable is already EOL according to https://www.kernel.org/

By the way, is the plan for 21.04 LTS still to go with v5.11,
seeing as Greg announced that v5.10 will be the next long term
stable kernel, picking 5.11 seems a little less ideal.
I'd think it might be easier and give better quality if an
the Ubuntu LTS coincides with one of Greg's longterm stable
kernels.
Then again, personally I have 2 tiny NVMe driver cleanups queued
for 5.11 and those would be my first actual changes to run
on almost all architectures (besides a tiny SR-IOV change but
people don't have that on their laptops :D).

Revision history for this message
Frank Heimes (fheimes) wrote :

Well, that's a pity, because it means that a manual kernel SRU is needed now.
It's needed to make sure that someone who has the fix in focal and upgrades to groovy will not run into a regression situation.

I think the 'plan' for hirsute is still 5.11 - but it of course depends a lot on upstream.
For the interim (aka non-LTS releases) we are not that super keen on LTS kernels, since interim releases are only supported for up to 9 month anyway and we want to offer the latest goodies (the story is of course different for LTS releases though).

Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2020-12-01 08:55 EDT-------
(In reply to comment #19)
> Well, that's a pity, because it means that a manual kernel SRU is needed now.
> It's needed to make sure that someone who has the fix in focal and upgrades
> to groovy will not run into a regression situation.
>
> I think the 'plan' for hirsute is still 5.11 - but it of course depends a
> lot on upstream.
> For the interim (aka non-LTS releases) we are not that super keen on LTS
> kernels, since interim releases are only supported for up to 9 month anyway
> and we want to offer the latest goodies (the story is of course different
> for LTS releases though).

:-( yeah..

On the bright side I have just verified that this is working
now in focal proposed. Thanks!

Revision history for this message
Frank Heimes (fheimes) wrote :

A groovy kernel test build (based on master-next) is available here:
https://people.canonical.com/~fheimes/lp1903682/groovy/

Revision history for this message
Frank Heimes (fheimes) wrote :

Kernel SRU request submitted for groovy:
https://lists.ubuntu.com/archives/kernel-team/2020-December/thread.html#115225
changing status to 'In Progress' for groovy.

Changed in linux (Ubuntu Groovy):
status: Triaged → In Progress
description: updated
Stefan Bader (smb)
Changed in linux (Ubuntu Groovy):
importance: Undecided → Medium
Frank Heimes (fheimes)
Changed in linux (Ubuntu Groovy):
assignee: Frank Heimes (fheimes) → nobody
Ian May (ian-may)
Changed in linux (Ubuntu Groovy):
status: In Progress → Fix Committed
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: In Progress → Fix Committed
Revision history for this message
Kelsey Steele (kelsey-steele) wrote :

Niklas verified fix in Focal proposed (comment #13). updating tag to `verification-done-focal`. thank you!

tags: added: verification-done-focal
removed: verification-needed-focal
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (32.1 KiB)

This bug was fixed in the package linux - 5.4.0-59.65

---------------
linux (5.4.0-59.65) focal; urgency=medium

  * focal/linux: 5.4.0-59.65 -proposed tracker (LP: #1907604)

  * focal: selftests/bpf build broken: test_map_init.skel.h: No such file or
    directory (LP: #1906866)
    - SAUCE: Revert selftests/ "bpf: Zero-fill re-used per-cpu map element"

  * Packaging resync (LP: #1786013)
    - update dkms package versions

  * memory is leaked when tasks are moved to net_prio (LP: #1886859)
    - netprio_cgroup: Fix unlimited memory leak of v2 cgroups

  * Focal update: v5.4.78 upstream stable release (LP: #1905618)
    - drm/i915/gem: Flush coherency domains on first set-domain-ioctl
    - time: Prevent undefined behaviour in timespec64_to_ns()
    - nbd: don't update block size after device is started
    - KVM: arm64: Force PTE mapping on fault resulting in a device mapping
    - PCI: qcom: Make sure PCIe is reset before init for rev 2.1.0
    - usb: dwc3: gadget: Continue to process pending requests
    - usb: dwc3: gadget: Reclaim extra TRBs after request completion
    - btrfs: tracepoints: output proper root owner for trace_find_free_extent()
    - btrfs: sysfs: init devices outside of the chunk_mutex
    - btrfs: reschedule when cloning lots of extents
    - ASoC: Intel: kbl_rt5663_max98927: Fix kabylake_ssp_fixup function
    - genirq: Let GENERIC_IRQ_IPI select IRQ_DOMAIN_HIERARCHY
    - hv_balloon: disable warning when floor reached
    - net: xfrm: fix a race condition during allocing spi
    - ASoC: codecs: wcd9335: Set digital gain range correctly
    - xfs: set xefi_discard when creating a deferred agfl free log intent item
    - netfilter: use actual socket sk rather than skb sk when routing harder
    - netfilter: nf_tables: missing validation from the abort path
    - netfilter: ipset: Update byte and packet counters regardless of whether they
      match
    - powerpc/eeh_cache: Fix a possible debugfs deadlock
    - perf trace: Fix segfault when trying to trace events by cgroup
    - perf tools: Add missing swap for ino_generation
    - ALSA: hda: prevent undefined shift in snd_hdac_ext_bus_get_link()
    - iommu/vt-d: Fix a bug for PDP check in prq_event_thread
    - afs: Fix warning due to unadvanced marshalling pointer
    - can: rx-offload: don't call kfree_skb() from IRQ context
    - can: dev: can_get_echo_skb(): prevent call to kfree_skb() in hard IRQ
      context
    - can: dev: __can_get_echo_skb(): fix real payload length return value for RTR
      frames
    - can: can_create_echo_skb(): fix echo skb generation: always use skb_clone()
    - can: j1939: swap addr and pgn in the send example
    - can: j1939: j1939_sk_bind(): return failure if netdev is down
    - can: ti_hecc: ti_hecc_probe(): add missed clk_disable_unprepare() in error
      path
    - can: xilinx_can: handle failure cases of pm_runtime_get_sync
    - can: peak_usb: add range checking in decode operations
    - can: peak_usb: peak_usb_get_ts_time(): fix timestamp wrapping
    - can: peak_canfd: pucan_handle_can_rx(): fix echo management when loopback is
      on
    - can: flexcan: remove FLEXCAN_QUIRK_DISABLE_MECR quirk for LS1021A
    - c...

Changed in linux (Ubuntu Focal):
status: Fix Committed → Fix Released
Revision history for this message
Ubuntu Kernel Bot (ubuntu-kernel-bot) wrote :

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-groovy' to 'verification-done-groovy'. If the problem still exists, change the tag 'verification-needed-groovy' to 'verification-failed-groovy'.

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-groovy
Frank Heimes (fheimes)
Changed in linux (Ubuntu Hirsute):
status: Triaged → Fix Committed
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2021-01-29 05:42 EDT-------
(In reply to comment #25)
> 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-groovy' to
> 'verification-done-groovy'. If the problem still exists, change the tag
> 'verification-needed-groovy' to 'verification-failed-groovy'.
>
> 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!

Just tested this and can confirm the 5.8.0-42-generic kernel in groovy proposed
fixes the issue. Thanks!

Revision history for this message
Frank Heimes (fheimes) wrote :

Many thx Niklas for the verification on groovy - adjusting tags...

tags: added: verification-done-groovy
removed: verification-needed-groovy
Revision history for this message
Frank Heimes (fheimes) wrote :

Now that kernel 5.10 landed in hirsute's release pocket:
linux-generic | 5.10.0.14.16 | hirsute
the 'hirsute' part can be updated to 'Fix Released".

Changed in linux (Ubuntu Hirsute):
status: Fix Committed → Fix Released
Revision history for this message
Frank Heimes (fheimes) wrote :

For groovy the patch is in Ubuntu-5.8.0-44.50

Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (129.8 KiB)

This bug was fixed in the package linux - 5.8.0-44.50

---------------
linux (5.8.0-44.50) groovy; urgency=medium

  * groovy/linux: 5.8.0-44.50 -proposed tracker (LP: #1914805)

  * Packaging resync (LP: #1786013)
    - update dkms package versions
    - update dkms package versions

  * Introduce the new NVIDIA 460-server series and update the 460 series
    (LP: #1913200)
    - [Config] dkms-versions -- drop NVIDIA 435 455 and 440-server
    - [Config] dkms-versions -- add the 460-server nvidia driver

  * [SRU][G/H/U/OEM-5.10] re-enable s0ix of e1000e (LP: #1910541)
    - Revert "UBUNTU: SAUCE: e1000e: bump up timeout to wait when ME un-configure
      ULP mode"
    - e1000e: Only run S0ix flows if shutdown succeeded
    - Revert "e1000e: disable s0ix entry and exit flows for ME systems"
    - e1000e: Export S0ix flags to ethtool

  * suspend only works once on ThinkPad X1 Carbon gen 7 (LP: #1865570) //
    [SRU][G/H/U/OEM-5.10] re-enable s0ix of e1000e (LP: #1910541)
    - e1000e: bump up timeout to wait when ME un-configures ULP mode

  * Cannot probe sata disk on sata controller behind VMD: ata1.00: failed to
    IDENTIFY (I/O error, err_mask=0x4) (LP: #1894778)
    - PCI: vmd: Offset Client VMD MSI-X vectors

  * Enable mute and micmute LED on HP EliteBook 850 G7 (LP: #1910102)
    - ALSA: hda/realtek: Enable mute and micmute LED on HP EliteBook 850 G7

  * SYNA30B4:00 06CB:CE09 Mouse on HP EliteBook 850 G7 not working at all
    (LP: #1908992)
    - HID: multitouch: Enable multi-input for Synaptics pointstick/touchpad device

  * HD Audio Device PCI ID for the Intel Cometlake-R platform (LP: #1912427)
    - SAUCE: ALSA: hda: Add Cometlake-R PCI ID

  * switch to an autogenerated nvidia series based core via dkms-versions
    (LP: #1912803)
    - [Packaging] nvidia -- use dkms-versions to define versions built
    - [Packaging] update-version-dkms -- maintain flags fields
    - [Config] dkms-versions -- add transitional/skip information for nvidia
      packages

  * udpgro.sh in net from ubuntu_kernel_selftests seems not reflecting sub-test
    result (LP: #1908499)
    - selftests: fix the return value for UDP GRO test

  * [UBUNTU 21.04] vfio: pass DMA availability information to userspace
    (LP: #1907421)
    - vfio/type1: Refactor vfio_iommu_type1_ioctl()
    - vfio iommu: Add dma available capability

  * qede: Kubernetes Internal DNS Failure due to QL41xxx NIC not supporting IPIP
    tx csum offload (LP: #1909062)
    - qede: fix offload for IPIP tunnel packets

  * Use DCPD to control HP DreamColor panel (LP: #1911001)
    - SAUCE: drm/dp: Another HP DreamColor panel brigntness fix

  * Fix right sounds and mute/micmute LEDs for HP ZBook Fury 15/17 G7 Mobile
    Workstation (LP: #1910561)
    - ALSA: hda/realtek: fix right sounds and mute/micmute LEDs for HP machines

  * Ubuntu 20.04 - multicast counter is not increased in ip -s (LP: #1901842)
    - net/mlx5e: Fix multicast counter not up-to-date in "ip -s"

  * eeh-basic.sh in powerpc from ubuntu_kernel_selftests timeout with 5.4 P8 /
    P9 (LP: #1882503)
    - selftests/powerpc/eeh: disable kselftest timeout setting for eeh-basic

  * DMI entry syntax fix for Pegatron /...

Changed in linux (Ubuntu Groovy):
status: Fix Committed → Fix Released
Frank Heimes (fheimes)
Changed in ubuntu-z-systems:
status: Fix Committed → Fix Released
Revision history for this message
bugproxy (bugproxy) wrote :

------- Comment From <email address hidden> 2021-02-24 05:17 EDT-------
IBM Bugzilla status->closed, Fix Released for all requested distros

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.