* [PATCH 4.14 0/2] 4.14.264-rc1 review
@ 2022-01-27 18:08 Greg Kroah-Hartman
2022-01-27 18:08 ` [PATCH 4.14 1/2] drm/i915: Flush TLBs before releasing backing store Greg Kroah-Hartman
` (4 more replies)
0 siblings, 5 replies; 8+ messages in thread
From: Greg Kroah-Hartman @ 2022-01-27 18:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee
This is the start of the stable review cycle for the 4.14.264 release.
There are 2 patches in this series, all will be posted as a response
to this one. If anyone has any issues with these being applied, please
let me know.
Responses should be made by Sat, 29 Jan 2022 18:02:51 +0000.
Anything received after that time might be too late.
The whole patch series can be found in one patch at:
https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.264-rc1.gz
or in the git tree and branch at:
git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
and the diffstat can be found below.
thanks,
greg k-h
-------------
Pseudo-Shortlog of commits:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Linux 4.14.264-rc1
Ziyang Xuan <william.xuanziyang@huawei.com>
can: bcm: fix UAF of bcm op
Tvrtko Ursulin <tvrtko.ursulin@intel.com>
drm/i915: Flush TLBs before releasing backing store
-------------
Diffstat:
Makefile | 4 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
drivers/gpu/drm/i915/i915_gem.c | 84 +++++++++++++++++++++++++++++++++-
drivers/gpu/drm/i915/i915_gem_object.h | 1 +
drivers/gpu/drm/i915/i915_reg.h | 6 +++
drivers/gpu/drm/i915/i915_vma.c | 4 ++
net/can/bcm.c | 20 ++++----
7 files changed, 108 insertions(+), 13 deletions(-)
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 4.14 1/2] drm/i915: Flush TLBs before releasing backing store
2022-01-27 18:08 [PATCH 4.14 0/2] 4.14.264-rc1 review Greg Kroah-Hartman
@ 2022-01-27 18:08 ` Greg Kroah-Hartman
2022-01-27 18:08 ` [PATCH 4.14 2/2] can: bcm: fix UAF of bcm op Greg Kroah-Hartman
` (3 subsequent siblings)
4 siblings, 0 replies; 8+ messages in thread
From: Greg Kroah-Hartman @ 2022-01-27 18:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, Tvrtko Ursulin,
Sushma Venkatesh Reddy, Daniel Vetter, Dave Airlie,
Jon Bloomfield, Joonas Lahtinen, Jani Nikula, Linus Torvalds
From: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
commit 7938d61591d33394a21bdd7797a245b65428f44c upstream.
We need to flush TLBs before releasing backing store otherwise userspace
is able to encounter stale entries if a) it is not declaring access to
certain buffers and b) it races with the backing store release from a
such undeclared execution already executing on the GPU in parallel.
The approach taken is to mark any buffer objects which were ever bound
to the GPU and to trigger a serialized TLB flush when their backing
store is released.
Alternatively the flushing could be done on VMA unbind, at which point
we would be able to ascertain whether there is potential a parallel GPU
execution (which could race), but essentially it boils down to paying
the cost of TLB flushes potentially needlessly at VMA unbind time (when
the backing store is not known to be going away so not needed for
safety), versus potentially needlessly at backing store relase time
(since we at that point cannot tell whether there is anything executing
on the GPU which uses that object).
Thereforce simplicity of implementation has been chosen for now with
scope to benchmark and refine later as required.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reported-by: Sushma Venkatesh Reddy <sushma.venkatesh.reddy@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Acked-by: Dave Airlie <airlied@redhat.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/gpu/drm/i915/i915_drv.h | 2
drivers/gpu/drm/i915/i915_gem.c | 84 ++++++++++++++++++++++++++++++++-
drivers/gpu/drm/i915/i915_gem_object.h | 1
drivers/gpu/drm/i915/i915_reg.h | 6 ++
drivers/gpu/drm/i915/i915_vma.c | 4 +
5 files changed, 96 insertions(+), 1 deletion(-)
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2166,6 +2166,8 @@ struct drm_i915_private {
struct intel_uncore uncore;
+ struct mutex tlb_invalidate_lock;
+
struct i915_virtual_gpu vgpu;
struct intel_gvt *gvt;
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2220,6 +2220,76 @@ static void __i915_gem_object_reset_page
rcu_read_unlock();
}
+struct reg_and_bit {
+ i915_reg_t reg;
+ u32 bit;
+};
+
+static struct reg_and_bit
+get_reg_and_bit(const struct intel_engine_cs *engine,
+ const i915_reg_t *regs, const unsigned int num)
+{
+ const unsigned int class = engine->class;
+ struct reg_and_bit rb = { .bit = 1 };
+
+ if (WARN_ON_ONCE(class >= num || !regs[class].reg))
+ return rb;
+
+ rb.reg = regs[class];
+ if (class == VIDEO_DECODE_CLASS)
+ rb.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
+
+ return rb;
+}
+
+static void invalidate_tlbs(struct drm_i915_private *dev_priv)
+{
+ static const i915_reg_t gen8_regs[] = {
+ [RENDER_CLASS] = GEN8_RTCR,
+ [VIDEO_DECODE_CLASS] = GEN8_M1TCR, /* , GEN8_M2TCR */
+ [VIDEO_ENHANCEMENT_CLASS] = GEN8_VTCR,
+ [COPY_ENGINE_CLASS] = GEN8_BTCR,
+ };
+ const unsigned int num = ARRAY_SIZE(gen8_regs);
+ const i915_reg_t *regs = gen8_regs;
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ if (INTEL_GEN(dev_priv) < 8)
+ return;
+
+ assert_rpm_wakelock_held(dev_priv);
+
+ mutex_lock(&dev_priv->tlb_invalidate_lock);
+ intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
+
+ for_each_engine(engine, dev_priv, id) {
+ /*
+ * HW architecture suggest typical invalidation time at 40us,
+ * with pessimistic cases up to 100us and a recommendation to
+ * cap at 1ms. We go a bit higher just in case.
+ */
+ const unsigned int timeout_us = 100;
+ const unsigned int timeout_ms = 4;
+ struct reg_and_bit rb;
+
+ rb = get_reg_and_bit(engine, regs, num);
+ if (!i915_mmio_reg_offset(rb.reg))
+ continue;
+
+ I915_WRITE_FW(rb.reg, rb.bit);
+ if (__intel_wait_for_register_fw(dev_priv,
+ rb.reg, rb.bit, 0,
+ timeout_us, timeout_ms,
+ NULL))
+ DRM_ERROR_RATELIMITED("%s TLB invalidation did not complete in %ums!\n",
+ engine->name, timeout_ms);
+ }
+
+ intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
+ mutex_unlock(&dev_priv->tlb_invalidate_lock);
+}
+
void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj,
enum i915_mm_subclass subclass)
{
@@ -2257,8 +2327,18 @@ void __i915_gem_object_put_pages(struct
__i915_gem_object_reset_page_iter(obj);
- if (!IS_ERR(pages))
+ if (!IS_ERR(pages)) {
+ if (test_and_clear_bit(I915_BO_WAS_BOUND_BIT, &obj->flags)) {
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
+ if (intel_runtime_pm_get_if_in_use(i915)) {
+ invalidate_tlbs(i915);
+ intel_runtime_pm_put(i915);
+ }
+ }
+
obj->ops->put_pages(obj, pages);
+ }
unlock:
mutex_unlock(&obj->mm.lock);
@@ -4972,6 +5052,8 @@ i915_gem_load_init(struct drm_i915_priva
spin_lock_init(&dev_priv->fb_tracking.lock);
+ mutex_init(&dev_priv->tlb_invalidate_lock);
+
return 0;
err_priorities:
--- a/drivers/gpu/drm/i915/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/i915_gem_object.h
@@ -135,6 +135,7 @@ struct drm_i915_gem_object {
* activity?
*/
#define I915_BO_ACTIVE_REF 0
+#define I915_BO_WAS_BOUND_BIT 1
/*
* Is the object to be mapped as read-only to the GPU
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2380,6 +2380,12 @@ enum i915_power_well_id {
#define GAMT_CHKN_BIT_REG _MMIO(0x4ab8)
#define GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING (1<<28)
+#define GEN8_RTCR _MMIO(0x4260)
+#define GEN8_M1TCR _MMIO(0x4264)
+#define GEN8_M2TCR _MMIO(0x4268)
+#define GEN8_BTCR _MMIO(0x426c)
+#define GEN8_VTCR _MMIO(0x4270)
+
#if 0
#define PRB0_TAIL _MMIO(0x2030)
#define PRB0_HEAD _MMIO(0x2034)
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -272,6 +272,10 @@ int i915_vma_bind(struct i915_vma *vma,
return ret;
vma->flags |= bind_flags;
+
+ if (vma->obj)
+ set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags);
+
return 0;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH 4.14 2/2] can: bcm: fix UAF of bcm op
2022-01-27 18:08 [PATCH 4.14 0/2] 4.14.264-rc1 review Greg Kroah-Hartman
2022-01-27 18:08 ` [PATCH 4.14 1/2] drm/i915: Flush TLBs before releasing backing store Greg Kroah-Hartman
@ 2022-01-27 18:08 ` Greg Kroah-Hartman
2022-02-03 20:45 ` Pavel Machek
2022-01-28 11:18 ` [PATCH 4.14 0/2] 4.14.264-rc1 review Jon Hunter
` (2 subsequent siblings)
4 siblings, 1 reply; 8+ messages in thread
From: Greg Kroah-Hartman @ 2022-01-27 18:08 UTC (permalink / raw)
To: linux-kernel
Cc: Greg Kroah-Hartman, stable, syzbot+5ca851459ed04c778d1d,
Ziyang Xuan, Oliver Hartkopp
From: Ziyang Xuan <william.xuanziyang@huawei.com>
Stopping tasklet and hrtimer rely on the active state of tasklet and
hrtimer sequentially in bcm_remove_op(), the op object will be freed
if they are all unactive. Assume the hrtimer timeout is short, the
hrtimer cb has been excuted after tasklet conditional judgment which
must be false after last round tasklet_kill() and before condition
hrtimer_active(), it is false when execute to hrtimer_active(). Bug
is triggerd, because the stopping action is end and the op object
will be freed, but the tasklet is scheduled. The resources of the op
object will occur UAF bug.
Move hrtimer_cancel() behind tasklet_kill() and switch 'while () {...}'
to 'do {...} while ()' to fix the op UAF problem.
Fixes: a06393ed0316 ("can: bcm: fix hrtimer/tasklet termination in bcm op removal")
Reported-by: syzbot+5ca851459ed04c778d1d@syzkaller.appspotmail.com
Cc: stable@vger.kernel.org
Signed-off-by: Ziyang Xuan <william.xuanziyang@huawei.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
net/can/bcm.c | 20 ++++++++++----------
1 file changed, 10 insertions(+), 10 deletions(-)
--- a/net/can/bcm.c
+++ b/net/can/bcm.c
@@ -762,21 +762,21 @@ static struct bcm_op *bcm_find_op(struct
static void bcm_remove_op(struct bcm_op *op)
{
if (op->tsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->tsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->tsklet.state) ||
- hrtimer_active(&op->timer)) {
- hrtimer_cancel(&op->timer);
+ do {
tasklet_kill(&op->tsklet);
- }
+ hrtimer_cancel(&op->timer);
+ } while (test_bit(TASKLET_STATE_SCHED, &op->tsklet.state) ||
+ test_bit(TASKLET_STATE_RUN, &op->tsklet.state) ||
+ hrtimer_active(&op->timer));
}
if (op->thrtsklet.func) {
- while (test_bit(TASKLET_STATE_SCHED, &op->thrtsklet.state) ||
- test_bit(TASKLET_STATE_RUN, &op->thrtsklet.state) ||
- hrtimer_active(&op->thrtimer)) {
- hrtimer_cancel(&op->thrtimer);
+ do {
tasklet_kill(&op->thrtsklet);
- }
+ hrtimer_cancel(&op->thrtimer);
+ } while (test_bit(TASKLET_STATE_SCHED, &op->thrtsklet.state) ||
+ test_bit(TASKLET_STATE_RUN, &op->thrtsklet.state) ||
+ hrtimer_active(&op->thrtimer));
}
if ((op->frames) && (op->frames != &op->sframe))
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 4.14 0/2] 4.14.264-rc1 review
2022-01-27 18:08 [PATCH 4.14 0/2] 4.14.264-rc1 review Greg Kroah-Hartman
2022-01-27 18:08 ` [PATCH 4.14 1/2] drm/i915: Flush TLBs before releasing backing store Greg Kroah-Hartman
2022-01-27 18:08 ` [PATCH 4.14 2/2] can: bcm: fix UAF of bcm op Greg Kroah-Hartman
@ 2022-01-28 11:18 ` Jon Hunter
2022-01-29 1:13 ` Guenter Roeck
2022-01-29 9:24 ` Naresh Kamboju
4 siblings, 0 replies; 8+ messages in thread
From: Jon Hunter @ 2022-01-28 11:18 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Greg Kroah-Hartman, stable, torvalds, akpm, linux, shuah,
patches, lkft-triage, pavel, jonathanh, f.fainelli,
sudipm.mukherjee, linux-tegra
On Thu, 27 Jan 2022 19:08:55 +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.264 release.
> There are 2 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Jan 2022 18:02:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.264-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
All tests passing for Tegra ...
Test results for stable-v4.14:
8 builds: 8 pass, 0 fail
16 boots: 16 pass, 0 fail
32 tests: 32 pass, 0 fail
Linux version: 4.14.264-rc1-ga816c082cb80
Boards tested: tegra124-jetson-tk1, tegra20-ventana,
tegra210-p2371-2180, tegra30-cardhu-a04
Tested-by: Jon Hunter <jonathanh@nvidia.com>
Jon
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 4.14 0/2] 4.14.264-rc1 review
2022-01-27 18:08 [PATCH 4.14 0/2] 4.14.264-rc1 review Greg Kroah-Hartman
` (2 preceding siblings ...)
2022-01-28 11:18 ` [PATCH 4.14 0/2] 4.14.264-rc1 review Jon Hunter
@ 2022-01-29 1:13 ` Guenter Roeck
2022-01-29 9:24 ` Naresh Kamboju
4 siblings, 0 replies; 8+ messages in thread
From: Guenter Roeck @ 2022-01-29 1:13 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee
On Thu, Jan 27, 2022 at 07:08:55PM +0100, Greg Kroah-Hartman wrote:
> This is the start of the stable review cycle for the 4.14.264 release.
> There are 2 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Jan 2022 18:02:51 +0000.
> Anything received after that time might be too late.
>
Build results:
total: 168 pass: 168 fail: 0
Qemu test results:
total: 424 pass: 424 fail: 0
Tested-by: Guenter Roeck <linux@roeck-us.net>
Guenter
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 4.14 0/2] 4.14.264-rc1 review
2022-01-27 18:08 [PATCH 4.14 0/2] 4.14.264-rc1 review Greg Kroah-Hartman
` (3 preceding siblings ...)
2022-01-29 1:13 ` Guenter Roeck
@ 2022-01-29 9:24 ` Naresh Kamboju
4 siblings, 0 replies; 8+ messages in thread
From: Naresh Kamboju @ 2022-01-29 9:24 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, torvalds, akpm, linux, shuah, patches,
lkft-triage, pavel, jonathanh, f.fainelli, sudipm.mukherjee
On Thu, 27 Jan 2022 at 23:39, Greg Kroah-Hartman
<gregkh@linuxfoundation.org> wrote:
>
> This is the start of the stable review cycle for the 4.14.264 release.
> There are 2 patches in this series, all will be posted as a response
> to this one. If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Sat, 29 Jan 2022 18:02:51 +0000.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.264-rc1.gz
> or in the git tree and branch at:
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.14.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h
Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing <lkft@linaro.org>
## Build
* kernel: 4.14.264-rc1
* git: https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc
* git branch: linux-4.14.y
* git commit: a816c082cb802807f6548940bb78b806ad74ca90
* git describe: v4.14.263-3-ga816c082cb80
* test details:
https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.14.y/build/v4.14.263-3-ga816c082cb80
## Test Regressions (compared to v4.14.262-185-g1cb564222633)
No test regressions found.
## Metric Regressions (compared to v4.14.262-185-g1cb564222633)
No metric regressions found.
## Test Fixes (compared to v4.14.262-185-g1cb564222633)
No test fixes found.
## Metric Fixes (compared to v4.14.262-185-g1cb564222633)
No metric fixes found.
## Test result summary
total: 69622, pass: 55697, fail: 666, skip: 11294, xfail: 1965
## Build Summary
* arm: 250 total, 242 passed, 8 failed
* arm64: 32 total, 32 passed, 0 failed
* dragonboard-410c: 1 total, 1 passed, 0 failed
* hi6220-hikey: 1 total, 1 passed, 0 failed
* i386: 19 total, 19 passed, 0 failed
* juno-r2: 1 total, 1 passed, 0 failed
* mips: 22 total, 22 passed, 0 failed
* powerpc: 52 total, 0 passed, 52 failed
* sparc: 12 total, 12 passed, 0 failed
* x15: 1 total, 1 passed, 0 failed
* x86: 1 total, 1 passed, 0 failed
* x86_64: 31 total, 31 passed, 0 failed
## Test suites summary
* fwts
* igt-gpu-tools
* kselftest-android
* kselftest-arm64
* kselftest-arm64/arm64.btitest.bti_c_func
* kselftest-arm64/arm64.btitest.bti_j_func
* kselftest-arm64/arm64.btitest.bti_jc_func
* kselftest-arm64/arm64.btitest.bti_none_func
* kselftest-arm64/arm64.btitest.nohint_func
* kselftest-arm64/arm64.btitest.paciasp_func
* kselftest-arm64/arm64.nobtitest.bti_c_func
* kselftest-arm64/arm64.nobtitest.bti_j_func
* kselftest-arm64/arm64.nobtitest.bti_jc_func
* kselftest-arm64/arm64.nobtitest.bti_none_func
* kselftest-arm64/arm64.nobtitest.nohint_func
* kselftest-arm64/arm64.nobtitest.paciasp_func
* kselftest-bpf
* kselftest-breakpoints
* kselftest-capabilities
* kselftest-cgroup
* kselftest-clone3
* kselftest-core
* kselftest-cpu-hotplug
* kselftest-cpufreq
* kselftest-drivers
* kselftest-efivarfs
* kselftest-filesystems
* kselftest-firmware
* kselftest-fpu
* kselftest-futex
* kselftest-gpio
* kselftest-intel_pstate
* kselftest-ipc
* kselftest-ir
* kselftest-kcmp
* kselftest-kexec
* kselftest-kvm
* kselftest-lib
* kselftest-livepatch
* kselftest-membarrier
* kselftest-net
* kselftest-netfilter
* kselftest-nsfs
* kselftest-openat2
* kselftest-pid_namespace
* kselftest-pidfd
* kselftest-proc
* kselftest-pstore
* kselftest-ptrace
* kselftest-rseq
* kselftest-rtc
* kselftest-seccomp
* kselftest-sigaltstack
* kselftest-size
* kselftest-splice
* kselftest-static_keys
* kselftest-sync
* kselftest-sysctl
* kselftest-tc-testing
* kselftest-timens
* kselftest-timers
* kselftest-tmpfs
* kselftest-tpm2
* kselftest-user
* kselftest-vm
* kselftest-x86
* kselftest-zram
* kvm-unit-tests
* libhugetlbfs
* linux-log-parser
* ltp-cap_bounds-tests
* ltp-commands-tests
* ltp-containers-tests
* ltp-controllers-tests
* ltp-cpuhotplug-tests
* ltp-crypto-tests
* ltp-cve-tests
* ltp-dio-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-mm-tests
* ltp-nptl-tests
* ltp-open-posix-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-tracing-tests
* network-basic-tests
* packetdrill
* perf
* rcutorture
* ssuite
* v4l2-compliance
--
Linaro LKFT
https://lkft.linaro.org
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 4.14 2/2] can: bcm: fix UAF of bcm op
2022-01-27 18:08 ` [PATCH 4.14 2/2] can: bcm: fix UAF of bcm op Greg Kroah-Hartman
@ 2022-02-03 20:45 ` Pavel Machek
2022-02-04 6:59 ` Greg Kroah-Hartman
0 siblings, 1 reply; 8+ messages in thread
From: Pavel Machek @ 2022-02-03 20:45 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: linux-kernel, stable, syzbot+5ca851459ed04c778d1d, Ziyang Xuan,
Oliver Hartkopp
[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]
Hi!
> From: Ziyang Xuan <william.xuanziyang@huawei.com>
>
> Stopping tasklet and hrtimer rely on the active state of tasklet and
> hrtimer sequentially in bcm_remove_op(), the op object will be freed
> if they are all unactive. Assume the hrtimer timeout is short, the
> hrtimer cb has been excuted after tasklet conditional judgment which
> must be false after last round tasklet_kill() and before condition
> hrtimer_active(), it is false when execute to hrtimer_active(). Bug
> is triggerd, because the stopping action is end and the op object
> will be freed, but the tasklet is scheduled. The resources of the op
> object will occur UAF bug.
>
> Move hrtimer_cancel() behind tasklet_kill() and switch 'while () {...}'
> to 'do {...} while ()' to fix the op UAF problem.
I don't see this commit in mainline or next kernels. What is going on
here? Is it one of those "only needed in -stable" things? Or do we
still need to fix it in the mainline?
Best regards,
Pavel
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH 4.14 2/2] can: bcm: fix UAF of bcm op
2022-02-03 20:45 ` Pavel Machek
@ 2022-02-04 6:59 ` Greg Kroah-Hartman
0 siblings, 0 replies; 8+ messages in thread
From: Greg Kroah-Hartman @ 2022-02-04 6:59 UTC (permalink / raw)
To: Pavel Machek
Cc: linux-kernel, stable, syzbot+5ca851459ed04c778d1d, Ziyang Xuan,
Oliver Hartkopp
On Thu, Feb 03, 2022 at 09:45:18PM +0100, Pavel Machek wrote:
> Hi!
>
>
> > From: Ziyang Xuan <william.xuanziyang@huawei.com>
> >
> > Stopping tasklet and hrtimer rely on the active state of tasklet and
> > hrtimer sequentially in bcm_remove_op(), the op object will be freed
> > if they are all unactive. Assume the hrtimer timeout is short, the
> > hrtimer cb has been excuted after tasklet conditional judgment which
> > must be false after last round tasklet_kill() and before condition
> > hrtimer_active(), it is false when execute to hrtimer_active(). Bug
> > is triggerd, because the stopping action is end and the op object
> > will be freed, but the tasklet is scheduled. The resources of the op
> > object will occur UAF bug.
> >
> > Move hrtimer_cancel() behind tasklet_kill() and switch 'while () {...}'
> > to 'do {...} while ()' to fix the op UAF problem.
>
> I don't see this commit in mainline or next kernels. What is going on
> here? Is it one of those "only needed in -stable" things? Or do we
> still need to fix it in the mainline?
Please see the stable list discussion of this commit for other branches,
it should answer your question.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2022-02-04 6:59 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-27 18:08 [PATCH 4.14 0/2] 4.14.264-rc1 review Greg Kroah-Hartman
2022-01-27 18:08 ` [PATCH 4.14 1/2] drm/i915: Flush TLBs before releasing backing store Greg Kroah-Hartman
2022-01-27 18:08 ` [PATCH 4.14 2/2] can: bcm: fix UAF of bcm op Greg Kroah-Hartman
2022-02-03 20:45 ` Pavel Machek
2022-02-04 6:59 ` Greg Kroah-Hartman
2022-01-28 11:18 ` [PATCH 4.14 0/2] 4.14.264-rc1 review Jon Hunter
2022-01-29 1:13 ` Guenter Roeck
2022-01-29 9:24 ` Naresh Kamboju
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.