rpms
/
kernel
2
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Merge branch 'f23' of ssh://pkgs.fedoraproject.org/kernel into f23-pf 

- 4.3.3-303.hu.2.pf4
- While Fedora step to 4.3.4, pf is still 4.3.4. But merging Fedora patch changes.
This commit is contained in:
Pavel Alexeev 2016-01-26 11:38:34 +03:00
parent 8d785071f7 059e5105d9
commit 82785a31c4
7 changed files with 107 additions and 2327 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

94
HID-multitouch-fix-input-mode-switching-on-some-Elan.patch Normal file
View File

@ -0,0 +1,94 @@
From cd1e1e286bb3c4fa8714c1e571ae082e510efd5d Mon Sep 17 00:00:00 2001
From: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Date: Tue, 1 Dec 2015 12:41:38 +0100
Subject: [PATCH] HID: multitouch: fix input mode switching on some Elan panels
as reported by https://bugzilla.kernel.org/show_bug.cgi?id=108481
This bug reports mentions 6d4f5440 ("HID: multitouch: Fetch feature
reports on demand for Win8 devices") as the origin of the problem but this
commit actually masked 2 firmware bugs that are annihilating each other:
The report descriptor declares two features in reports 3 and 5:
0x05, 0x0d, // Usage Page (Digitizers) 318
0x09, 0x0e, // Usage (Device Configuration) 320
0xa1, 0x01, // Collection (Application) 322
0x85, 0x03, // Report ID (3) 324
0x09, 0x22, // Usage (Finger) 326
0xa1, 0x00, // Collection (Physical) 328
0x09, 0x52, // Usage (Inputmode) 330
0x15, 0x00, // Logical Minimum (0) 332
0x25, 0x0a, // Logical Maximum (10) 334
0x75, 0x08, // Report Size (8) 336
0x95, 0x02, // Report Count (2) 338
0xb1, 0x02, // Feature (Data,Var,Abs) 340
0xc0, // End Collection 342
0x09, 0x22, // Usage (Finger) 343
0xa1, 0x00, // Collection (Physical) 345
0x85, 0x05, // Report ID (5) 347
0x09, 0x57, // Usage (Surface Switch) 349
0x09, 0x58, // Usage (Button Switch) 351
0x15, 0x00, // Logical Minimum (0) 353
0x75, 0x01, // Report Size (1) 355
0x95, 0x02, // Report Count (2) 357
0x25, 0x03, // Logical Maximum (3) 359
0xb1, 0x02, // Feature (Data,Var,Abs) 361
0x95, 0x0e, // Report Count (14) 363
0xb1, 0x03, // Feature (Cnst,Var,Abs) 365
0xc0, // End Collection 367
The report ID 3 presents 2 input mode features, while only the first one
is handled by the device. Given that we did not checked if one was
previously assigned, we were dealing with the ignored featured and we
should never have been able to switch this panel into the multitouch mode.
However, the firmware presents an other bugs which allowed 6d4f5440
to counteract the faulty report descriptor. When we request the values
of the feature 5, the firmware answers "03 03 00". The fields are correct
but the report id is wrong. Before 6d4f5440, we retrieved all the features
and injected them in the system. So when we called report 5, we injected
in the system the report 3 with the values "03 00".
Setting the second input mode to 03 in this report changed it to "03 03"
and the touchpad switched to the mt mode. We could have set anything
in the second field because the actual value (the first 03 in this report)
was given by the query of report ID 5.
To sum up: 2 bugs in the firmware were hiding that we were accessing the
wrong feature.
Signed-off-by: Benjamin Tissoires <benjamin.tissoires@redhat.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
---
drivers/hid/hid-multitouch.c | 15 +++++++++++++--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index ba94044cb859..d866720412cd 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -357,8 +357,19 @@ static void mt_feature_mapping(struct hid_device *hdev,
break;
}
- td->inputmode = field->report->id;
- td->inputmode_index = usage->usage_index;
+ if (td->inputmode < 0) {
+ td->inputmode = field->report->id;
+ td->inputmode_index = usage->usage_index;
+ } else {
+ /*
+ * Some elan panels wrongly declare 2 input mode
+ * features, and silently ignore when we set the
+ * value in the second field. Skip the second feature
+ * and hope for the best.
+ */
+ dev_info(&hdev->dev,
+ "Ignoring the extra HID_DG_INPUTMODE\n");
+ }
break;
case HID_DG_CONTACTMAX:
--
2.5.0

78
KEYS-Fix-keyring-ref-leak-in-join_session_keyring.patch
View File

@ -1,78 +0,0 @@
From 05fd13592b60c3e9873f56705f80ff934e98b046 Mon Sep 17 00:00:00 2001
From: David Howells <dhowells@redhat.com>
Date: Mon, 18 Jan 2016 10:53:31 +0000
Subject: [PATCH] KEYS: Fix keyring ref leak in join_session_keyring()
This fixes CVE-2016-0728.
If a thread is asked to join as a session keyring the keyring that's already
set as its session, we leak a keyring reference.
This can be tested with the following program:
#include <stddef.h>
#include <stdio.h>
#include <sys/types.h>
#include <keyutils.h>
int main(int argc, const char *argv[])
{
int i = 0;
key_serial_t serial;
serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
"leaked-keyring");
if (serial < 0) {
perror("keyctl");
return -1;
}
if (keyctl(KEYCTL_SETPERM, serial,
KEY_POS_ALL | KEY_USR_ALL) < 0) {
perror("keyctl");
return -1;
}
for (i = 0; i < 100; i++) {
serial = keyctl(KEYCTL_JOIN_SESSION_KEYRING,
"leaked-keyring");
if (serial < 0) {
perror("keyctl");
return -1;
}
}
return 0;
}
If, after the program has run, there something like the following line in
/proc/keys:
3f3d898f I--Q--- 100 perm 3f3f0000 0 0 keyring leaked-keyring: empty
with a usage count of 100 * the number of times the program has been run,
then the kernel is malfunctioning. If leaked-keyring has zero usages or
has been garbage collected, then the problem is fixed.
Reported-by: Yevgeny Pats <yevgeny@perception-point.io>
Signed-off-by: David Howells <dhowells@redhat.com>
RH-bugzilla: 1298036
---
security/keys/process_keys.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/security/keys/process_keys.c b/security/keys/process_keys.c
index 43b4cddbf2b3..7877e5cd4e23 100644
--- a/security/keys/process_keys.c
+++ b/security/keys/process_keys.c
@@ -794,6 +794,7 @@ long join_session_keyring(const char *name)
ret = PTR_ERR(keyring);
goto error2;
} else if (keyring == new->session_keyring) {
+ key_put(keyring);
ret = 0;
goto error2;
}
--
2.5.0

