From: Greg Kroah-Hartman Date: Sun, 23 Jan 2022 14:00:30 +0000 (+0100) Subject: 5.10-stable patches X-Git-Tag: v4.4.300~146 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=eb088bccfe57d623bb69f3be3e5117d4d71f4ad4;p=thirdparty%2Fkernel%2Fstable-queue.git 5.10-stable patches added patches: hid-uhid-fix-worker-destroying-device-without-any-protection.patch hid-wacom-avoid-using-stale-array-indicies-to-read-contact-count.patch hid-wacom-ignore-the-confidence-flag-when-a-touch-is-removed.patch hid-wacom-reset-expected-and-received-contact-counts-at-the-same-time.patch --- diff --git a/queue-5.10/hid-uhid-fix-worker-destroying-device-without-any-protection.patch b/queue-5.10/hid-uhid-fix-worker-destroying-device-without-any-protection.patch new file mode 100644 index 00000000000..a116313e63b --- /dev/null +++ b/queue-5.10/hid-uhid-fix-worker-destroying-device-without-any-protection.patch @@ -0,0 +1,101 @@ +From 4ea5763fb79ed89b3bdad455ebf3f33416a81624 Mon Sep 17 00:00:00 2001 +From: Jann Horn +Date: Fri, 14 Jan 2022 14:33:30 +0100 +Subject: HID: uhid: Fix worker destroying device without any protection + +From: Jann Horn + +commit 4ea5763fb79ed89b3bdad455ebf3f33416a81624 upstream. + +uhid has to run hid_add_device() from workqueue context while allowing +parallel use of the userspace API (which is protected with ->devlock). +But hid_add_device() can fail. Currently, that is handled by immediately +destroying the associated HID device, without using ->devlock - but if +there are concurrent requests from userspace, that's wrong and leads to +NULL dereferences and/or memory corruption (via use-after-free). + +Fix it by leaving the HID device as-is in the worker. We can clean it up +later, either in the UHID_DESTROY command handler or in the ->release() +handler. + +Cc: stable@vger.kernel.org +Fixes: 67f8ecc550b5 ("HID: uhid: fix timeout when probe races with IO") +Signed-off-by: Jann Horn +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/uhid.c | 29 +++++++++++++++++++++++++---- + 1 file changed, 25 insertions(+), 4 deletions(-) + +--- a/drivers/hid/uhid.c ++++ b/drivers/hid/uhid.c +@@ -28,11 +28,22 @@ + + struct uhid_device { + struct mutex devlock; ++ ++ /* This flag tracks whether the HID device is usable for commands from ++ * userspace. The flag is already set before hid_add_device(), which ++ * runs in workqueue context, to allow hid_add_device() to communicate ++ * with userspace. ++ * However, if hid_add_device() fails, the flag is cleared without ++ * holding devlock. ++ * We guarantee that if @running changes from true to false while you're ++ * holding @devlock, it's still fine to access @hid. ++ */ + bool running; + + __u8 *rd_data; + uint rd_size; + ++ /* When this is NULL, userspace may use UHID_CREATE/UHID_CREATE2. */ + struct hid_device *hid; + struct uhid_event input_buf; + +@@ -63,9 +74,18 @@ static void uhid_device_add_worker(struc + if (ret) { + hid_err(uhid->hid, "Cannot register HID device: error %d\n", ret); + +- hid_destroy_device(uhid->hid); +- uhid->hid = NULL; ++ /* We used to call hid_destroy_device() here, but that's really ++ * messy to get right because we have to coordinate with ++ * concurrent writes from userspace that might be in the middle ++ * of using uhid->hid. ++ * Just leave uhid->hid as-is for now, and clean it up when ++ * userspace tries to close or reinitialize the uhid instance. ++ * ++ * However, we do have to clear the ->running flag and do a ++ * wakeup to make sure userspace knows that the device is gone. ++ */ + uhid->running = false; ++ wake_up_interruptible(&uhid->report_wait); + } + } + +@@ -474,7 +494,7 @@ static int uhid_dev_create2(struct uhid_ + void *rd_data; + int ret; + +- if (uhid->running) ++ if (uhid->hid) + return -EALREADY; + + rd_size = ev->u.create2.rd_size; +@@ -556,7 +576,7 @@ static int uhid_dev_create(struct uhid_d + + static int uhid_dev_destroy(struct uhid_device *uhid) + { +- if (!uhid->running) ++ if (!uhid->hid) + return -EINVAL; + + uhid->running = false; +@@ -565,6 +585,7 @@ static int uhid_dev_destroy(struct uhid_ + cancel_work_sync(&uhid->worker); + + hid_destroy_device(uhid->hid); ++ uhid->hid = NULL; + kfree(uhid->rd_data); + + return 0; diff --git a/queue-5.10/hid-wacom-avoid-using-stale-array-indicies-to-read-contact-count.patch b/queue-5.10/hid-wacom-avoid-using-stale-array-indicies-to-read-contact-count.patch new file mode 100644 index 00000000000..068c61a3328 --- /dev/null +++ b/queue-5.10/hid-wacom-avoid-using-stale-array-indicies-to-read-contact-count.patch @@ -0,0 +1,44 @@ +From 20f3cf5f860f9f267a6a6e5642d3d0525edb1814 Mon Sep 17 00:00:00 2001 +From: Jason Gerecke +Date: Tue, 18 Jan 2022 14:38:41 -0800 +Subject: HID: wacom: Avoid using stale array indicies to read contact count + +From: Jason Gerecke + +commit 20f3cf5f860f9f267a6a6e5642d3d0525edb1814 upstream. + +If we ever see a touch report with contact count data we initialize +several variables used to read the contact count in the pre-report +phase. These variables are never reset if we process a report which +doesn't contain a contact count, however. This can cause the pre- +report function to trigger a read of arbitrary memory (e.g. NULL +if we're lucky) and potentially crash the driver. + +This commit restores resetting of the variables back to default +"none" values that were used prior to the commit mentioned +below. + +Link: https://github.com/linuxwacom/input-wacom/issues/276 +Fixes: 003f50ab673c (HID: wacom: Update last_slot_field during pre_report phase) +CC: stable@vger.kernel.org +Signed-off-by: Jason Gerecke +Reviewed-by: Ping Cheng +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/wacom_wac.c | 4 ++++ + 1 file changed, 4 insertions(+) + +--- a/drivers/hid/wacom_wac.c ++++ b/drivers/hid/wacom_wac.c +@@ -2654,6 +2654,10 @@ static void wacom_wac_finger_pre_report( + + hid_data->confidence = true; + ++ hid_data->cc_report = 0; ++ hid_data->cc_index = -1; ++ hid_data->cc_value_index = -1; ++ + for (i = 0; i < report->maxfield; i++) { + struct hid_field *field = report->field[i]; + int j; diff --git a/queue-5.10/hid-wacom-ignore-the-confidence-flag-when-a-touch-is-removed.patch b/queue-5.10/hid-wacom-ignore-the-confidence-flag-when-a-touch-is-removed.patch new file mode 100644 index 00000000000..5040ee6b89a --- /dev/null +++ b/queue-5.10/hid-wacom-ignore-the-confidence-flag-when-a-touch-is-removed.patch @@ -0,0 +1,80 @@ +From df03e9bd6d4806619b4cdc91a3d7695818a8e2b7 Mon Sep 17 00:00:00 2001 +From: Jason Gerecke +Date: Tue, 18 Jan 2022 14:37:56 -0800 +Subject: HID: wacom: Ignore the confidence flag when a touch is removed + +From: Jason Gerecke + +commit df03e9bd6d4806619b4cdc91a3d7695818a8e2b7 upstream. + +AES hardware may internally re-classify a contact that it thought was +intentional as a palm. Intentional contacts are reported as "down" with +the confidence bit set. When this re-classification occurs, however, the +state transitions to "up" with the confidence bit cleared. This kind of +transition appears to be legal according to Microsoft docs, but we do +not handle it correctly. Because the confidence bit is clear, we don't +call `wacom_wac_finger_slot` and update userspace. This causes hung +touches that confuse userspace and interfere with pen arbitration. + +This commit adds a special case to ignore the confidence flag if a contact +is reported as removed. This ensures we do not leave a hung touch if one +of these re-classification events occured. Ideally we'd have some way to +also let userspace know that the touch has been re-classified as a palm +and needs to be canceled, but that's not possible right now :) + +Link: https://github.com/linuxwacom/input-wacom/issues/288 +Fixes: 7fb0413baa7f (HID: wacom: Use "Confidence" flag to prevent reporting invalid contacts) +CC: stable@vger.kernel.org +Signed-off-by: Jason Gerecke +Reviewed-by: Ping Cheng +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/wacom_wac.c | 29 ++++++++++++++++++++++++++--- + 1 file changed, 26 insertions(+), 3 deletions(-) + +--- a/drivers/hid/wacom_wac.c ++++ b/drivers/hid/wacom_wac.c +@@ -2566,6 +2566,24 @@ static void wacom_wac_finger_slot(struct + } + } + ++static bool wacom_wac_slot_is_active(struct input_dev *dev, int key) ++{ ++ struct input_mt *mt = dev->mt; ++ struct input_mt_slot *s; ++ ++ if (!mt) ++ return false; ++ ++ for (s = mt->slots; s != mt->slots + mt->num_slots; s++) { ++ if (s->key == key && ++ input_mt_get_value(s, ABS_MT_TRACKING_ID) >= 0) { ++ return true; ++ } ++ } ++ ++ return false; ++} ++ + static void wacom_wac_finger_event(struct hid_device *hdev, + struct hid_field *field, struct hid_usage *usage, __s32 value) + { +@@ -2613,9 +2631,14 @@ static void wacom_wac_finger_event(struc + } + + if (usage->usage_index + 1 == field->report_count) { +- if (equivalent_usage == wacom_wac->hid_data.last_slot_field && +- wacom_wac->hid_data.confidence) +- wacom_wac_finger_slot(wacom_wac, wacom_wac->touch_input); ++ if (equivalent_usage == wacom_wac->hid_data.last_slot_field) { ++ bool touch_removed = wacom_wac_slot_is_active(wacom_wac->touch_input, ++ wacom_wac->hid_data.id) && !wacom_wac->hid_data.tipswitch; ++ ++ if (wacom_wac->hid_data.confidence || touch_removed) { ++ wacom_wac_finger_slot(wacom_wac, wacom_wac->touch_input); ++ } ++ } + } + } + diff --git a/queue-5.10/hid-wacom-reset-expected-and-received-contact-counts-at-the-same-time.patch b/queue-5.10/hid-wacom-reset-expected-and-received-contact-counts-at-the-same-time.patch new file mode 100644 index 00000000000..a9862e3ff00 --- /dev/null +++ b/queue-5.10/hid-wacom-reset-expected-and-received-contact-counts-at-the-same-time.patch @@ -0,0 +1,70 @@ +From 546e41ac994cc185ef3de610ca849a294b5df3ba Mon Sep 17 00:00:00 2001 +From: Jason Gerecke +Date: Tue, 18 Jan 2022 14:37:55 -0800 +Subject: HID: wacom: Reset expected and received contact counts at the same time + +From: Jason Gerecke + +commit 546e41ac994cc185ef3de610ca849a294b5df3ba upstream. + +These two values go hand-in-hand and must be valid for the driver to +behave correctly. We are currently lazy about updating the values and +rely on the "expected" code flow to take care of making sure they're +valid at the point they're needed. The "expected" flow changed somewhat +with commit f8b6a74719b5 ("HID: wacom: generic: Support multiple tools +per report"), however. This led to problems with the DTH-2452 due (in +part) to *all* contacts being fully processed -- even those past the +expected contact count. Specifically, the received count gets reset to +0 once all expected fingers are processed, but not the expected count. +The rest of the contacts in the report are then *also* processed since +now the driver thinks we've only processed 0 of N expected contacts. + +Later commits such as 7fb0413baa7f (HID: wacom: Use "Confidence" flag to +prevent reporting invalid contacts) worked around the DTH-2452 issue by +skipping the invalid contacts at the end of the report, but this is not +a complete fix. The confidence flag cannot be relied on when a contact +is removed (see the following patch), and dealing with that condition +re-introduces the DTH-2452 issue unless we also address this contact +count laziness. By resetting expected and received counts at the same +time we ensure the driver understands that there are 0 more contacts +expected in the report. Similarly, we also make sure to reset the +received count if for some reason we're out of sync in the pre-report +phase. + +Link: https://github.com/linuxwacom/input-wacom/issues/288 +Fixes: f8b6a74719b5 ("HID: wacom: generic: Support multiple tools per report") +CC: stable@vger.kernel.org +Signed-off-by: Jason Gerecke +Reviewed-by: Ping Cheng +Signed-off-by: Jiri Kosina +Signed-off-by: Greg Kroah-Hartman +--- + drivers/hid/wacom_wac.c | 6 +++++- + 1 file changed, 5 insertions(+), 1 deletion(-) + +--- a/drivers/hid/wacom_wac.c ++++ b/drivers/hid/wacom_wac.c +@@ -2664,11 +2664,14 @@ static void wacom_wac_finger_pre_report( + hid_data->cc_index >= 0) { + struct hid_field *field = report->field[hid_data->cc_index]; + int value = field->value[hid_data->cc_value_index]; +- if (value) ++ if (value) { + hid_data->num_expected = value; ++ hid_data->num_received = 0; ++ } + } + else { + hid_data->num_expected = wacom_wac->features.touch_max; ++ hid_data->num_received = 0; + } + } + +@@ -2692,6 +2695,7 @@ static void wacom_wac_finger_report(stru + + input_sync(input); + wacom_wac->hid_data.num_received = 0; ++ wacom_wac->hid_data.num_expected = 0; + + /* keep touch state for pen event */ + wacom_wac->shared->touch_down = wacom_wac_finger_count_touches(wacom_wac); diff --git a/queue-5.10/series b/queue-5.10/series index b75962b1868..06b96d9d3af 100644 --- a/queue-5.10/series +++ b/queue-5.10/series @@ -1 +1,5 @@ kvm-vmx-switch-blocked_vcpu_on_cpu_lock-to-raw-spinlock.patch +hid-uhid-fix-worker-destroying-device-without-any-protection.patch +hid-wacom-reset-expected-and-received-contact-counts-at-the-same-time.patch +hid-wacom-ignore-the-confidence-flag-when-a-touch-is-removed.patch +hid-wacom-avoid-using-stale-array-indicies-to-read-contact-count.patch