October 2018 - Linux-stable-mirror

[4.4.y 4.9.y 0/1] ext4 CVE fixes for 4.9 and 4.4

by Chenbo Feng

This patch is aimed to fixing CVE-2018-10883 and is already in 4.14 stable. The upstream one has minor conflicts when backporting to 4.4 and 4.9 but it is trivial to resolve. I have tested the patch with xfstests on kvm and there is no regression. Theodore Ts'o (1): ext4: avoid running out of journal credits when appending to an inline file fs/ext4/ext4.h | 3 --- fs/ext4/inline.c | 38 +------------------------------------- fs/ext4/xattr.c | 18 ++---------------- 3 files changed, 3 insertions(+), 56 deletions(-) -- 2.19.0.605.g01d371f741-goog

7 years

2
2
0 0

[PATCH 0/2] A couple recent ext4 CVE fixes

by Daniel Rosenberg

A couple ext4-related CVE fixes were released to other kernels in linux-stable, but didn't cleanly apply to 4.9.y. These are adjusted cherry-picks of Ben Hutching's 3.16.y backports. Theodore Ts'o (2): ext4: add corruption check in ext4_xattr_set_entry() ext4: always verify the magic number in xattr blocks fs/ext4/xattr.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) -- 2.19.0.605.g01d371f741-goog

7 years

2
3
0 0

[PATCH 0/2] A couple recent ext4 CVE fixes

by Daniel Rosenberg

A couple ext4-related CVE fixes were released to other kernels in linux-stable, but didn't cleanly apply to 4.4.y. These are adjusted cherry-picks of Ben Hutching's 3.16.y backports. Theodore Ts'o (2): ext4: add corruption check in ext4_xattr_set_entry() ext4: always verify the magic number in xattr blocks fs/ext4/xattr.c | 28 +++++++++++++++++----------- 1 file changed, 17 insertions(+), 11 deletions(-) -- 2.19.0.605.g01d371f741-goog

7 years

2
3
0 0

Re: [PATCH] platform-msi: Free descriptors in platform_msi_domain_free()

by Miquel Raynal

Hi Marc, Marc Zyngier <marc.zyngier(a)arm.com> wrote on Thu, 11 Oct 2018 09:36:04 +0100: > Miquel, > > On Fri, 28 Sep 2018 16:10:29 +0100, > Miquel Raynal <miquel.raynal(a)bootlin.com> wrote: > > > > Hi Marc, > > > > [...] > > > > > At that stage, you're better off just calling > > > > > > list_del(&desc->list); > > > free_msi_entry(desc); > > > > > > I like this approach better as we only traverse the list once. > > > > Right. > > > > > > > > > } > > > > } > > > > > /** > > > > diff --git a/include/linux/msi.h b/include/linux/msi.h > > > > index 5839d8062dfc..be8ec813dbfb 100644 > > > > --- a/include/linux/msi.h > > > > +++ b/include/linux/msi.h > > > > @@ -116,6 +116,8 @@ struct msi_desc { > > > > list_first_entry(dev_to_msi_list((dev)), struct msi_desc, list) > > > > #define for_each_msi_entry(desc, dev) \ > > > > list_for_each_entry((desc), dev_to_msi_list((dev)), list) > > > > +#define for_each_msi_entry_safe(desc, tmp, dev) \ > > > > + list_for_each_entry_safe((desc), (tmp), dev_to_msi_list((dev)), list) > > > > > #ifdef CONFIG_PCI_MSI > > > > #define first_pci_msi_entry(pdev) first_msi_entry(&(pdev)->dev) > > > > > > If you repin this, I'll queue it right away. > > > > Let me test the new version to be sure I'm not breaking anything and > > I'll send a v2. > > What is the status of this? Are you still planning to send a v2? I'd > really like this fix to reach 4.19 before we put the last nail on it. Sorry about that, I was sure I already sent the v2, now it's done. The changes in this v2 are that instead of creating a platform_msi_domain_free_descs() helper that iterates over the list of descriptors, the descriptor itself is removed from the list and destroyed directly in platform_msi_domain_free(). The for_each_msi_entry() loop is also transformed to use the "_safe" alternative. Thanks, Miquèl