108
KEYS-Fix-race-between-read-and-revoke.patch
View File

@ -1,108 +0,0 @@
From f144220f72062ed5359e0211f130670c915a12dd Mon Sep 17 00:00:00 2001
From: David Howells <dhowells@redhat.com>
Date: Mon, 14 Dec 2015 10:36:31 -0500
Subject: [PATCH] KEYS: Fix race between read and revoke
There's a race between keyctl_read() and keyctl_revoke(). If the revoke
happens between keyctl_read() checking the validity of a key and the key's
semaphore being taken, then the key type read method will see a revoked key.
This causes a problem for the user-defined key type because it assumes in
its read method that there will always be a payload in a non-revoked key
and doesn't check for a NULL pointer.
Fix this by making keyctl_read() check the validity of a key after taking
semaphore instead of before.
This was discovered by a multithreaded test program generated by syzkaller
(http://github.com/google/syzkaller). Here's a cleaned up version:
#include <sys/types.h>
#include <keyutils.h>
#include <pthread.h>
void *thr0(void *arg)
{
key_serial_t key = (unsigned long)arg;
keyctl_revoke(key);
return 0;
}
void *thr1(void *arg)
{
key_serial_t key = (unsigned long)arg;
char buffer[16];
keyctl_read(key, buffer, 16);
return 0;
}
int main()
{
key_serial_t key = add_key("user", "%", "foo", 3, KEY_SPEC_USER_KEYRING);
pthread_t th[5];
pthread_create(&th[0], 0, thr0, (void *)(unsigned long)key);
pthread_create(&th[1], 0, thr1, (void *)(unsigned long)key);
pthread_create(&th[2], 0, thr0, (void *)(unsigned long)key);
pthread_create(&th[3], 0, thr1, (void *)(unsigned long)key);
pthread_join(th[0], 0);
pthread_join(th[1], 0);
pthread_join(th[2], 0);
pthread_join(th[3], 0);
return 0;
}
Build as:
cc -o keyctl-race keyctl-race.c -lkeyutils -lpthread
Run as:
while keyctl-race; do :; done
as it may need several iterations to crash the kernel. The crash can be
summarised as:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
IP: [<ffffffff81279b08>] user_read+0x56/0xa3
...
Call Trace:
[<ffffffff81276aa9>] keyctl_read_key+0xb6/0xd7
[<ffffffff81277815>] SyS_keyctl+0x83/0xe0
[<ffffffff815dbb97>] entry_SYSCALL_64_fastpath+0x12/0x6f
Reported-by: Dmitry Vyukov <dvyukov@google.com>
Signed-off-by: David Howells <dhowells@redhat.com>
---
security/keys/keyctl.c | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/security/keys/keyctl.c b/security/keys/keyctl.c
index fb111eafcb89..1c3872aeed14 100644
--- a/security/keys/keyctl.c
+++ b/security/keys/keyctl.c
@@ -751,16 +751,16 @@ long keyctl_read_key(key_serial_t keyid, char __user *buffer, size_t buflen)
/* the key is probably readable - now try to read it */
can_read_key:
- ret = key_validate(key);
- if (ret == 0) {
- ret = -EOPNOTSUPP;
- if (key->type->read) {
- /* read the data with the semaphore held (since we
- * might sleep) */
- down_read(&key->sem);
+ ret = -EOPNOTSUPP;
+ if (key->type->read) {
+ /* Read the data with the semaphore held (since we might sleep)
+ * to protect against the key being updated or revoked.
+ */
+ down_read(&key->sem);
+ ret = key_validate(key);
+ if (ret == 0)
ret = key->type->read(key, buffer, buflen);
- up_read(&key->sem);
- }
+ up_read(&key->sem);
}
error2:
--
2.5.0

24
kernel.spec
View File

@ -22,7 +22,7 @@ Summary: The Linux kernel
%global zipsed -e 's/\.ko$/\.ko.xz/'
%endif
%define buildid .hu.1.pf4
%define buildid .hu.2.pf4
# baserelease defines which build revision of this kernel version we're
# building. We used to call this fedora_build, but the magical name
@ -40,7 +40,7 @@ Summary: The Linux kernel
# For non-released -rc kernels, this will be appended after the rcX and
# gitX tags, so a 3 here would become part of release "0.rcX.gitX.3"
#
%global baserelease 303
%global baserelease 300
%global fedora_build %{baserelease}
# base_sublevel is the kernel version we're starting with and patching
@ -637,11 +637,6 @@ Patch572: alua_fix.patch
#CVE-XXXX-XXXX rhbz 1291329 1291332
Patch574: ovl-fix-permission-checking-for-setattr.patch
#CVE-2015-7550 rhbz 1291197 1291198
Patch575: KEYS-Fix-race-between-read-and-revoke.patch
Patch601: vrf-fix-memory-leak-on-registration.patch
#CVE-2015-8709 rhbz 1295287 1295288
Patch603: ptrace-being-capable-wrt-a-process-requires-mapped-u.patch
@ -652,6 +647,7 @@ Patch605: KVM-x86-Reload-pit-counters-for-all-channels-when-re.patch
#rhbz 1296677
Patch606: HID-multitouch-Fetch-feature-reports-on-demand-for-W.patch
Patch641: HID-multitouch-fix-input-mode-switching-on-some-Elan.patch
#rhbz 1281368
Patch607: drm-nouveau-Fix-pre-nv50-pageflip-events-v4.patch
@ -709,11 +705,6 @@ Patch630: SCSI-fix-bug-in-scsi_dev_info_list-matching.patch
Patch631: btrfs-handle-invalid-num_stripes-in-sys_array.patch
Patch632: Btrfs-fix-fitrim-discarding-device-area-reserved-for.patch
Patch633: net_43.mbox
#CVE-2016-0728 rhbz 1296623 1297475
Patch634: KEYS-Fix-keyring-ref-leak-in-join_session_keyring.patch
#CVE-2013-4312 rhbz 1297813 1300216
Patch636: unix-properly-account-for-FDs-passed-over-unix-socke.patch
@ -2177,6 +2168,15 @@ fi
# and build.
#
%changelog
* Tue Jan 26 2016 Pavel Alexeev <Pahan@Hubbitus.info> - 4.3.3-303.hu.2.pf4
- While Fedora step to 4.3.4, pf is still 4.3.4. But merging Fedora patch changes.
* Mon Jan 25 2016 Josh Boyer <jwboyer@fedoraproject.org> - 4.3.4-300
- Add patch to fix some Elan touchpads (rhbz 1296677)
* Sat Jan 23 2016 Josh Boyer <jwboyer@fedoraproject.org>
- Linux v4.3.4
* Sat Jan 23 2016 Pavel Alexeev <Pahan@Hubbitus.info> - 4.3.3-303.hu.1.pf4
- Merge Fedora 15 patches.
- 4.3.3-303.hu.1.pf4

2086
net_43.mbox
View File

File diff suppressed because it is too large Load Diff

2
sources
View File

@ -1,3 +1,3 @@
58b35794eee3b6d52ce7be39357801e7 linux-4.3.tar.xz
7c516c9528b9f9aac0136944b0200b7e perf-man-4.3.tar.gz
d3235b3640ae6ac1ab579171943fda4b patch-4.3.3.xz
5bbeeb57b8cff23e5c27430e60810d1b patch-4.3.4.xz

42
vrf-fix-memory-leak-on-registration.patch
View File

@ -1,42 +0,0 @@
From 5780068e17af44a98d432d31448bb18a99ce64dc Mon Sep 17 00:00:00 2001
From: Ben Hutchings <ben@decadent.org.uk>
Date: Tue, 15 Dec 2015 15:12:43 +0000
Subject: [PATCH] vrf: Fix memory leak on registration failure in vrf_newlink()
The backported version of commit 7f109f7cc371 ("vrf: fix double free
and memory corruption on register_netdevice failure") incorrectly
removed a kfree() from the failure path as well as the free_netdev().
Add that back.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
---
drivers/net/vrf.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/net/vrf.c b/drivers/net/vrf.c
index c9e309c..6c25fd0 100644
--- a/drivers/net/vrf.c
+++ b/drivers/net/vrf.c
@@ -581,6 +581,7 @@ static int vrf_newlink(struct net *src_net, struct net_device *dev,
{
struct net_vrf *vrf = netdev_priv(dev);
struct net_vrf_dev *vrf_ptr;
+ int err;
if (!data || !data[IFLA_VRF_TABLE])
return -EINVAL;
@@ -598,7 +599,10 @@ static int vrf_newlink(struct net *src_net, struct net_device *dev,
rcu_assign_pointer(dev->vrf_ptr, vrf_ptr);
- return register_netdev(dev);
+ err = register_netdev(dev);
+ if (err)
+ kfree(vrf_ptr);
+ return err;
}
static size_t vrf_nl_getsize(const struct net_device *dev)
--
2.5.0