Key 5 automatically pressed on some Logitech wireless keyboards

This change was made by a bot.

I also get freezes/hangs, may be unrelated, do you get them too?

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v4.6 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc6-wily/

Yes I WladyX I get freezes, but IIRC this is always how it was on Linux since I use it. :)
Are the freezes happening to you at the same same time the 5 key is repeated?

Joseph Salisbury, yes I can try the latest upstream kernel.
Will let you know the results.

freeze/hang forever, the pc gets stuck and it does not recover, i have to hard reboot it. I could not see the freeze synced with the 5.

I am experiencing this on a Logitech K350

I'm using 4.6.0 rc6 since about a week and haven't experienced this issue since then.
I would treat this as an evidence though. Will be continuing testing with the 4.6 kernel series.
Installed the kernel from here: http://kernel.ubuntu.com/~kernel-ppa/mainline/v4.6-rc6-wily/

I'm using a Logitech K20 wireless keyboard and it randomly repeats 5555555555555.
After an event the fist key pressed (no matter which key) is not recognized.
It is pretty annoying especially when writing a text or while programming.
Does not happen under Windows (same computer).

I'm running the latest and greatest Kubuntu though:
4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I also get this behaviour with my Logitech K520 keyboard and unifying receiver, on Ubuntu 16.04 and on 15.10 before that.

I'm currently running
4.4.0-22-generic #40-Ubuntu SMP Thu May 12 22:03:46 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

The same bug has been reported on the RedHat bug tracker: https://bugzilla.redhat.com/show_bug.cgi?id=1278818

According to that, the hid-logitech-hidpp driver might be the culprit.

I'm interested to hear that Viktor has not yet seen the problem with the 4.6 kernel. Viktor, please keep us posted when you've run it for a bit longer!

I have been having the same problem ever since I got my K800 wireless keyboard. Ubuntu 15.10 - it happens also when the keyboard is turned off.

Ubuntu 15.10 and 16.04, Keyboard K520.

I buy new keyboard and receiver and it's don't fix my problem.
I never seen this bug on Windows and Ubuntu 15.04 on same host.

Still not able to reproduce this with 4.6 kernel series.
It is very likely that this issue is already fixed there.
Any chance this could be backported to the xenial kernel as this is an LTS release?

Doug, you added the tag 'kernel-fixed-upstream' but I don't think we have hard evidence of that at this point. Was your tagging based only on Viktor's reports that it hasn't happened (yet) on a 4.6 kernel, or is there more information elsewhere?

Viktor, your result with 4.6 is promising! However, since this problem is known to "come and go" it is also possible that code has just moved around such that its just not manifesting in your current 4.6 kernel build you currently (but could reappear in some future build of 4.6).

I do see one potentially interesting fix in 4.6 (50220de HID: core: prevent out-of-bound reading). I'm going to produce a test kernel with just that fix backported on top of Xenial 4.4.0-22.40 (which I've seen manifest the problem), and will post that here for further testing.

I've built a test kernel for Ubuntu Xenial 16.04 (amd64) which comprised of 4.4.0-22.40 plus:
    [mainline] 50220de HID: core: prevent out-of-bound readings

The test kernel is here (most users will only need to 'dpkg -i' install the linux-image-4.4.0...deb):

    http://people.canonical.com/~kamal/lp1579190-logitech-55555555/

After installing, please verify that 'uname -a' shows this version number:
    4.4.0-22-generic #40+lp1579190

If you *still* experience the "55555555" problem with this test kernel, please post that here immediately!

If you do not experience the problem anymore, then please post that here after a few days of testing time. Thanks!

I have just installed the patched version. I had to remove both 4.6 and also the 4.4.0 signed image (which was broken by the install of the patched version).

I'll report either way in a week or 2 (or sooner if the bug appears again).

U1604-MATE:~$ uname -a
Linux U1604-MATE 4.4.0-22-generic #40+lp1579190 SMP Fri Jun 3 15:50:59 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