7 years

1
0
0 0

[PATCH 3.18.y 00/10] recent ext4 CVE fixes

by Greg Hackmann

A batch of ext4-related CVE fixes were released to other kernels in linux-stable, but don't apply cleanly to 3.18.y. For the most part these are unmodified cherry-picks of Ben Hutchings's 3.16.y backports (exceptions are noted above my Signed-off-by). Theodore Ts'o (10): ext4: only look at the bg_flags field if it is valid ext4: fix check to prevent initializing reserved inodes ext4: always check block group bounds in ext4_init_block_bitmap() ext4: fix false negatives *and* false positives in ext4_check_descriptors() ext4: add corruption check in ext4_xattr_set_entry() ext4: always verify the magic number in xattr blocks ext4: never move the system.data xattr out of the inode body ext4: add more inode number paranoia checks jbd2: don't mark block as modified if the handle is out of credits ext4: avoid running out of journal credits when appending to an inline file fs/ext4/balloc.c | 21 ++++++++++++------- fs/ext4/ext4.h | 8 ------- fs/ext4/ialloc.c | 19 ++++++++++++++--- fs/ext4/inline.c | 38 +-------------------------------- fs/ext4/inode.c | 3 ++- fs/ext4/mballoc.c | 6 ++++-- fs/ext4/super.c | 12 +++++++++-- fs/ext4/xattr.c | 49 ++++++++++++++++++++----------------------- fs/jbd2/transaction.c | 2 +- 9 files changed, 70 insertions(+), 88 deletions(-) -- 2.19.0.605.g01d371f741-goog

7 years

2
11
0 0

[PATCH 1/6] arm64: perf: Reject stand-alone CHAIN events for PMUv3

by Will Deacon

It doesn't make sense for a perf event to be configured as a CHAIN event in isolation, so extend the arm_pmu structure with a ->filter_match() function to allow the backend PMU implementation to reject CHAIN events early. Cc: <stable(a)vger.kernel.org> Signed-off-by: Will Deacon <will.deacon(a)arm.com> --- arch/arm64/kernel/perf_event.c | 7 +++++++ drivers/perf/arm_pmu.c | 8 +++++++- include/linux/perf/arm_pmu.h | 1 + 3 files changed, 15 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kernel/perf_event.c b/arch/arm64/kernel/perf_event.c index 8e38d5267f22..e213f8e867f6 100644 --- a/arch/arm64/kernel/perf_event.c +++ b/arch/arm64/kernel/perf_event.c @@ -966,6 +966,12 @@ static int armv8pmu_set_event_filter(struct hw_perf_event *event, return 0; } +static int armv8pmu_filter_match(struct perf_event *event) +{ + unsigned long evtype = event->hw.config_base & ARMV8_PMU_EVTYPE_EVENT; + return evtype != ARMV8_PMUV3_PERFCTR_CHAIN; +} + static void armv8pmu_reset(void *info) { struct arm_pmu *cpu_pmu = (struct arm_pmu *)info; @@ -1114,6 +1120,7 @@ static int armv8_pmu_init(struct arm_pmu *cpu_pmu) cpu_pmu->stop = armv8pmu_stop, cpu_pmu->reset = armv8pmu_reset, cpu_pmu->set_event_filter = armv8pmu_set_event_filter; + cpu_pmu->filter_match = armv8pmu_filter_match; return 0; } diff --git a/drivers/perf/arm_pmu.c b/drivers/perf/arm_pmu.c index 7f01f6f60b87..d0b7dd8fb184 100644 --- a/drivers/perf/arm_pmu.c +++ b/drivers/perf/arm_pmu.c @@ -485,7 +485,13 @@ static int armpmu_filter_match(struct perf_event *event) { struct arm_pmu *armpmu = to_arm_pmu(event->pmu); unsigned int cpu = smp_processor_id(); - return cpumask_test_cpu(cpu, &armpmu->supported_cpus); + int ret; + + ret = cpumask_test_cpu(cpu, &armpmu->supported_cpus); + if (ret && armpmu->filter_match) + return armpmu->filter_match(event); + + return ret; } static ssize_t armpmu_cpumask_show(struct device *dev, diff --git a/include/linux/perf/arm_pmu.h b/include/linux/perf/arm_pmu.h index 10f92e1d8e7b..bf309ff6f244 100644 --- a/include/linux/perf/arm_pmu.h +++ b/include/linux/perf/arm_pmu.h @@ -99,6 +99,7 @@ struct arm_pmu { void (*stop)(struct arm_pmu *); void (*reset)(void *); int (*map_event)(struct perf_event *event); + int (*filter_match)(struct perf_event *event); int num_events; bool secure_access; /* 32-bit ARM only */ #define ARMV8_PMUV3_MAX_COMMON_EVENTS 0x40 -- 2.1.4

