PD#SWPL-3088
Problem:
g12b big-little cluster is different from other SoC with pmu
interrupts and registers.
software modifications must adapt to the difference.
Solution:
modify
Verify:
u200 w400
Change-Id: If9217c1025dff5c17d51790f8c216e31b7d6532b
Signed-off-by: Hanjie Lin <hanjie.lin@amlogic.com>
Signed-off-by: Luan Yuan <luan.yuan@amlogic.com>
PD#SWPL-915
Problem:
DOLBY only sets the enhancement for the first frame ->
Vd sets cur_dispubf2 according to enhance ->
codec_mm keeps the last frame according to cur_dispbuf2,
so it fails -> AFBC2 access to the released content causes the trigger.
Solution:
close afbc2
Verify:
r321
Change-Id: I03c431a6ea11b8aabf97b1f0b21f717024be2f62
Signed-off-by: Yi Zhou <yi.zhou@amlogic.com>
PD#SWPL-4320
Problem:
The meson8b and arm64_a32 are both selected in Kconfig,
which is quite misleading
Solution:
Disable meson8b when arm64_a32 is selected
Verify:
Locally passed for Ampere
Change-Id: I93f55239ea90bf8cf6b96e108b6fd4a239de32b4
Signed-off-by: Jiamin Ma <jiamin.ma@amlogic.com>
PD#SWPL-3951
Problem:
buffer malloc for dtb may failed
Solution:
malloc may sleep to wait for enough memory
Verify:
pass on p212
Change-Id: Ib4c266c17140d2a6abf2aea6c02b2ff591f0fe08
Signed-off-by: Ruixuan Li <ruixuan.li@amlogic.com>
PD#SWPL-4876
Problem:
32bit will operate led-trigger cpu0 in cpu idle enter/exit causing
system led flashing.
Solution:
give up using led-trigger cpu0.
Verify:
g12a_u211 g12a_u212
Change-Id: I106a4fe0e35923919f5bbc34113fa73a4ca28577
Signed-off-by: Bichao Zheng <bichao.zheng@amlogic.com>
Signed-off-by: Luan Yuan <luan.yuan@amlogic.com>
Conflicts:
arch/arm64/boot/dts/amlogic/g12b_a311x_w411_buildroot.dts
PD#SWPL-3359
Problem:
the bt656 clocks were missing
Solution:
1.add bt656 clocks
2.fix several errors for media clocks
Verify:
test passed on u200
Change-Id: Iff69e790c78335930d6b2ea54f7544aca464e1fb
Signed-off-by: Jian Hu <jian.hu@amlogic.com>
PD#SWPL-85
Problem:
print into level control
Solution:
print into level control
Verify:
U212
Change-Id: Ib0fdc02f26e75c20e48171bca5ebef072947d78c
Signed-off-by: jintao xu <jintao.xu@amlogic.com>
PD#SWPL-85
Problem:
Upper layer need control osd and video layer zorder
Solution:
1.Add video layer zorder interface by sysfs and ioctl
2.Switch the osd and video layer order in vsync
Verify:
Verify on U212
Change-Id: Ic50e81784b865cc57e4ab9a63d74806f7a8721cf
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
PD#SWPL-85
Problem:
Need support two video layers feature
Solution:
1.Add vd2 mif config
2.Add vd2 pps calculation and config
3.Add vd2 axis/crop/screen mode interface by sysfs and ioctl
4.Add layer query/alloc/free interface
Verify:
Verify on U212
Change-Id: I71fc9ab2ae0230c3e84c4b790e77d2c790951642
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
PD#172587
Problem:
Add sr driver support for tl1
Solution:
add sr driver support for tl1
fix horizontal line when play video on 4K screen
Verify:
TL1 X301
Change-Id: I422f27eb5cf12f69dc57de295425536671e2df38
Signed-off-by: wenfeng.guo <wenfeng.guo@amlogic.com>
PD#172587
Problem:
Bringup TL1 vidoe driver.
TL1 need support YUV422/444 AFBC.
TL1 need check afbc source from decode or vdin.
TL1 need afbc compress loss mode.
Solution:
Merge from branch bringup/amlogic-4.9/tl1-20181111.
Verify:
verify on tl1
Change-Id: I0af62e7638db4e1c349df874ccffdeddcaa715af
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
PD#SWPL-3144
Problem:
The latch function cause the super scaler size asynchronous
Solution:
Disable sr core0 and core1 scaler latch
Verify:
T962x2 x301 board test pass
Change-Id: Iecbcc3e0c751093b6515f7b46973eca2157cd349
Signed-off-by: Brian Zhu <brian.zhu@amlogic.com>
PD# 169839
After do suspend/resume circularly, sometimes ethernet can't recover from
suspend. Add a phy reset when every resume.
Change-Id: Id03223a9c62f4dcab1cdfbc4805cc3b4c0212cf5
Signed-off-by: Shen Liu <shen.liu@amlogic.com>
PD#SWPL-4331
Problem:
Same source clk doesn't recover to 48K
after playback 192k DDP stream.
Solution:
Add ways to recover the clk.
Verify:
Local verified
Change-Id: If410d9ca04446c35bafebe2913b01e19b5fee224
Signed-off-by: Shuai Li <shuai.li@amlogic.com>
PD#SWPL-5219
Problem:
audio glitch at tdm startup
Solution:
Pad 0 data to clear the remaining data
in the module.
Verify:
Local tested.
Change-Id: Iab526c6893a32030799567b57e05e7bb11b8fea0
Signed-off-by: Shuai Li <shuai.li@amlogic.com>
PD#SWPL-5131
Problem:
Some stream in tunnel mode, first audio pts is large than
AV_DISCONTINUE_THREDHOLD_MAX(60s). In audio_hw it will check pcr and
apts diff, so large difference between pcr and apts will lead sync mode
from amster to vmaster(egg:SYNC-HEVC-59FPS-DDP51)
Solution:
do not operate tsync_mode_switch before first video toggled
Verify:
verify by franklin
Change-Id: Icec2de71ea8f838146444aa3ea880f76ed8e0f13
Signed-off-by: Yingwei Long <yingwei.long@amlogic.com>
PD#SWPL-5113
Problem:
video flash when resolution change from 4K to 640x480
Solution:
temporary solution for video flash for u212
Verify:
verify by u212
Change-Id: I8b7ec009bf599032c7bff5f80b72b557403355da
Signed-off-by: shuanglong.wang <shuanglong.wang@amlogic.com>
PD#SWPL-4048
Problem:
video peek can not get first frame toggled on 64bit
Solution:
add the cmd to amvideo_compat_ioctl
Verify:
verify on p212
Change-Id: I6933f305382d636f5f98f4bf19fddcf6ce9471c1
Signed-off-by: Jian Wang <jian.wang@amlogic.com>
PD#SWPL-4079
Problem:
hdr->sdr must have 1.5s delay, when switching from sdr->hdr
the work queue can't be eliminated in time.
Solution:
eliminate the work of sdr effect when choosing hdr
Verify:
u212
Change-Id: I4c1d5467a58253ffa2fa12dfbac7f504d0388a00
Signed-off-by: Yi Zhou <yi.zhou@amlogic.com>
PD#SWPL-4317
Problem:
for video peek, before audio post audio start, video may have rended.
Solution:
do not post video start for video peek, all wait for audio start to
start pcr
Verify:
verify by p212
Change-Id: If5656154e30613164465f84c44d3fd1ee386d654
Signed-off-by: shuanglong.wang <shuanglong.wang@amlogic.com>
PD#SWPL-1207
Problem:
fix the filckered problem when playing transition
video in sdr tv
Solution:
when dv core2 don't run, the reset can't be executed
Verify:
r321
Change-Id: I719325f1722589e02a40d46442258b0d1e3feb17
Signed-off-by: Yi Zhou <yi.zhou@amlogic.com>
commit 6f496a555d upstream.
When KASLR and KASAN are both enabled, we keep the modules where they
are, and randomize the placement of the kernel so it is within 2 GB
of the module region. The reason for this is that putting modules in
the vmalloc region (like we normally do when KASLR is enabled) is not
possible in this case, given that the entire vmalloc region is already
backed by KASAN zero shadow pages, and so allocating dedicated KASAN
shadow space as required by loaded modules is not possible.
The default module allocation window is set to [_etext - 128MB, _etext]
in kaslr.c, which is appropriate for KASLR kernels booted without a
seed or with 'nokaslr' on the command line. However, as it turns out,
it is not quite correct for the KASAN case, since it still intersects
the vmalloc region at the top, where attempts to allocate shadow pages
will collide with the KASAN zero shadow pages, causing a WARN() and all
kinds of other trouble. So cap the top end to MODULES_END explicitly
when running with KASAN.
Cc: <stable@vger.kernel.org> # 4.9+
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Tested-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
[will: backport to 4.9.y]
Signed-off-by: Will Deacon <will@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3f93a4f297 upstream.
It is possible for an irq triggered by channel0 to be received later
after clks are disabled once firmware loaded during sdma probe. If
that happens then clearing them by writing to SDMA_H_INTR won't work
and the kernel will hang processing infinite interrupts. Actually,
don't need interrupt triggered on channel0 since it's pollling
SDMA_H_STATSTOP to know channel0 done rather than interrupt in
current code, just clear BD_INTR to disable channel0 interrupt to
avoid the above case.
This issue was brought by commit 1d069bfa3c ("dmaengine: imx-sdma:
ack channel 0 IRQ in the interrupt handler") which didn't take care
the above case.
Fixes: 1d069bfa3c ("dmaengine: imx-sdma: ack channel 0 IRQ in the interrupt handler")
Cc: stable@vger.kernel.org #5.0+
Signed-off-by: Robin Gong <yibin.gong@nxp.com>
Reported-by: Sven Van Asbroeck <thesven73@gmail.com>
Tested-by: Sven Van Asbroeck <thesven73@gmail.com>
Reviewed-by: Michael Olbrich <m.olbrich@pengutronix.de>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 0b24cae4d5 upstream.
Add a missing EHB (Execution Hazard Barrier) in mtc0 -> mfc0 sequence.
Without this execution hazard barrier it's possible for the value read
back from the KScratch register to be the value from before the mtc0.
Reproducible on P5600 & P6600.
The hazard is documented in the MIPS Architecture Reference Manual Vol.
III: MIPS32/microMIPS32 Privileged Resource Architecture (MD00088), rev
6.03 table 8.1 which includes:
Producer | Consumer | Hazard
----------|----------|----------------------------
mtc0 | mfc0 | any coprocessor 0 register
Signed-off-by: Dmitry Korotin <dkorotin@wavecomp.com>
[paul.burton@mips.com:
- Commit message tweaks.
- Add Fixes tags.
- Mark for stable back to v3.15 where P5600 support was introduced.]
Signed-off-by: Paul Burton <paul.burton@mips.com>
Fixes: 3d8bfdd030 ("MIPS: Use C0_KScratch (if present) to hold PGD pointer.")
Fixes: 829dcc0a95 ("MIPS: Add MIPS P5600 probe support")
Cc: linux-mips@vger.kernel.org
Cc: stable@vger.kernel.org # v3.15+
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit da9de5f852 upstream.
The call to sdma_progress() is called outside the wait lock.
In this case, there is a race condition where sdma_progress() can return
false and the sdma_engine can idle. If that happens, there will be no
more sdma interrupts to cause the wakeup and the user_sdma xmit will hang.
Fix by moving the lock to enclose the sdma_progress() call.
Also, delete busycount. The need for this was removed by:
commit bcad29137a ("IB/hfi1: Serve the most starved iowait entry first")
Cc: <stable@vger.kernel.org>
Fixes: 7724105686 ("IB/hfi1: add driver files")
Reviewed-by: Gary Leshner <Gary.S.Leshner@intel.com>
Signed-off-by: Mike Marciniszyn <mike.marciniszyn@intel.com>
Signed-off-by: Dennis Dalessandro <dennis.dalessandro@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit bb34e690e9 upstream.
Thomas reported that:
| Background:
|
| In preparation of supporting IPI shorthands I changed the CPU offline
| code to software disable the local APIC instead of just masking it.
| That's done by clearing the APIC_SPIV_APIC_ENABLED bit in the APIC_SPIV
| register.
|
| Failure:
|
| When the CPU comes back online the startup code triggers occasionally
| the warning in apic_pending_intr_clear(). That complains that the IRRs
| are not empty.
|
| The offending vector is the local APIC timer vector who's IRR bit is set
| and stays set.
|
| It took me quite some time to reproduce the issue locally, but now I can
| see what happens.
|
| It requires apicv_enabled=0, i.e. full apic emulation. With apicv_enabled=1
| (and hardware support) it behaves correctly.
|
| Here is the series of events:
|
| Guest CPU
|
| goes down
|
| native_cpu_disable()
|
| apic_soft_disable();
|
| play_dead()
|
| ....
|
| startup()
|
| if (apic_enabled())
| apic_pending_intr_clear() <- Not taken
|
| enable APIC
|
| apic_pending_intr_clear() <- Triggers warning because IRR is stale
|
| When this happens then the deadline timer or the regular APIC timer -
| happens with both, has fired shortly before the APIC is disabled, but the
| interrupt was not serviced because the guest CPU was in an interrupt
| disabled region at that point.
|
| The state of the timer vector ISR/IRR bits:
|
| ISR IRR
| before apic_soft_disable() 0 1
| after apic_soft_disable() 0 1
|
| On startup 0 1
|
| Now one would assume that the IRR is cleared after the INIT reset, but this
| happens only on CPU0.
|
| Why?
|
| Because our CPU0 hotplug is just for testing to make sure nothing breaks
| and goes through an NMI wakeup vehicle because INIT would send it through
| the boots-trap code which is not really working if that CPU was not
| physically unplugged.
|
| Now looking at a real world APIC the situation in that case is:
|
| ISR IRR
| before apic_soft_disable() 0 1
| after apic_soft_disable() 0 1
|
| On startup 0 0
|
| Why?
|
| Once the dying CPU reenables interrupts the pending interrupt gets
| delivered as a spurious interupt and then the state is clear.
|
| While that CPU0 hotplug test case is surely an esoteric issue, the APIC
| emulation is still wrong, Even if the play_dead() code would not enable
| interrupts then the pending IRR bit would turn into an ISR .. interrupt
| when the APIC is reenabled on startup.
From SDM 10.4.7.2 Local APIC State After It Has Been Software Disabled
* Pending interrupts in the IRR and ISR registers are held and require
masking or handling by the CPU.
In Thomas's testing, hardware cpu will not respect soft disable LAPIC
when IRR has already been set or APICv posted-interrupt is in flight,
so we can skip soft disable APIC checking when clearing IRR and set ISR,
continue to respect soft disable APIC when attempting to set IRR.
Reported-by: Rong Chen <rong.a.chen@intel.com>
Reported-by: Feng Tang <feng.tang@intel.com>
Reported-by: Thomas Gleixner <tglx@linutronix.de>
Tested-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Rong Chen <rong.a.chen@intel.com>
Cc: Feng Tang <feng.tang@intel.com>
Cc: stable@vger.kernel.org
Signed-off-by: Wanpeng Li <wanpengli@tencent.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
[ Upstream commit 423ea32554 ]
Make the forward declaration actually match the real function
definition, something that previous versions of gcc had just ignored.
This is another patch to fix new warnings from gcc-9 before I start the
merge window pulls. I don't want to miss legitimate new warnings just
because my system update brought a new compiler with new warnings.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
commit debd1c065d upstream.
Recent FITRIM work, namely bbbf7243d6 ("btrfs: combine device update
operations during transaction commit") combined the way certain
operations are recoded in a transaction. As a result an ASSERT was added
in dev_replace_finish to ensure the new code works correctly.
Unfortunately I got reports that it's possible to trigger the assert,
meaning that during a device replace it's possible to have an unfinished
chunk allocation on the source device.
This is supposed to be prevented by the fact that a transaction is
committed before finishing the replace oepration and alter acquiring the
chunk mutex. This is not sufficient since by the time the transaction is
committed and the chunk mutex acquired it's possible to allocate a chunk
depending on the workload being executed on the replaced device. This
bug has been present ever since device replace was introduced but there
was never code which checks for it.
The correct way to fix is to ensure that there is no pending device
modification operation when the chunk mutex is acquire and if there is
repeat transaction commit. Unfortunately it's not possible to just
exclude the source device from btrfs_fs_devices::dev_alloc_list since
this causes ENOSPC to be hit in transaction commit.
Fixing that in another way would need to add special cases to handle the
last writes and forbid new ones. The looped transaction fix is more
obvious, and can be easily backported. The runtime of dev-replace is
long so there's no noticeable delay caused by that.
Reported-by: David Sterba <dsterba@suse.com>
Fixes: 391cd9df81 ("Btrfs: fix unprotected alloc list insertion during the finishing procedure of replace")
CC: stable@vger.kernel.org # 4.4+
Signed-off-by: Nikolay Borisov <nborisov@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 78c68e8f5c upstream.
Notify drm core before sending pending events during crtc disable.
This fixes the first event after disable having an old stale timestamp
by having drm_crtc_vblank_off update the timestamp to now.
This was seen while debugging weston log message:
Warning: computed repaint delay is insane: -8212 msec
This occurred due to:
1. driver starts up
2. fbcon comes along and restores fbdev, enabling vblank
3. vblank_disable_fn fires via timer disabling vblank, keeping vblank
seq number and time set at current value
(some time later)
4. weston starts and does a modeset
5. atomic commit disables crtc while it does the modeset
6. ipu_crtc_atomic_disable sends vblank with old seq number and time
Fixes: a474478642 ("drm/imx: fix crtc vblank state regression")
Signed-off-by: Robert Beckett <bob.beckett@collabora.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 2acf5a3e6e upstream.
There are a couple of left shifts of unsigned 8 bit values that
first get promoted to signed ints and hence get sign extended
on the shift if the top bit of the 8 bit values are set. Fix
this by casting the 8 bit values to unsigned ints to stop the
unintentional sign extension.
Addresses-Coverity: ("Unintended sign extension")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 3450121997 upstream.
LINE6 drivers allocate the buffers based on the value returned from
usb_maxpacket() calls. The manipulated device may return zero for
this, and this results in the kmalloc() with zero size (and it may
succeed) while the other part of the driver code writes the packet
data with the fixed size -- which eventually overwrites.
This patch adds a simple sanity check for the invalid buffer size for
avoiding that problem.
Reported-by: syzbot+219f00fb49874dcaea17@syzkaller.appspotmail.com
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 7fbd1753b6 upstream.
In IEC 61883-6, 8 MIDI data streams are multiplexed into single
MIDI conformant data channel. The index of stream is calculated by
modulo 8 of the value of data block counter.
In fireworks, the value of data block counter in CIP header has a quirk
with firmware version v5.0.0, v5.7.3 and v5.8.0. This brings ALSA
IEC 61883-1/6 packet streaming engine to miss detection of MIDI
messages.
This commit fixes the miss detection to modify the value of data block
counter for the modulo calculation.
For maintainers, this bug exists since a commit 18f5ed365d ("ALSA:
fireworks/firewire-lib: add support for recent firmware quirk") in Linux
kernel v4.2. There're many changes since the commit. This fix can be
backported to Linux kernel v4.4 or later. I tagged a base commit to the
backport for your convenience.
Besides, my work for Linux kernel v5.3 brings heavy code refactoring and
some structure members are renamed in 'sound/firewire/amdtp-stream.h'.
The content of this patch brings conflict when merging -rc tree with
this patch and the latest tree. I request maintainers to solve the
conflict to replace 'tx_first_dbc' with 'ctx_data.tx.first_dbc'.
Fixes: df075feefb ("ALSA: firewire-lib: complete AM824 data block processing layer")
Cc: <stable@vger.kernel.org> # v4.4+
Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit c3ea60c231 upstream.
There are two occurrances of a call to snd_seq_oss_fill_addr where
the dest_client and dest_port arguments are in the wrong order. Fix
this by swapping them around.
Addresses-Coverity: ("Arguments in wrong order")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 21d4120ec6 upstream.
Michal Suchanek reported [1] that running the pcrypt_aead01 test from
LTP [2] in a loop and holding Ctrl-C causes a NULL dereference of
alg->cra_users.next in crypto_remove_spawns(), via crypto_del_alg().
The test repeatedly uses CRYPTO_MSG_NEWALG and CRYPTO_MSG_DELALG.
The crash occurs when the instance that CRYPTO_MSG_DELALG is trying to
unregister isn't a real registered algorithm, but rather is a "test
larval", which is a special "algorithm" added to the algorithms list
while the real algorithm is still being tested. Larvals don't have
initialized cra_users, so that causes the crash. Normally pcrypt_aead01
doesn't trigger this because CRYPTO_MSG_NEWALG waits for the algorithm
to be tested; however, CRYPTO_MSG_NEWALG returns early when interrupted.
Everything else in the "crypto user configuration" API has this same bug
too, i.e. it inappropriately allows operating on larval algorithms
(though it doesn't look like the other cases can cause a crash).
Fix this by making crypto_alg_match() exclude larval algorithms.
[1] https://lkml.kernel.org/r/20190625071624.27039-1-msuchanek@suse.de
[2] https://github.com/linux-test-project/ltp/blob/20190517/testcases/kernel/crypto/pcrypt_aead01.c
Reported-by: Michal Suchanek <msuchanek@suse.de>
Fixes: a38f7907b9 ("crypto: Add userspace configuration API")
Cc: <stable@vger.kernel.org> # v3.2+
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: Eric Biggers <ebiggers@google.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
commit 6994eefb00 upstream.
Fix two issues:
When called for PTRACE_TRACEME, ptrace_link() would obtain an RCU
reference to the parent's objective credentials, then give that pointer
to get_cred(). However, the object lifetime rules for things like
struct cred do not permit unconditionally turning an RCU reference into
a stable reference.
PTRACE_TRACEME records the parent's credentials as if the parent was
acting as the subject, but that's not the case. If a malicious
unprivileged child uses PTRACE_TRACEME and the parent is privileged, and
at a later point, the parent process becomes attacker-controlled
(because it drops privileges and calls execve()), the attacker ends up
with control over two processes with a privileged ptrace relationship,
which can be abused to ptrace a suid binary and obtain root privileges.
Fix both of these by always recording the credentials of the process
that is requesting the creation of the ptrace relationship:
current_cred() can't change under us, and current is the proper subject
for access control.
This change is theoretically userspace-visible, but I am not aware of
any code that it will actually break.
Fixes: 64b875f7ac ("ptrace: Capture the ptracer's creds not PT_PTRACE_CAP")
Signed-off-by: Jann Horn <jannh@google.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