I have been running the patched kernel for a couple of days now. The 5555555's have totally ceased. I was experiencing the 55555's frequently daily prior to the patch but I realize the problem often vanishes for periods of time. I will test for another week or so and also will inform you promptly if I have a 5555555's event prior to then.

I am still testing #40+lp1579190 and have not experienced 55555555555's yet but on an install of the new linux mint 18 Beta I have upped from the default 4.4.0-21-generic to 4.4.0-24-generic #43-Ubuntu SMP and have had no incidents of 5555555's in the 2 days I have had it installed. Will continue testing the patch on U and 4.4.0-24 #43 on LM.

I mention this because 'maybe' a look into 4.4.0-24-generic #4 may be worthwhile. ?????

4.4.0-24-generic #43-Ubuntu SMP just failed. I went to reply to a thunderbird email. 5555555555555's went wild. #40+lp157919 is still okay.

4.4.0-24-generic #43-Ubuntu SMP just failed for me as well.

I had installed it a few days ago and it was OK, but just went wild again with repeating 5555555555555's. It may be a coincidence, but I also was using Thunderbird at the time.

I shall revert to the patched version.

Hi Tim Passingham (tim-8aw3u04umo),

you are not using the patched kernel.
The patched is: 4.4.0-22-generic #40+lp1579190
And you are using: 4.4.0-24

What might have happened is that you installed the patched kernel and then you updated Ubuntu and 4.4.0-24 was installed and set as the default kernel.
So after you restarted your machine your OS is not running the patched kernel any more.
To run the patched kernel you either have to modify the default kernel in the GRUB configuration or explicitly choose the patched kernel on startup.

BTW, I'm running 4.4.0-22-generic #40+lp1579190 since few days without any issues.
Any chance for this patch to get into the Ubuntu 16.04 repositories?

Sorry, I should have explained better. I was using the patched kernel, with no problems. When the 24 update came up for installation a few days ago I thought I would try it, so I did. Today that newer version still showed the same problem, so I have reverted to the patched version (by using grub customizer to make it the default choice and checking with uname).

Hi Tim Passingham (tim-8aw3u04umo),

the new kernel you installed (4.4.0-24) will definitely produce the issue as it does not contain the patch.
Please clarify if you where also able to reproduce the issue with 4.4.0-22-generic #40+lp1579190.

As I said, "I was using the patched kernel, with no problems". I was away for a few days so have probably only run 4.4.0-22-generic #40+lp1579190 for 4 or 5 days in all, so far without seeing the problem, but it is transient.

4.4.0-24 didn't display the fault for a couple of days, and then did today.

Summary of test kernel results: All users of the test kernel have reported that it does appear to eliminate the 555555555 problem.

I will get the fix patch ([mainline] 50220de HID: core: prevent out-of-bound readings) into the pipeline for all affected Ubuntu kernels, and a note will be posted here once those kernels become available.

Thanks all, for the testing help!

Status changed to 'Confirmed' because the bug affects multiple users.

Is there an obvious reason why users of trusty never had this problem before, even though the fix seems to apply to many versions?

Tim, its essentially the same reason that we saw the problem manifest in some Wily and Xenial kernel versions, then seem to disappear in the next kernel version, only to return again in some future version:

The bug, which definitely existed all the way back through Precise, was that the driver could access the wrong data (an out of bounds array access) in some circumstances. The theory is that for any each individual kernel build, that particular wrong data it accesses might end up containing 'the 5 key' (making this bug manifest) or might end up containing a 'null' (resulting in no obvious manifestation for that kernel build). Its plausible that in Precise, the kernel builds just always ended up with a 'null' there.

The fix patch ([mainline] 50220de HID: core: prevent out-of-bound readings) prevents the driver from accessing that wrong data at all, which is certainly the correct behavior whether or not the 55555 problem was seen to manifest.

Kamal, Thanks very much for taking the time to explain this.