7 years

2
2
0 0

[PATCH] drm/atomic_helper: Allow DPMS On<->Off changes for unregistered connectors

by Lyude Paul

It appears when testing my previous fix for some of the legacy modesetting issues with MST, I misattributed some kernel splats that started appearing on my machine after a rebase as being from upstream. But it appears they actually came from my patch series: [ 2.980512] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] Updating routing for [CONNECTOR:65:eDP-1] [ 2.980516] [drm:drm_atomic_helper_check_modeset [drm_kms_helper]] [CONNECTOR:65:eDP-1] is not registered [ 2.980516] ------------[ cut here ]------------ [ 2.980519] Could not determine valid watermarks for inherited state [ 2.980553] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980556] Modules linked in: i915(O+) i2c_algo_bit drm_kms_helper(O) syscopyarea sysfillrect sysimgblt fb_sys_fops drm(O) intel_rapl x86_pkg_temp_thermal iTCO_wdt wmi_bmof coretemp crc32_pclmul psmouse i2c_i801 mei_me mei i2c_core lpc_ich mfd_core tpm_tis tpm_tis_core wmi tpm thinkpad_acpi pcc_cpufreq video ehci_pci crc32c_intel serio_raw ehci_hcd xhci_pci xhci_hcd [ 2.980577] CPU: 3 PID: 551 Comm: systemd-udevd Tainted: G O 4.19.0-rc7Lyude-Test+ #1 [ 2.980579] Hardware name: LENOVO 20BWS1KY00/20BWS1KY00, BIOS JBET63WW (1.27 ) 11/10/2016 [ 2.980605] RIP: 0010:intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980607] Code: 89 df e8 ec 27 02 00 e9 24 f2 ff ff be 03 00 00 00 48 89 df e8 da 27 02 00 e9 26 f2 ff ff 48 c7 c7 c8 d1 34 a0 e8 23 cf dc e0 <0f> 0b e9 7c fd ff ff f6 c4 04 0f 85 37 f7 ff ff 48 8b 83 60 08 00 [ 2.980611] RSP: 0018:ffffc90000287988 EFLAGS: 00010282 [ 2.980614] RAX: 0000000000000000 RBX: ffff88031b488000 RCX: 0000000000000006 [ 2.980617] RDX: 0000000000000007 RSI: 0000000000000086 RDI: ffff880321ad54d0 [ 2.980620] RBP: ffffc90000287a10 R08: 000000000000040a R09: 0000000000000065 [ 2.980623] R10: ffff88030ebb8f00 R11: ffffffff81416590 R12: ffff88031b488000 [ 2.980626] R13: ffff88031b4883a0 R14: ffffc900002879a8 R15: ffff880319099800 [ 2.980630] FS: 00007f475620d180(0000) GS:ffff880321ac0000(0000) knlGS:0000000000000000 [ 2.980633] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 2.980636] CR2: 00007f9ef28018a0 CR3: 000000031b72c001 CR4: 00000000003606e0 [ 2.980639] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 2.980642] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 2.980645] Call Trace: [ 2.980675] i915_driver_load+0xb0e/0xdc0 [i915] [ 2.980681] ? kernfs_add_one+0xe7/0x130 [ 2.980709] i915_pci_probe+0x46/0x60 [i915] [ 2.980715] pci_device_probe+0xd4/0x150 [ 2.980719] really_probe+0x243/0x3b0 [ 2.980722] driver_probe_device+0xba/0x100 [ 2.980726] __driver_attach+0xe4/0x110 [ 2.980729] ? driver_probe_device+0x100/0x100 [ 2.980733] bus_for_each_dev+0x74/0xb0 [ 2.980736] driver_attach+0x1e/0x20 [ 2.980739] bus_add_driver+0x159/0x230 [ 2.980743] ? 0xffffffffa0393000 [ 2.980746] driver_register+0x70/0xc0 [ 2.980749] ? 0xffffffffa0393000 [ 2.980753] __pci_register_driver+0x57/0x60 [ 2.980780] i915_init+0x55/0x58 [i915] [ 2.980785] do_one_initcall+0x4a/0x1c4 [ 2.980789] ? do_init_module+0x27/0x210 [ 2.980793] ? kmem_cache_alloc_trace+0x131/0x190 [ 2.980797] do_init_module+0x60/0x210 [ 2.980800] load_module+0x2063/0x22e0 [ 2.980804] ? vfs_read+0x116/0x140 [ 2.980807] ? vfs_read+0x116/0x140 [ 2.980811] __do_sys_finit_module+0xbd/0x120 [ 2.980814] ? __do_sys_finit_module+0xbd/0x120 [ 2.980818] __x64_sys_finit_module+0x1a/0x20 [ 2.980821] do_syscall_64+0x5a/0x110 [ 2.980824] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 2.980826] RIP: 0033:0x7f4754e32879 [ 2.980828] Code: 00 c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d f7 45 2c 00 f7 d8 64 89 01 48 [ 2.980831] RSP: 002b:00007fff43fd97d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 2.980834] RAX: ffffffffffffffda RBX: 0000559a44ca64f0 RCX: 00007f4754e32879 [ 2.980836] RDX: 0000000000000000 RSI: 00007f475599f4cd RDI: 0000000000000018 [ 2.980838] RBP: 00007f475599f4cd R08: 0000000000000000 R09: 0000000000000000 [ 2.980839] R10: 0000000000000018 R11: 0000000000000246 R12: 0000000000000000 [ 2.980841] R13: 0000559a44c92fd0 R14: 0000000000020000 R15: 0000000000000000 [ 2.980881] WARNING: CPU: 3 PID: 551 at drivers/gpu/drm/i915/intel_display.c:14983 intel_modeset_init+0x14d7/0x19f0 [i915] [ 2.980884] ---[ end trace 5eb47a76277d4731 ]--- The cause of this appears to be due to the fact that if there's pre-existing display state that was set by the BIOS when i915 loads, it will attempt to perform a modeset before the driver is registered with userspace. Since this happens before the driver's registered with userspace, it's connectors are also unregistered and thus-states which would turn on DPMS on a connector end up getting rejected since the connector isn't registered. These bugs managed to get past Intel's CI partially due to the fact it never ran a full test on my patches for some reason, but also because all of the tests unload the GPU once before running. Since this bug is only really triggered when the drivers tries to perform a modeset before it's been fully registered with userspace when coming from whatever display configuration the firmware left us with, it likely would never have been picked up by CI in the first place. After some discussion with vsyrjala, we decided the best course of action would be to just move the unregistered connector checks out of update_connector_routing() and into drm_atomic_set_crtc_for_connector(). The reason for this being that legacy modesetting isn't going to be expecting failures anywhere (at least this is the case with X), so ideally we want to ensure that any DPMS changes will still work even on unregistered connectors. Instead, we now only reject new modesets which would change the current CRTC assigned to an unregistered connector unless no new CRTC is being assigned to replace the connector's previous one. Signed-off-by: Lyude Paul <lyude(a)redhat.com> Reported-by: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Fixes: 4d80273976bf ("drm/atomic_helper: Disallow new modesets on unregistered connectors") Cc: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: Ville Syrjälä <ville.syrjala(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/drm_atomic_helper.c | 21 +-------------------- drivers/gpu/drm/drm_atomic_uapi.c | 21 +++++++++++++++++++++ 2 files changed, 22 insertions(+), 20 deletions(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index e6a2cf72de5e..6f66777dca4b 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -319,26 +319,6 @@ update_connector_routing(struct drm_atomic_state *state, return 0; } - crtc_state = drm_atomic_get_new_crtc_state(state, - new_connector_state->crtc); - /* - * For compatibility with legacy users, we want to make sure that - * we allow DPMS On->Off modesets on unregistered connectors. Modesets - * which would result in anything else must be considered invalid, to - * avoid turning on new displays on dead connectors. - * - * Since the connector can be unregistered at any point during an - * atomic check or commit, this is racy. But that's OK: all we care - * about is ensuring that userspace can't do anything but shut off the - * display on a connector that was destroyed after its been notified, - * not before. - */ - if (!READ_ONCE(connector->registered) && crtc_state->active) { - DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n", - connector->base.id, connector->name); - return -EINVAL; - } - funcs = connector->helper_private; if (funcs->atomic_best_encoder) @@ -383,6 +363,7 @@ update_connector_routing(struct drm_atomic_state *state, set_best_encoder(state, new_connector_state, new_encoder); + crtc_state = drm_atomic_get_new_crtc_state(state, new_connector_state->crtc); crtc_state->connectors_changed = true; DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on [CRTC:%d:%s]\n", diff --git a/drivers/gpu/drm/drm_atomic_uapi.c b/drivers/gpu/drm/drm_atomic_uapi.c index d5b7f315098c..7acec863b10c 100644 --- a/drivers/gpu/drm/drm_atomic_uapi.c +++ b/drivers/gpu/drm/drm_atomic_uapi.c @@ -299,6 +299,27 @@ drm_atomic_set_crtc_for_connector(struct drm_connector_state *conn_state, struct drm_connector *connector = conn_state->connector; struct drm_crtc_state *crtc_state; + /* + * For compatibility with legacy users, we want to make sure that + * we allow DPMS On<->Off modesets on unregistered connectors, since + * legacy modesetting users will not be expecting these to fail. We do + * not however, want to allow legacy users to assign a connector + * that's been unregistered from sysfs to another CRTC, since doing + * this with a now non-existant connector could potentially leave us + * in an invalid state. + * + * Since the connector can be unregistered at any point during an + * atomic check or commit, this is racy. But that's OK: all we care + * about is ensuring that userspace can't use this connector for new + * configurations after it's been notified that the connector is no + * longer present. + */ + if (!READ_ONCE(connector->registered) && crtc) { + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n", + connector->base.id, connector->name); + return -EINVAL; + } + if (conn_state->crtc == crtc) return 0; -- 2.17.1

