In drivers/hid/hid-elo.c in the Linux kernel before 5.16.11, a memory leak exists for a certain hid_parse error condition. https://www.openwall.com/lists/oss-security/2022/03/13/1 https://github.com/torvalds/linux/commit/817b8b9c5396d2b2d92311b46719aad5d3339dbe https://cdn.kernel.org/pub/linux/kernel/v5.x/ChangeLog-5.16.11 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=817b8b9c5396d2b2d92311b46719aad5d3339dbe
Created kernel tracking bugs for this issue: Affects: fedora-all [bug 2069409]
This was fixed for Fedora with the 5.16.11 stable kernel updates.
OK, thanks, but I need to express my rant here: For reference: https://lore.kernel.org/linux-input/nycvar.YFH.7.76.2202171420080.11721@cbobk.fhfr.pm/ - in July 2021, commit fbf42729d0e913 was introduced, but while it was taken by the HID maintainers, Greg KH, the USB maintainer rejected the same series because: 1. it's useless, and 2. it was buggy (unfortunately, we didn't caught the bug in the HID tree) - in Jan 2022, commit 817b8b9c5396d (the one referenced by this "CVE") was submitted and accepted, because it obviously fixed the bug from above. - Meanwhile, Alan Stern caught the same bug and solved it properly by reverting fbf42729d0e913 - a discussion happened (lore link from above) and the consensus was to revert both fbf42729d0e913 and 817b8b9c5396d because they are wrong - that decision happened on the 17 Feb 2022 - then, on https://www.openwall.com/lists/oss-security/2022/03/13/1, we see that the person who tried to fixed the bug created a CVE for it, ONE MONTH LATER I do not know the motivations of that person, but the patch had already made it to stable, and IMO is *not* a memory leak, because we are just keeping a reference on the USB device, and can't use it outside of the scope of the module. It will probably mess up the system when the device gets disconnected, but to trigger a DoS on the machine we need: to plug/unplug the forged device a certain amount of time, or script that with virtual USB devices, in which case you need root access to do it. So as stated by the prodsec team, the impact is definitively not high, maybe moderate (but more likely low IMO). I'll fix the rhel8 commit in the same way upstream did (reverting those 2 commits), but still, this is messed up.
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:7444 https://access.redhat.com/errata/RHSA-2022:7444
This issue has been addressed in the following products: Red Hat Enterprise Linux 8 Via RHSA-2022:7683 https://access.redhat.com/errata/RHSA-2022:7683
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2022-27950
This issue has been addressed in the following products: Red Hat Enterprise Linux 8.6 Extended Update Support Via RHSA-2024:1188 https://access.redhat.com/errata/RHSA-2024:1188