Thanks for the fix, where can I apply it now? Ubuntu Xenial. In 2 hours this bug has happened no less than 20 times. Everything is currently updated.

Darren, the fix is scheduled to be released in all affected Ubuntu versions in the near future and a note will be posted here at that time. In the meantime, the Xenial (amd64) test kernel indicated in Comment #16 should offer you some relief.

I'm having the same issue. I'm on Xubuntu 16.04 and using logitech k800. The only way to stop the issue is by logging out of the desktop. I'll be trying the patched kernel today. I hope it works.

A new Xenial kernel was released today (28/6/16) - 4.4.0-28. Is the fix in that version?

I just looked at the change log at the today's kernel (4.4.0-28) and the fix for this bug is not listed in the change log.

When, oh my, just when is it going to be released? Please! This is very annoying.

The "out of the normal cycle" kernel versions released yesterday were for a security fix, and so do _not_ include the fix for this bug.

The "normal cycle" kernel versions that we're preparing this week _do_ include this fix. A note will be posted here as soon as those kernels reach the -proposed archive.

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-precise' to 'verification-done-precise'.

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!

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-trusty' to 'verification-done-trusty'.

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!

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-vivid' to 'verification-done-vivid'.

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!

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-wily' to 'verification-done-wily'.

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!

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-xenial' to 'verification-done-xenial'.

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!

Affected users: As noted above, the kernel versions available in the -proposed include this fix now. Since the problem can't be positively verified, we'll consider the problem "verified" as long as we do not get any reports to the contrary in the next few days.

So, if you install the -proposed kernel and yet still experience any instance of the 55555555 problem, please post that here along with the output of 'uname -a'.

On xenial I found it easiest to:

- add the proposed repository via 'Software and Updates', in the 'Developer Options' tab, tick the 'pre-released updates' box

- using synaptic, reload the repos, mark all upgrades, and then tick only the 4 'linux-..' kernel items to get version 4.4.0.29.

- I then updated just these

- I then went back to untick the 'pre-released updates' box so I don't get any more test versions.

I assume testers need to post both positive and negative results here by Sunday 3rd June - please confirm this.

Do us users change the status of this bug, or does Kamal?

Thanks for posting the handy instructions, Tim.

It isn't really necessary for all previously affected users to post "positive" results (since they will necessarily be inconclusive anyway). As long as we get at least a couple of folks (including myself) to report no further instance of the problem with the -proposed kernel by mid-next-week, we'll call it resolved.

I will handle manipulating the bug status and all the "verified-done-xxxx" tags at that time; users do not need to adjust them.

Kamal - thanks for the clarification.

I have had no further problems when using the proposed kernel, so it works for me.

This bug was fixed in the package linux - 4.4.0-30.49