7 years

3
2
0 0

[PATCH v7 1/5] drm/atomic_helper: Disallow new modesets on unregistered connectors

by Lyude Paul

With the exception of modesets which would switch the DPMS state of a connector from on to off, we want to make sure that we disallow all modesets which would result in enabling a new monitor or a new mode configuration on a monitor if the connector for the display in question is no longer registered. This allows us to stop userspace from trying to enable new displays on connectors for an MST topology that were just removed from the system, without preventing userspace from disabling DPMS on those connectors. Changes since v5: - Fix typo in comment, nothing else Signed-off-by: Lyude Paul <lyude(a)redhat.com> Reviewed-by: Daniel Vetter <daniel.vetter(a)ffwll.ch> Cc: stable(a)vger.kernel.org --- drivers/gpu/drm/drm_atomic_helper.c | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 6f66777dca4b..e6a2cf72de5e 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -319,6 +319,26 @@ update_connector_routing(struct drm_atomic_state *state, return 0; } + crtc_state = drm_atomic_get_new_crtc_state(state, + new_connector_state->crtc); + /* + * For compatibility with legacy users, we want to make sure that + * we allow DPMS On->Off modesets on unregistered connectors. Modesets + * which would result in anything else must be considered invalid, to + * avoid turning on new displays on dead connectors. + * + * Since the connector can be unregistered at any point during an + * atomic check or commit, this is racy. But that's OK: all we care + * about is ensuring that userspace can't do anything but shut off the + * display on a connector that was destroyed after its been notified, + * not before. + */ + if (!READ_ONCE(connector->registered) && crtc_state->active) { + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] is not registered\n", + connector->base.id, connector->name); + return -EINVAL; + } + funcs = connector->helper_private; if (funcs->atomic_best_encoder) @@ -363,7 +383,6 @@ update_connector_routing(struct drm_atomic_state *state, set_best_encoder(state, new_connector_state, new_encoder); - crtc_state = drm_atomic_get_new_crtc_state(state, new_connector_state->crtc); crtc_state->connectors_changed = true; DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] using [ENCODER:%d:%s] on [CRTC:%d:%s]\n", -- 2.17.1

7 years

3
2
0 0

FAILED: patch "[PATCH] USB: serial: option: improve Quectel EP06 detection" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 36cae568404a298a19a6e8a3f18641075d4cab04 Mon Sep 17 00:00:00 2001 From: Kristian Evensen <kristian.evensen(a)gmail.com> Date: Thu, 13 Sep 2018 11:21:49 +0200 Subject: [PATCH] USB: serial: option: improve Quectel EP06 detection The Quectel EP06 (and EM06/EG06) LTE modem supports updating the USB configuration, without the VID/PID or configuration number changing. When the configuration is updated and interfaces are added/removed, the interface numbers are updated. This causes our current code for matching EP06 not to work as intended, as the assumption about reserved interfaces no longer holds. If for example the diagnostic (first) interface is removed, option will (try to) bind to the QMI interface. This patch improves EP06 detection by replacing the current match with two matches, and those matches check class, subclass and protocol as well as VID and PID. The diag interface exports class, subclass and protocol as 0xff. For the other serial interfaces, class is 0xff and subclass and protocol are both 0x0. The modem can export the following devices and always in this order: diag, nmea, at, ppp. qmi and adb. This means that diag can only ever be interface 0, and interface numbers 1-5 should be marked as reserved. The three other serial devices can have interface numbers 0-3, but I have not marked any interfaces as reserved. The reason is that the serial devices are the only interfaces exported by the device where subclass and protocol is 0x0. QMI exports the same class, subclass and protocol values as the diag interface. However, the two interfaces have different number of endpoints, QMI has three and diag two. I have added a check for number of interfaces if VID/PID matches the EP06, and we ignore the device if number of interfaces equals three (and subclass is set). Signed-off-by: Kristian Evensen <kristian.evensen(a)gmail.com> Acked-by: Dan Williams <dcbw(a)redhat.com> [ johan: drop uneeded RSVD(5) for ADB ] Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 0215b70c4efc..382feafbd127 100644 --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -1081,8 +1081,9 @@ static const struct usb_device_id option_ids[] = { .driver_info = RSVD(4) }, { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96), .driver_info = RSVD(4) }, - { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EP06), - .driver_info = RSVD(4) | RSVD(5) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EP06, 0xff, 0xff, 0xff), + .driver_info = RSVD(1) | RSVD(2) | RSVD(3) | RSVD(4) }, + { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EP06, 0xff, 0, 0) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6003), @@ -1985,6 +1986,7 @@ static int option_probe(struct usb_serial *serial, { struct usb_interface_descriptor *iface_desc = &serial->interface->cur_altsetting->desc; + struct usb_device_descriptor *dev_desc = &serial->dev->descriptor; unsigned long device_flags = id->driver_info; /* Never bind to the CD-Rom emulation interface */ @@ -1999,6 +2001,18 @@ static int option_probe(struct usb_serial *serial, if (device_flags & RSVD(iface_desc->bInterfaceNumber)) return -ENODEV; + /* + * Don't bind to the QMI device of the Quectel EP06/EG06/EM06. Class, + * subclass and protocol is 0xff for both the diagnostic port and the + * QMI interface, but the diagnostic port only has two endpoints (QMI + * has three). + */ + if (dev_desc->idVendor == cpu_to_le16(QUECTEL_VENDOR_ID) && + dev_desc->idProduct == cpu_to_le16(QUECTEL_PRODUCT_EP06) && + iface_desc->bInterfaceSubClass && iface_desc->bNumEndpoints == 3) { + return -ENODEV; + } + /* Store the device flags so we can use them during attach. */ usb_set_serial_data(serial, (void *)device_flags);

7 years

1
0
0 0

FAILED: patch "[PATCH] USB: serial: option: add two-endpoints device-id flag" failed to apply to 4.14-stable tree

by gregkh＠linuxfoundation.org

The patch below does not apply to the 4.14-stable tree. If someone wants it applied there, or to any other stable or longterm tree, then please email the backport, including the original git commit id to <stable(a)vger.kernel.org>. thanks, greg k-h ------------------ original commit in Linus's tree ------------------ >From 35aecc02b5b621782111f64cbb032c7f6a90bb32 Mon Sep 17 00:00:00 2001 From: Johan Hovold <johan(a)kernel.org> Date: Thu, 13 Sep 2018 11:21:50 +0200 Subject: [PATCH] USB: serial: option: add two-endpoints device-id flag Allow matching on interfaces having two endpoints by adding a new device-id flag. This allows for the handling of devices whose interface numbers can change (e.g. Quectel EP06) to be contained in the device-id table. Tested-by: Kristian Evensen <kristian.evensen(a)gmail.com> Cc: stable <stable(a)vger.kernel.org> Signed-off-by: Johan Hovold <johan(a)kernel.org> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c index 382feafbd127..e72ad9f81c73 100644 --- a/drivers/usb/serial/option.c +++ b/drivers/usb/serial/option.c @@ -561,6 +561,9 @@ static void option_instat_callback(struct urb *urb); /* Interface is reserved */ #define RSVD(ifnum) ((BIT(ifnum) & 0xff) << 0) +/* Interface must have two endpoints */ +#define NUMEP2 BIT(16) + static const struct usb_device_id option_ids[] = { { USB_DEVICE(OPTION_VENDOR_ID, OPTION_PRODUCT_COLT) }, @@ -1082,7 +1085,7 @@ static const struct usb_device_id option_ids[] = { { USB_DEVICE(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_BG96), .driver_info = RSVD(4) }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EP06, 0xff, 0xff, 0xff), - .driver_info = RSVD(1) | RSVD(2) | RSVD(3) | RSVD(4) }, + .driver_info = RSVD(1) | RSVD(2) | RSVD(3) | RSVD(4) | NUMEP2 }, { USB_DEVICE_AND_INTERFACE_INFO(QUECTEL_VENDOR_ID, QUECTEL_PRODUCT_EP06, 0xff, 0, 0) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_6001) }, { USB_DEVICE(CMOTECH_VENDOR_ID, CMOTECH_PRODUCT_CMU_300) }, @@ -1986,7 +1989,6 @@ static int option_probe(struct usb_serial *serial, { struct usb_interface_descriptor *iface_desc = &serial->interface->cur_altsetting->desc; - struct usb_device_descriptor *dev_desc = &serial->dev->descriptor; unsigned long device_flags = id->driver_info; /* Never bind to the CD-Rom emulation interface */ @@ -2002,16 +2004,11 @@ static int option_probe(struct usb_serial *serial, return -ENODEV; /* - * Don't bind to the QMI device of the Quectel EP06/EG06/EM06. Class, - * subclass and protocol is 0xff for both the diagnostic port and the - * QMI interface, but the diagnostic port only has two endpoints (QMI - * has three). + * Allow matching on bNumEndpoints for devices whose interface numbers + * can change (e.g. Quectel EP06). */ - if (dev_desc->idVendor == cpu_to_le16(QUECTEL_VENDOR_ID) && - dev_desc->idProduct == cpu_to_le16(QUECTEL_PRODUCT_EP06) && - iface_desc->bInterfaceSubClass && iface_desc->bNumEndpoints == 3) { + if (device_flags & NUMEP2 && iface_desc->bNumEndpoints != 2) return -ENODEV; - } /* Store the device flags so we can use them during attach. */ usb_set_serial_data(serial, (void *)device_flags);

7 years

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2018