---------------
linux (4.4.0-30.49) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1597897

  * FCP devices are not detected correctly nor deterministically (LP: #1567602)
    - scsi_dh_alua: Disable ALUA handling for non-disk devices
    - scsi_dh_alua: Use vpd_pg83 information
    - scsi_dh_alua: improved logging
    - scsi_dh_alua: sanitze sense code handling
    - scsi_dh_alua: use standard logging functions
    - scsi_dh_alua: return standard SCSI return codes in submit_rtpg
    - scsi_dh_alua: fixup description of stpg_endio()
    - scsi_dh_alua: use flag for RTPG extended header
    - scsi_dh_alua: use unaligned access macros
    - scsi_dh_alua: rework alua_check_tpgs() to return the tpgs mode
    - scsi_dh_alua: simplify sense code handling
    - scsi: Add scsi_vpd_lun_id()
    - scsi: Add scsi_vpd_tpg_id()
    - scsi_dh_alua: use scsi_vpd_tpg_id()
    - scsi_dh_alua: Remove stale variables
    - scsi_dh_alua: Pass buffer as function argument
    - scsi_dh_alua: separate out alua_stpg()
    - scsi_dh_alua: Make stpg synchronous
    - scsi_dh_alua: call alua_rtpg() if stpg fails
    - scsi_dh_alua: switch to scsi_execute_req_flags()
    - scsi_dh_alua: allocate RTPG buffer separately
    - scsi_dh_alua: Use separate alua_port_group structure
    - scsi_dh_alua: use unique device id
    - scsi_dh_alua: simplify alua_initialize()
    - revert commit a8e5a2d593cb ("[SCSI] scsi_dh_alua: ALUA handler attach should
      succeed while TPG is transitioning")
    - scsi_dh_alua: move optimize_stpg evaluation
    - scsi_dh_alua: remove 'rel_port' from alua_dh_data structure
    - scsi_dh_alua: Use workqueue for RTPG
    - scsi_dh_alua: Allow workqueue to run synchronously
    - scsi_dh_alua: Add new blacklist flag 'BLIST_SYNC_ALUA'
    - scsi_dh_alua: Recheck state on unit attention
    - scsi_dh_alua: update all port states
    - scsi_dh_alua: Send TEST UNIT READY to poll for transitioning
    - scsi_dh_alua: do not fail for unknown VPD identification

linux (4.4.0-29.48) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1597015

  * Wireless hotkey fails on Dell XPS 15 9550 (LP: #1589886)
    - intel-hid: new hid event driver for hotkeys
    - intel-hid: fix incorrect entries in intel_hid_keymap
    - intel-hid: allocate correct amount of memory for private struct
    - intel-hid: add a workaround to ignore an event after waking up from S4.
    - [Config] CONFIG_INTEL_HID_EVENT=m

  * cgroupfs mounts can hang (LP: #1588056)
    - Revert "UBUNTU: SAUCE: (namespace) mqueue: Super blocks must be owned by the
      user ns which owns the ipc ns"
    - Revert "UBUNTU: SAUCE: kernfs: Do not match superblock in another user
      namespace when mounting"
    - Revert "UBUNTU: SAUCE: cgroup: Use a new super block when mounting in a
      cgroup namespace"
    - (namespace) bpf: Use mount_nodev not mount_ns to mount the bpf filesystem
    - (namespace) bpf, inode: disallow userns mounts
    - (namespace) ipc: Initialize ipc_namespace->user_ns early.
    - (namespace) vfs: Pass data, ns, and ns->userns to mount_ns
    - SAUCE: (namespace) S...

I assume I don't have to test 4.4.0-30 as well?

Tim: Correct, there is no need to also test 4.4.0-30.

Given that we've had no further reports of this problem, we'll now consider it to be verified as fixed in the -proposed kernels. Those kernels are scheduled to be released via standard -updates within the next week.

Excellent!

I notice that there's no mention of a yakety release. Is that deliberate?

The fix was already present in the Yakkety kernel (since the fix in mainline Linux v4.6, upon which Yakkety is currently based).

Sorry, I forgot that.

I have this issue with an MK710 on Ubuntu 15.10

Glad there is a fix. Sorry I am not clear. Will this be in an automatic update for 15.10 or should I manually update the kernel?

This fix will appear in the next normal automatic kernel update for 15.10 (which currently scheduled for July 18 -- my previous estimate was off by one week).

However, that kernel is available in the "-proposed" archive right now, so if you don't want to wait for the normal update you can install it early: see instructions in comment #45.

This bug was fixed in the package linux - 4.4.0-31.50

---------------
linux (4.4.0-31.50) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1602449

  * nouveau: boot hangs at blank screen with unsupported graphics cards
    (LP: #1602340)
    - SAUCE: drm: check for supported chipset before booting fbdev off the hw

linux (4.4.0-30.49) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1597897

  * FCP devices are not detected correctly nor deterministically (LP: #1567602)
    - scsi_dh_alua: Disable ALUA handling for non-disk devices
    - scsi_dh_alua: Use vpd_pg83 information
    - scsi_dh_alua: improved logging
    - scsi_dh_alua: sanitze sense code handling
    - scsi_dh_alua: use standard logging functions
    - scsi_dh_alua: return standard SCSI return codes in submit_rtpg
    - scsi_dh_alua: fixup description of stpg_endio()
    - scsi_dh_alua: use flag for RTPG extended header
    - scsi_dh_alua: use unaligned access macros
    - scsi_dh_alua: rework alua_check_tpgs() to return the tpgs mode
    - scsi_dh_alua: simplify sense code handling
    - scsi: Add scsi_vpd_lun_id()
    - scsi: Add scsi_vpd_tpg_id()
    - scsi_dh_alua: use scsi_vpd_tpg_id()
    - scsi_dh_alua: Remove stale variables
    - scsi_dh_alua: Pass buffer as function argument
    - scsi_dh_alua: separate out alua_stpg()
    - scsi_dh_alua: Make stpg synchronous
    - scsi_dh_alua: call alua_rtpg() if stpg fails
    - scsi_dh_alua: switch to scsi_execute_req_flags()
    - scsi_dh_alua: allocate RTPG buffer separately
    - scsi_dh_alua: Use separate alua_port_group structure
    - scsi_dh_alua: use unique device id
    - scsi_dh_alua: simplify alua_initialize()
    - revert commit a8e5a2d593cb ("[SCSI] scsi_dh_alua: ALUA handler attach should
      succeed while TPG is transitioning")
    - scsi_dh_alua: move optimize_stpg evaluation
    - scsi_dh_alua: remove 'rel_port' from alua_dh_data structure
    - scsi_dh_alua: Use workqueue for RTPG
    - scsi_dh_alua: Allow workqueue to run synchronously
    - scsi_dh_alua: Add new blacklist flag 'BLIST_SYNC_ALUA'
    - scsi_dh_alua: Recheck state on unit attention
    - scsi_dh_alua: update all port states
    - scsi_dh_alua: Send TEST UNIT READY to poll for transitioning
    - scsi_dh_alua: do not fail for unknown VPD identification

linux (4.4.0-29.48) xenial; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1597015

  * Wireless hotkey fails on Dell XPS 15 9550 (LP: #1589886)
    - intel-hid: new hid event driver for hotkeys
    - intel-hid: fix incorrect entries in intel_hid_keymap
    - intel-hid: allocate correct amount of memory for private struct
    - intel-hid: add a workaround to ignore an event after waking up from S4.
    - [Config] CONFIG_INTEL_HID_EVENT=m

  * cgroupfs mounts can hang (LP: #1588056)
    - Revert "UBUNTU: SAUCE: (namespace) mqueue: Super blocks must be owned by the
      user ns which owns the ipc ns"
    - Revert "UBUNTU: SAUCE: kernfs: Do not match superblock in another user
      namespace when mounting"
    - Revert "UBUNTU: SAUCE: cgroup: Use a new super block when mounting in a
      cgroup namespace"
    - (name...

This bug was fixed in the package linux - 4.2.0-42.49

---------------
linux (4.2.0-42.49) wily; urgency=low

  [ Ben Romer ]

  * Release Tracking Bug
    - LP: #1597053

  [ Josh Boyer ]

  * SAUCE: UEFI: acpi: Ignore acpi_rsdp kernel parameter when module
    loading is restricted
    - LP: #1566221
  * SAUCE: UEFI: efi: Make EFI_SECURE_BOOT_SIG_ENFORCE depend on EFI
    - LP: #1566221
  * SAUCE: UEFI MODSIGN: Import certificates from UEFI Secure Boot
    - LP: #1571691
  * SAUCE: UEFI: efi: Disable secure boot if shim is in insecure mode
    - LP: #1571691

  [ Matthew Garrett ]

  * SAUCE: UEFI: Add secure_modules() call
    - LP: #1566221
  * SAUCE: UEFI: PCI: Lock down BAR access when module security is enabled
    - LP: #1566221
  * SAUCE: UEFI: x86: Lock down IO port access when module security is
    enabled
    - LP: #1566221
  * SAUCE: UEFI: ACPI: Limit access to custom_method
    - LP: #1566221
  * SAUCE: UEFI: asus-wmi: Restrict debugfs interface when module loading
    is restricted
    - LP: #1566221
  * SAUCE: UEFI: Restrict /dev/mem and /dev/kmem when module loading is
    restricted
    - LP: #1566221
  * SAUCE: UEFI: kexec: Disable at runtime if the kernel enforces module
    loading restrictions
    - LP: #1566221
  * SAUCE: UEFI: x86: Restrict MSR access when module loading is restricted
    - LP: #1566221
  * SAUCE: UEFI: Add option to automatically enforce module signatures when
    in Secure Boot mode
    - LP: #1566221

  [ Stefan Bader ]

  * [Config] Add pm80xx scsi driver to d-i
    - LP: #1595628

  [ Tim Gardner ]

  * [Config] CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
  * SAUCE: UEFI: Display MOKSBState when disabled
    - LP: #1571691
  * SAUCE: UEFI: Add secure boot and MOK SB State disabled sysctl
    - LP: #1593075

  [ Upstream Kernel Changes ]

  * Revert "scsi: fix soft lockup in scsi_remove_target() on module
    removal"
    - LP: #1592552
  * ath10k: fix firmware assert in monitor mode
    - LP: #1592552
  * drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
    - LP: #1592552
  * ath10k: fix debugfs pktlog_filter write
    - LP: #1592552
  * drm/i915: Call intel_dp_mst_resume() before resuming displays
    - LP: #1592552
  * ARM: mvebu: fix GPIO config on the Linksys boards
    - LP: #1592552
  * ath5k: Change led pin configuration for compaq c700 laptop
    - LP: #1592552, #972604
  * xfs: disallow rw remount on fs with unknown ro-compat features
    - LP: #1592552
  * xfs: Don't wrap growfs AGFL indexes
    - LP: #1592552
  * rtlwifi: rtl8723be: Add antenna select module parameter
    - LP: #1592552
  * rtlwifi: btcoexist: Implement antenna selection
    - LP: #1592552
  * drm/gma500: Fix possible out of bounds read
    - LP: #1592552
  * Bluetooth: vhci: fix open_timeout vs. hdev race
    - LP: #1592552
  * Bluetooth: vhci: purge unhandled skbs
    - LP: #1592552
  * cpuidle: Indicate when a device has been unregistered
    - LP: #1592552
  * mfd: intel_quark_i2c_gpio: Use clkdev_create()
    - LP: #1592552
  * mfd: intel_quark_i2c_gpio: Remove clock tree on error path
    - LP: #1592552
  * [media] media: v4l2-compat-ioctl32: fix missing reserved field copy in
    put_v4l2_create32
    -...

This bug was fixed in the package linux - 3.19.0-65.73

---------------
linux (3.19.0-65.73) vivid; urgency=low

  [ Ben Romer ]

  * Release Tracking Bug
    - LP: #1596631

  [ Josh Boyer ]

  * SAUCE: UEFI: acpi: Ignore acpi_rsdp kernel parameter when module
    loading is restricted
    - LP: #1566221
  * SAUCE: UEFI: efi: Make EFI_SECURE_BOOT_SIG_ENFORCE depend on EFI
    - LP: #1566221
  * SAUCE: UEFI MODSIGN: Import certificates from UEFI Secure Boot
    - LP: #1571691
  * SAUCE: UEFI: efi: Disable secure boot if shim is in insecure mode
    - LP: #1571691

  [ Matthew Garrett ]

  * SAUCE: UEFI: Add secure_modules() call
    - LP: #1566221
  * SAUCE: UEFI: PCI: Lock down BAR access when module security is enabled
    - LP: #1566221
  * SAUCE: UEFI: x86: Lock down IO port access when module security is
    enabled
    - LP: #1566221
  * SAUCE: UEFI: ACPI: Limit access to custom_method
    - LP: #1566221
  * SAUCE: UEFI: asus-wmi: Restrict debugfs interface when module loading
    is restricted
    - LP: #1566221
  * SAUCE: UEFI: Restrict /dev/mem and /dev/kmem when module loading is
    restricted
    - LP: #1566221
  * SAUCE: UEFI: kexec: Disable at runtime if the kernel enforces module
    loading restrictions
    - LP: #1566221
  * SAUCE: UEFI: x86: Restrict MSR access when module loading is restricted
    - LP: #1566221
  * SAUCE: UEFI: Add option to automatically enforce module signatures when
    in Secure Boot mode
    - LP: #1566221

  [ Stefan Bader ]

  * [Config] Add pm80xx scsi driver to d-i
    - LP: #1595628

  [ Tim Gardner ]

  * [Config] CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
  * SAUCE: UEFI: Display MOKSBState when disabled
    - LP: #1571691
  * SAUCE: UEFI: Add secure boot and MOK SB State disabled sysctl
    - LP: #1593075

  [ Upstream Kernel Changes ]

  * HID: core: prevent out-of-bound readings
    - LP: #1579190
  * mm: migrate dirty page without clear_page_dirty_for_io etc
    - LP: #1581865
    - CVE-2016-3070

 -- Benjamin M Romer <email address hidden> Mon, 27 Jun 2016 12:37:48 -0400

This bug was fixed in the package linux - 3.13.0-92.139

---------------
linux (3.13.0-92.139) trusty; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1597060

  [ Josh Boyer ]

  * SAUCE: UEFI: acpi: Ignore acpi_rsdp kernel parameter when module
    loading is restricted
    - LP: #1566221
  * SAUCE: UEFI: efi: Make EFI_SECURE_BOOT_SIG_ENFORCE depend on EFI
    - LP: #1566221
  * SAUCE: UEFI MODSIGN: Import certificates from UEFI Secure Boot
    - LP: #1566221, #1571691
  * SAUCE: UEFI: efi: Disable secure boot if shim is in insecure mode
    - LP: #1566221, #1571691

  [ Matthew Garrett ]

  * SAUCE: UEFI: Add secure_modules() call
    - LP: #1566221
  * SAUCE: UEFI: PCI: Lock down BAR access when module security is enabled
    - LP: #1566221
  * SAUCE: UEFI: x86: Lock down IO port access when module security is
    enabled
    - LP: #1566221
  * SAUCE: UEFI: ACPI: Limit access to custom_method
    - LP: #1566221
  * SAUCE: UEFI: asus-wmi: Restrict debugfs interface when module loading
    is restricted
    - LP: #1566221
  * SAUCE: UEFI: Restrict /dev/mem and /dev/kmem when module loading is
    restricted
    - LP: #1566221
  * SAUCE: UEFI: kexec: Disable at runtime if the kernel enforces module
    loading restrictions
    - LP: #1566221
  * SAUCE: UEFI: x86: Restrict MSR access when module loading is restricted
    - LP: #1566221
  * SAUCE: UEFI: Add option to automatically enforce module signatures when
    in Secure Boot mode
    - LP: #1566221

  [ Stefan Bader ]

  * [Config] Add pm80xx scsi driver to d-i
    - LP: #1595628

  [ Tim Gardner ]

  * [Config] CONFIG_EFI_SECURE_BOOT_SIG_ENFORCE=y
  * SAUCE: UEFI: Display MOKSBState when disabled
    - LP: #1566221, #1571691
  * SAUCE: UEFI: Add secure boot and MOK SB State disabled sysctl
    - LP: #1593075
  * SAUCE: UEFI: Set EFI_SECURE_BOOT bit in x86_efi_facility
    - LP: #1593075
  * [Config] CONFIG_EFI=n for arm64
    - LP: #1566221

  [ Upstream Kernel Changes ]

  * powerpc/tm: Abort syscalls in active transactions
    - LP: #1572624
  * HID: core: prevent out-of-bound readings
    - LP: #1579190
  * efi: Add separate 32-bit/64-bit definitions
    - LP: #1566221
  * x86/efi: Build our own EFI services pointer table
    - LP: #1566221
  * mm: migrate dirty page without clear_page_dirty_for_io etc
    - LP: #1581865
    - CVE-2016-3070
  * oom_kill: change oom_kill.c to use for_each_thread()
    - LP: #1592429
  * oom_kill: has_intersects_mems_allowed() needs rcu_read_lock()
    - LP: #1592429
  * oom_kill: add rcu_read_lock() into find_lock_task_mm()
    - LP: #1592429
  * virtio_balloon: return the amount of freed memory from leak_balloon()
    - LP: #1587089
  * virtio_balloon: free some memory from balloon on OOM
    - LP: #1587089
  * virtio_ballon: change stub of release_pages_by_pfn
    - LP: #1587089
  * virtio_balloon: do not change memory amount visible via /proc/meminfo
    - LP: #1587089

 -- Kamal Mostafa <email address hidden> Tue, 28 Jun 2016 12:40:49 -0700

This bug was fixed in the package linux - 3.2.0-106.147

---------------
linux (3.2.0-106.147) precise; urgency=low

  [ Kamal Mostafa ]

  * Release Tracking Bug
    - LP: #1597109

  [ Upstream Kernel Changes ]

  * HID: core: prevent out-of-bound readings
    - LP: #1579190

 -- Kamal Mostafa <email address hidden> Tue, 28 Jun 2016 14:09:30 -0700

I'm also experiencing this bug on a K350 keyboard on Ubuntu 16.10. It's been a problem on and off for a few years with this same keyboard though.

I'm experiencing this on a K350 keyboard, on 4.4.0-21-generic kernel (fresh install of Linux Mint 18 Sarah / Ubuntu 16.04 LTS).

I usually see the problem after changing windows by clicking on one in the panel. As the new window takes focus, the 55555555...5555555's start flying.

Another curious symptom: occasionally, pressing the number "5" key while typing does not output anything. It just happened while I was typing this sentence.

But after having read all the above posts, I am going to try a kernel upgrade now. For some reason Mint has marked the kernel updates as "unsafe" which why I'm still on the release kernel of 4.4.0-21-generic.

I will report my results.

Greetings Geoffrey,

I'm running the latest Mint (18) and I did not see issues with my K520 keyboard so far.
I'm using the kernel that comes (I guess 4.4) with the release.
So I guess updating the kernel to the latest should definitely help.
The patch was released with 4.4.0-31.50 as I see.

Thanks Viktor.
Following my post #65...
I've been running kernel 4.4.0-47-generic for a week now and the problem has not come up once.
So for my part, the kernel update has fixed it.

I have been having the same problem ever since I got my K800 wireless keyboard.
example: 55555555555555555..... etc
I am using Ubuntu 16.10

please help. I dont know what to do

i forgot to add, i am running linux-image-4.2.0-36-generic

Earlier posts say this bug was fixed in linux 4.4.0-30.49. My system has been fine since then.

walterramjet, the 55555 bug was indeed still present in your kernel version (4.2.0-36.*). For the 4.2.0 kernel series, it was fixed in version 4.2.0-42.49 as noted in comment #59 here, so running a regular system software update is probably what you need to do.

However, its confusing that you also mention that you're running Ubuntu 16.10 ("Yakkety") since Yakkety's kernel series is 4.8.0. Perhaps you're actually running Ubuntu 15.10 ("Wily") which used the 4.2.0 kernel series. If so, note that Wily is now past its end-of-life and is no longer supported.