| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
commit 578797f0c8cbc2e3ec5fc0dab87087b4c7073686 upstream.
A fix for:
BUG: KASAN: slab-out-of-bounds in ses_intf_remove+0x23f/0x270 [ses]
Read of size 8 at addr ffff88a10d32e5d8 by task rmmod/12013
When edev->components is zero, accessing edev->component[0] members is
wrong.
Link: https://lore.kernel.org/r/20230202162451.15346-5-thenzl@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 801ab13d50cf3d26170ee073ea8bb4eececb76ab upstream.
Sanitize possible desc_ptr out-of-bounds accesses in
ses_enclosure_data_process().
Link: https://lore.kernel.org/r/20230202162451.15346-4-thenzl@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit db95d4df71cb55506425b6e4a5f8d68e3a765b63 upstream.
Sanitize possible addl_desc_ptr out-of-bounds accesses in
ses_enclosure_data_process().
Link: https://lore.kernel.org/r/20230202162451.15346-3-thenzl@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 9b4f5028e493cb353a5c8f5c45073eeea0303abd upstream.
A fix for:
BUG: KASAN: slab-out-of-bounds in ses_enclosure_data_process+0x949/0xe30 [ses]
Read of size 1 at addr ffff88a1b043a451 by task systemd-udevd/3271
Checking after (and before in next loop) addl_desc_ptr[1] is sufficient, we
expect the size to be sanitized before first access to addl_desc_ptr[1].
Make sure we don't walk beyond end of page.
Link: https://lore.kernel.org/r/20230202162451.15346-2-thenzl@redhat.com
Cc: stable@vger.kernel.org
Signed-off-by: Tomas Henzl <thenzl@redhat.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3fe97ff3d94934649abb0652028dd7296170c8d0 upstream.
An enclosure with no components can't usefully be operated by the driver
(since effectively it has nothing to manage), so report the problem and
don't attach. Not attaching also fixes an oops which could occur if the
driver tries to manage a zero component enclosure.
[mkp: Switched to KERN_WARNING since this scenario is common]
Link: https://lore.kernel.org/r/c5deac044ac409e32d9ad9968ce0dcbc996bfc7a.camel@linux.ibm.com
Cc: stable@vger.kernel.org
Reported-by: Ding Hui <dinghui@sangfor.com.cn>
Signed-off-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 3fbc74feb642deb688cc97f76d40b7287ddd4cb1 upstream.
If after an adapter reset the appearance of link is not recovered, the
devices are not rediscovered. This is result of a race condition between
adapter reset (abort_isp) and the topology scan. During adapter reset, the
ABORT_ISP_ACTIVE flag is set. Topology scan usually occurred after adapter
reset. In this case, the topology scan came earlier than usual where it
ran into problem due to ABORT_ISP_ACTIVE flag was still set.
kernel: qla2xxx [0000:13:00.0]-1005:1: Cmd 0x6a aborted with timeout since ISP Abort is pending
kernel: qla2xxx [0000:13:00.0]-28a0:1: MBX_GET_PORT_NAME failed, No FL Port.
kernel: qla2xxx [0000:13:00.0]-286b:1: qla2x00_configure_loop: exiting normally. local port wwpn 51402ec0123d9a80 id 012300)
kernel: qla2xxx [0000:13:00.0]-8017:1: ADAPTER RESET SUCCEEDED nexus=1:0:15.
Allow adapter reset to complete before any scan can start.
Cc: stable@vger.kernel.org
Signed-off-by: Quinn Tran <qutran@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c75e6aef5039830cce5d4cf764dd204522f89e6b upstream.
The following message and call trace was seen with debug kernels:
DMA-API: qla2xxx 0000:41:00.0: device driver failed to check map
error [device address=0x00000002a3ff38d8] [size=1024 bytes] [mapped as
single]
WARNING: CPU: 0 PID: 2930 at kernel/dma/debug.c:1017
check_unmap+0xf42/0x1990
Call Trace:
debug_dma_unmap_page+0xc9/0x100
qla_nvme_ls_unmap+0x141/0x210 [qla2xxx]
Remove DMA mapping from the driver altogether, as it is already done by FC
layer. This prevents the warning.
Fixes: c85ab7d9e27a ("scsi: qla2xxx: Fix missed DMA unmap for NVMe ls requests")
Cc: stable@vger.kernel.org
Signed-off-by: Arun Easi <aeasi@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit b1ae65c082f74536ec292b15766f2846f0238373 upstream.
User experienced symptoms of adapter failure in NPIV environment. NPIV
hosts were allowed to trigger chip reset back to back due to NPIV link
state being slow to come online.
Fix link failure in NPIV environment by removing NPIV host from directly
being able to perform chip reset.
kernel: qla2xxx [0000:04:00.1]-6009:261: Loop down - aborting ISP.
kernel: qla2xxx [0000:04:00.1]-6009:262: Loop down - aborting ISP.
kernel: qla2xxx [0000:04:00.1]-6009:281: Loop down - aborting ISP.
kernel: qla2xxx [0000:04:00.1]-6009:285: Loop down - aborting ISP
Fixes: 0d6e61bc6a4f ("[SCSI] qla2xxx: Correct various NPIV issues.")
Cc: stable@vger.kernel.org
Signed-off-by: Quinn Tran <qutran@marvell.com>
Signed-off-by: Nilesh Javali <njavali@marvell.com>
Reviewed-by: Himanshu Madhani <himanshu.madhani@oracle.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 909d3096ac99fa2289f9b8945a3eab2269947a0a upstream.
Get the PM runtime usage_count and forbid PM runtime at driver unbind. The
opposite is being done in probe() already.
Fixes: commit c2a6a07afe4a ("media: intel-ipu3: cio2: add new MIPI-CSI2 driver")
Cc: stable@vger.kernel.org # for >= 4.16
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Reviewed-by: Bingbu Cao <bingbu.cao@intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f7c4d9b133c7a04ca619355574e96b6abf209fba upstream.
If getting an ID or setting up a work queue in rbd_dev_create() fails,
use-after-free on rbd_dev->rbd_client, rbd_dev->spec and rbd_dev->opts
is triggered in do_rbd_add(). The root cause is that the ownership of
these structures is transfered to rbd_dev prematurely and they all end
up getting freed when rbd_dev_create() calls rbd_dev_free() prior to
returning to do_rbd_add().
Found by Linux Verification Center (linuxtesting.org) with SVACE, an
incomplete patch submitted by Natalia Petrova <n.petrova@fintech.ru>.
Cc: stable@vger.kernel.org
Fixes: 1643dfa4c2c8 ("rbd: introduce a per-device ordered workqueue")
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit f50714b57aecb6b3dc81d578e295f86d9c73f078 upstream.
When we need to zero some range on a block device, the function
__blkdev_issue_zero_pages submits a write bio with the bio vector pointing
to the zero page. If we use dm-flakey with corrupt bio writes option, it
will corrupt the content of the zero page which results in crashes of
various userspace programs. Glibc assumes that memory returned by mmap is
zeroed and it uses it for calloc implementation; if the newly mapped
memory is not zeroed, calloc will return non-zeroed memory.
Fix this bug by testing if the page is equal to ZERO_PAGE(0) and
avoiding the corruption in this case.
Cc: stable@vger.kernel.org
Fixes: a00f5276e266 ("dm flakey: Properly corrupt multi-page bios.")
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit aa56b9b75996ff4c76a0a4181c2fa0206c3d91cc upstream.
If "corrupt_bio_byte" is set to corrupt reads and corrupt_bio_flags is
used, dm-flakey would erroneously return all writes as errors. Likewise,
if "corrupt_bio_byte" is set to corrupt writes, dm-flakey would return
errors for all reads.
Fix the logic so that if fc->corrupt_bio_byte is non-zero, dm-flakey
will not abort reads on writes with an error.
Cc: stable@vger.kernel.org
Signed-off-by: Mikulas Patocka <mpatocka@redhat.com>
Reviewed-by: Sweet Tea Dorminy <sweettea-kernel@dorminy.me>
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8e47363588377e1bdb65e2b020b409cfb44dd260 upstream.
The powerclamp cooling device cur_state shows actual idle observed by
package C-state idle counters. But the implementation is not sufficient
for multi package or multi die system. The cur_state value is incorrect.
On these systems, these counters must be read from each package/die and
somehow aggregate them. But there is no good method for aggregation.
It was not a problem when explicit CPU model addition was required to
enable intel powerclamp. In this way certain CPU models could have
been avoided. But with the removal of CPU model check with the
availability of Package C-state counters, the driver is loaded on most
of the recent systems.
For multi package/die systems, just show the actual target idle state,
the system is trying to achieve. In powerclamp this is the user set
state minus one.
Also there is no use of starting a worker thread for polling package
C-state counters and applying any compensation for multiple package
or multiple die systems.
Fixes: b721ca0d1927 ("thermal/powerclamp: remove cpu whitelist")
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Cc: 4.14+ <stable@vger.kernel.org> # 4.14+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2a86aa9a1892d60ef2e3f310f5b42b8b05546d65 upstream.
The Realtek rate control algorithm goes back and forth a lot between
the highest and the lowest rate it's allowed to use. This is due to
a lot of frames being dropped because the retry limits set by
IEEE80211_CONF_CHANGE_RETRY_LIMITS are too low. (Experimentally, they
are 4 for long frames and 7 for short frames.)
The vendor drivers hardcode the value 48 for both retry limits (for
station mode), which makes dropped frames very rare and thus the rate
control is more stable.
Because most Realtek chips handle the rate control in the firmware,
which can't be modified, ignore the limits set by
IEEE80211_CONF_CHANGE_RETRY_LIMITS and use the value 48 (set during
chip initialisation), same as the vendor drivers.
Cc: stable@vger.kernel.org
Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/477d745b-6bac-111d-403c-487fc19aa30d@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 8230831c43a328c2be6d28c65d3f77e14c59986b upstream.
Rename the SSIF_IDLE() to IS_SSIF_IDLE(), since that is more clear, and
rename SSIF_NORMAL to SSIF_IDLE, since that's more accurate.
Cc: stable@vger.kernel.org
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c88db0eff9722fc2b6c4d172a50471d20e08ecc6 upstream.
Make sure to disable the alarm before updating the four alarm time
registers to avoid spurious alarms during the update.
Note that the disable needs to be done outside of the ctrl_reg_lock
section to prevent a racing alarm interrupt from disabling the newly set
alarm when the lock is released.
Fixes: 9a9a54ad7aa2 ("drivers/rtc: add support for Qualcomm PMIC8xxx RTC")
Cc: stable@vger.kernel.org # 3.1
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Reviewed-by: David Collins <quic_collinsd@quicinc.com>
Link: https://lore.kernel.org/r/20230202155448.6715-2-johan+linaro@kernel.org
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit e6acaf25cba14661211bb72181c35dd13b24f5b3 upstream.
The coreboot framebuffer doesn't support transparency, its 'reserved'
bit field is merely padding for byte/word alignment of pixel colors [1].
When trying to match the framebuffer to a simplefb format, the kernel
driver unnecessarily requires the format's transparency bit field to
exactly match this padding, even if the former is zero-width.
Due to a coreboot bug [2] (fixed upstream), some boards misreport the
reserved field's size as equal to its position (0x18 for both on a
'Lick' Chromebook), and the driver fails to probe where it would have
otherwise worked fine with e.g. the a8r8g8b8 or x8r8g8b8 formats.
Remove the transparency comparison with reserved bits. When the
bits-per-pixel and other color components match, transparency will
already be in a subset of the reserved field. Not forcing it to match
reserved bits allows the driver to work on the boards which misreport
the reserved field. It also enables using simplefb formats that don't
have transparency bits, although this doesn't currently happen due to
format support and ordering in linux/platform_data/simplefb.h.
[1] https://review.coreboot.org/plugins/gitiles/coreboot/+/4.19/src/commonlib/include/commonlib/coreboot_tables.h#255
[2] https://review.coreboot.org/plugins/gitiles/coreboot/+/4.13/src/drivers/intel/fsp2_0/graphics.c#82
Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
Link: https://lore.kernel.org/r/20230122190433.195941-1-alpernebiyasak@gmail.com
Cc: Salvatore Bonaccorso <carnil@debian.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit c6015bf3ff1ffb3caa27eb913797438a0fc634a0 upstream.
Fixing transmission failure which results in
"authentication with ... timed out". This can be
fixed by disable the REG_TXPAUSE.
Signed-off-by: Jun ASAKA <JunASAKA@zzy040330.moe>
Reviewed-by: Ping-Ke Shih <pkshih@realtek.com>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221217030659.12577-1-JunASAKA@zzy040330.moe
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
[ Upstream commit 76227f6dc805e9e960128bcc6276647361e0827c ]
Otherwise on resource constrained systems these workqueues may be too
greedy.
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e4f80303c2353952e6e980b23914e4214487f2a6 ]
Otherwise on resource constrained systems these workqueues may be too
greedy.
Signed-off-by: Mike Snitzer <snitzer@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 38b2d8efd03d2e56431b611e3523f0158306451d ]
Another Lenovo convertable where the panel is installed landscape but is
reported to the kernel as portrait.
Signed-off-by: Darrell Kavanagh <darrell.kavanagh@gmail.com>
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20230214164659.3583-1-darrell.kavanagh@gmail.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 1c4e5c470a56f7f7c649c0c70e603abc1eab15c4 ]
Use devm_kasprintf() instead of kasprintf() to avoid any potential
leaks. At the moment drivers have no remove functionality thus
there is no need for fixes tag.
Signed-off-by: Claudiu Beznea <claudiu.beznea@microchip.com>
Link: https://lore.kernel.org/r/20230203132714.1931596-1-claudiu.beznea@microchip.com
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6d03bbff456befeccdd4d663177c4d6c75d0c4ff ]
Coretemp's platform driver is unconventional. All the real work is done
globally by the initcall and CPU hotplug notifiers, while the "driver"
effectively just wraps an allocation and the registration of the hwmon
interface in a long-winded round-trip through the driver core. The whole
logic of dynamically creating and destroying platform devices to bring
the interfaces up and down is error prone, since it assumes
platform_device_add() will synchronously bind the driver and set drvdata
before it returns, thus results in a NULL dereference if drivers_autoprobe
is turned off for the platform bus. Furthermore, the unusual approach of
doing that from within a CPU hotplug notifier, already commented in the
code that it deadlocks suspend, also causes lockdep issues for other
drivers or subsystems which may want to legitimately register a CPU
hotplug notifier from a platform bus notifier.
All of these issues can be solved by ripping this unusual behaviour out
completely, simply tying the platform devices to the lifetime of the
module itself, and directly managing the hwmon interfaces from the
hotplug notifiers. There is a slight user-visible change in that
/sys/bus/platform/drivers/coretemp will no longer appear, and
/sys/devices/platform/coretemp.n will remain present if package n is
hotplugged off, but hwmon users should really only be looking for the
presence of the hwmon interfaces, whose behaviour remains unchanged.
Link: https://lore.kernel.org/lkml/20220922101036.87457-1-janusz.krzysztofik@linux.intel.com/
Link: https://gitlab.freedesktop.org/drm/intel/issues/6641
Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Signed-off-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://lore.kernel.org/r/20230103114620.15319-1-janusz.krzysztofik@linux.intel.com
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e314e15a0b58f9d051c00b25951073bcdae61953 ]
The compiler has no way to know if "id" is within the array bounds of
the regulators array. Add a check for this and a build-time check that
the regulators and reg_voltage_map arrays are sized the same. Seen with
GCC 13:
../drivers/regulator/s5m8767.c: In function 's5m8767_pmic_probe':
../drivers/regulator/s5m8767.c:936:35: warning: array subscript [0, 36] is outside array bounds of 'struct regulator_desc[37]' [-Warray-bounds=]
936 | regulators[id].vsel_reg =
| ~~~~~~~~~~^~~~
Cc: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: linux-samsung-soc@vger.kernel.org
Signed-off-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20230128005358.never.313-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 4fd8bcec5fd7c0d586206fa2f42bd67b06cdaa7e ]
Explicitly bounds-check the id before accessing the opmode array. Seen
with GCC 13:
../drivers/regulator/max77802-regulator.c: In function 'max77802_enable':
../drivers/regulator/max77802-regulator.c:217:29: warning: array subscript [0, 41] is outside array bounds of 'unsigned int[42]' [-Warray-bounds=]
217 | if (max77802->opmode[id] == MAX77802_OFF_PWRREQ)
| ~~~~~~~~~~~~~~~~^~~~
../drivers/regulator/max77802-regulator.c:62:22: note: while referencing 'opmode'
62 | unsigned int opmode[MAX77802_REG_MAX];
| ^~~~~~
Cc: Javier Martinez Canillas <javier@dowhile0.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Acked-by: Javier Martinez Canillas <javierm@redhat.com>
Link: https://lore.kernel.org/r/20230127225203.never.864-kees@kernel.org
Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 115906ca7b535afb1fe7b5406c566ccd3873f82b ]
Add check for the return value of alloc_ordered_workqueue as it may return
NULL pointer and cause NULL pointer dereference.
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com>
Patchwork: https://patchwork.freedesktop.org/patch/517646/
Link: https://lore.kernel.org/r/20230110021651.12770-1-jiasheng@iscas.ac.cn
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 4773fadedca918faec443daaca5e4ea1c0ced144 ]
Fix below kmemleak when unload radeon driver:
unreferenced object 0xffff9f8608ede200 (size 512):
comm "systemd-udevd", pid 326, jiffies 4294682822 (age 716.338s)
hex dump (first 32 bytes):
00 00 00 00 c4 aa ec aa 14 ab 00 00 00 00 00 00 ................
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<0000000062fadebe>] kmem_cache_alloc_trace+0x2f1/0x500
[<00000000b6883cea>] atom_parse+0x117/0x230 [radeon]
[<00000000158c23fd>] radeon_atombios_init+0xab/0x170 [radeon]
[<00000000683f672e>] si_init+0x57/0x750 [radeon]
[<00000000566cc31f>] radeon_device_init+0x559/0x9c0 [radeon]
[<0000000046efabb3>] radeon_driver_load_kms+0xc1/0x1a0 [radeon]
[<00000000b5155064>] drm_dev_register+0xdd/0x1d0
[<0000000045fec835>] radeon_pci_probe+0xbd/0x100 [radeon]
[<00000000e69ecca3>] pci_device_probe+0xe1/0x160
[<0000000019484b76>] really_probe.part.0+0xc1/0x2c0
[<000000003f2649da>] __driver_probe_device+0x96/0x130
[<00000000231c5bb1>] driver_probe_device+0x24/0xf0
[<0000000000a42377>] __driver_attach+0x77/0x190
[<00000000d7574da6>] bus_for_each_dev+0x7f/0xd0
[<00000000633166d2>] driver_attach+0x1e/0x30
[<00000000313b05b8>] bus_add_driver+0x12c/0x1e0
iio was allocated in atom_index_iio() called by atom_parse(),
but it doesn't got released when the dirver is shutdown.
Fix this kmemleak by free it in radeon_atombios_fini().
Signed-off-by: Liwei Song <liwei.song@windriver.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2d60f9f4f26785a00273cb81fe60eff129ebd449 ]
HUTRR110 added a new usage code for a key that is supposed to
mute/unmute microphone system-wide.
Map the new usage code(0x01 0xa9) to keycode KEY_MICMUTE.
Additionally hid-debug is adjusted to recognize this keycode as well.
Signed-off-by: Jingyuan Liang <jingyliang@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit cfca78971b9233aef0891507a98fba62046d4542 ]
dsi_dump_dsi_irqs(), a function used for debugfs prints, has a large
struct in its frame, which can result in:
drivers/gpu/drm/omapdrm/dss/dsi.c:1126:1: warning: the frame size of 1060 bytes is larger than 1024 bytes [-Wframe-larger-than=]
As the performance of the function is of no concern, let's allocate the
struct with kmalloc instead.
Compile-tested only.
Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Reported-by: kernel test robot <lkp@intel.com>
Reviewed-by: Arnd Bergmann <arnd@arndb.de>
Link: https://patchwork.freedesktop.org/patch/msgid/20220916082206.167427-1-tomi.valkeinen@ideasonboard.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7a7175a2cd84b7874bebbf8e59f134557a34161b ]
[Why]
Fixing smatch error:
dm_resume() error: we previously assumed 'aconnector->dc_link' could be null
[How]
Check if dc_link null at the beginning of the loop,
so further checks can be dropped.
Reported-by: kernel test robot <lkp@intel.com>
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reviewed-by: Wayne Lin <Wayne.Lin@amd.com>
Acked-by: Jasdeep Dhillon <jdhillon@amd.com>
Signed-off-by: Roman Li <roman.li@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 988c2352273997a242f15c4fc3711773515006a2 ]
The debug message specify tdsn, but takes as an argument the
tmsn. The correct argument is tmsn, hence, fix the print.
Signed-off-by: Shay Drory <shayd@nvidia.com>
Reviewed-by: Moshe Shemesh <moshe@nvidia.com>
Signed-off-by: Saeed Mahameed <saeedm@nvidia.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 2d11eae42d52a131f06061015e49dc0f085c5bfc ]
Multiple Ideapad Z570 variants need acpi_backlight=native to force native
use on these pre Windows 8 machines since acpi_video backlight control
does not work here.
The original DMI quirk matches on a product_name of "102434U" but other
variants may have different product_name-s such as e.g. "1024D9U".
Move to checking product_version instead as is more or less standard for
Lenovo DMI quirks for similar reasons.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 1b88b47e898edef0e56e3a2f4e49f052a136153d ]
Free rx_head skb in mt76_dma_rx_cleanup routine in order to avoid
possible memory leak at module unload.
Signed-off-by: Lorenzo Bianconi <lorenzo@kernel.org>
Signed-off-by: Felix Fietkau <nbd@nbd.name>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 5c0862c2c962052ed5055220a00ac1cefb92fbcd ]
Occasionnaly we may get oversized packets from the hardware which
exceed the nomimal 2KiB buffer size we allocate SKBs with. Add an early
check which drops the packet to avoid invoking skb_over_panic() and move
on to processing the next packet.
Signed-off-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 8f9e0a52810dd83406c768972d022c37e7a18f1f ]
The ACPICA code has been built with '-Os' since the beginning of git
history, though there's no explanatory comment as to why.
This is unfortunate as GCC drops the alignment specificed by
'-falign-functions=N' when '-Os' is used, as reported in GCC bug 88345:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88345
This prevents CONFIG_FUNCTION_ALIGNMENT and
CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B from having their expected effect
on the ACPICA code. This is doubly unfortunate as in subsequent patches
arm64 will depend upon CONFIG_FUNCTION_ALIGNMENT for its ftrace
implementation.
Drop the '-Os' flag when building the ACPICA code. With this removed,
the code builds cleanly and works correctly in testing so far.
I've tested this by selecting CONFIG_DEBUG_FORCE_FUNCTION_ALIGN_64B=y,
building and booting a kernel using ACPI, and looking for misaligned
text symbols:
* arm64:
Before, v6.2-rc3:
# uname -rm
6.2.0-rc3 aarch64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
5009
Before, v6.2-rc3 + fixed __cold:
# uname -rm
6.2.0-rc3-00001-g2a2bedf8bfa9 aarch64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
919
After:
# uname -rm
6.2.0-rc3-00002-g267bddc38572 aarch64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
323
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l
0
* x86_64:
Before, v6.2-rc3:
# uname -rm
6.2.0-rc3 x86_64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
11537
Before, v6.2-rc3 + fixed __cold:
# uname -rm
6.2.0-rc3-00001-g2a2bedf8bfa9 x86_64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
2805
After:
# uname -rm
6.2.0-rc3-00002-g267bddc38572 x86_64
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | wc -l
1357
# grep ' [Tt] ' /proc/kallsyms | grep -iv '[048c]0 [Tt] ' | grep acpi | wc -l
0
With the patch applied, the remaining unaligned text labels are a
combination of static call trampolines and labels in assembly, which can
be dealt with in subsequent patches.
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Cc: Florent Revest <revest@chromium.org>
Cc: Len Brown <lenb@kernel.org>
Cc: Masami Hiramatsu <mhiramat@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Robert Moore <robert.moore@intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: Will Deacon <will@kernel.org>
Cc: linux-acpi@vger.kernel.org
Link: https://lore.kernel.org/r/20230123134603.1064407-4-mark.rutland@arm.com
Signed-off-by: Catalin Marinas <catalin.marinas@arm.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6a8d013e904ad9a66706fcc926ec9993bed7d190 ]
There were a few places we had missed checking the VSI type to make sure
it was definitely a PF VSI, before calling setup functions intended only
for the PF VSI.
This doesn't fix any explicit bugs but cleans up the code in a few
places and removes one explicit != vsi->type check that can be
superseded by this code (it's a super set)
Signed-off-by: Jesse Brandeburg <jesse.brandeburg@intel.com>
Tested-by: Gurucharan G <gurucharanx.g@intel.com> (A Contingent worker at Intel)
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 803f3176c5df3b5582c27ea690f204abb60b19b9 ]
Fix an integer underflow that leads to a null pointer dereference in
'mt7601u_rx_skb_from_seg()'. The variable 'dma_len' in the URB packet
could be manipulated, which could trigger an integer underflow of
'seg_len' in 'mt7601u_rx_process_seg()'. This underflow subsequently
causes the 'bad_frame' checks in 'mt7601u_rx_skb_from_seg()' to be
bypassed, eventually leading to a dereference of the pointer 'p', which
is a null pointer.
Ensure that 'dma_len' is greater than 'min_seg_len'.
Found by a modified version of syzkaller.
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 12 Comm: ksoftirqd/0 Tainted: G W O 5.14.0+
#139
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
RIP: 0010:skb_add_rx_frag+0x143/0x370
Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44
89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00
RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8
RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010
R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000
R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008
FS: 0000000000000000(0000) GS:ffff88811a800000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
mt7601u_rx_tasklet+0xc73/0x1270
? mt7601u_submit_rx_buf.isra.0+0x510/0x510
? tasklet_action_common.isra.0+0x79/0x2f0
tasklet_action_common.isra.0+0x206/0x2f0
__do_softirq+0x1b5/0x880
? tasklet_unlock+0x30/0x30
run_ksoftirqd+0x26/0x50
smpboot_thread_fn+0x34f/0x7d0
? smpboot_register_percpu_thread+0x370/0x370
kthread+0x3a1/0x480
? set_kthread_struct+0x120/0x120
ret_from_fork+0x1f/0x30
Modules linked in: 88XXau(O) 88x2bu(O)
---[ end trace 57f34f93b4da0f9b ]---
RIP: 0010:skb_add_rx_frag+0x143/0x370
Code: e2 07 83 c2 03 38 ca 7c 08 84 c9 0f 85 86 01 00 00 4c 8d 7d 08 44
89 68 08 48 b8 00 00 00 00 00 fc ff df 4c 89 fa 48 c1 ea 03 <80> 3c 02
00 0f 85 cd 01 00 00 48 8b 45 08 a8 01 0f 85 3d 01 00 00
RSP: 0018:ffffc900000cfc90 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: ffff888115520dc0 RCX: 0000000000000000
RDX: 0000000000000001 RSI: ffff8881118430c0 RDI: ffff8881118430f8
RBP: 0000000000000000 R08: 0000000000000e09 R09: 0000000000000010
R10: ffff888111843017 R11: ffffed1022308602 R12: 0000000000000000
R13: 0000000000000e09 R14: 0000000000000010 R15: 0000000000000008
FS: 0000000000000000(0000) GS:ffff88811a800000(0000)
knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000004035af40 CR3: 00000001157f2000 CR4: 0000000000750ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221229092906.2328282-1-jisoo.jang@yonsei.ac.kr
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
stack-out-of-bounds
[ Upstream commit 660145d708be52f946a82e5b633c020f58f996de ]
Fix a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strreplace() in brcmf_c_preinit_dcmds(). This buffer is filled with
a CLM version string by memcpy() in brcmf_fil_iovar_data_get().
Ensure buf is null-terminated.
Found by a modified version of syzkaller.
[ 33.004414][ T1896] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 33.013486][ T1896] brcmfmac: brcmf_c_preinit_dcmds: Firmware: BCM43236/3 wl0: Nov 30 2011 17:33:42 version 5.90.188.22
[ 33.021554][ T1896] ==================================================================
[ 33.022379][ T1896] BUG: KASAN: stack-out-of-bounds in strreplace+0xf2/0x110
[ 33.023122][ T1896] Read of size 1 at addr ffffc90001d6efc8 by task kworker/0:2/1896
[ 33.023852][ T1896]
[ 33.024096][ T1896] CPU: 0 PID: 1896 Comm: kworker/0:2 Tainted: G O 5.14.0+ #132
[ 33.024927][ T1896] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 33.026065][ T1896] Workqueue: usb_hub_wq hub_event
[ 33.026581][ T1896] Call Trace:
[ 33.026896][ T1896] dump_stack_lvl+0x57/0x7d
[ 33.027372][ T1896] print_address_description.constprop.0.cold+0xf/0x334
[ 33.028037][ T1896] ? strreplace+0xf2/0x110
[ 33.028403][ T1896] ? strreplace+0xf2/0x110
[ 33.028807][ T1896] kasan_report.cold+0x83/0xdf
[ 33.029283][ T1896] ? strreplace+0xf2/0x110
[ 33.029666][ T1896] strreplace+0xf2/0x110
[ 33.029966][ T1896] brcmf_c_preinit_dcmds+0xab1/0xc40
[ 33.030351][ T1896] ? brcmf_c_set_joinpref_default+0x100/0x100
[ 33.030787][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 33.031223][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 33.031661][ T1896] ? lock_acquire+0x19d/0x4e0
[ 33.032091][ T1896] ? find_held_lock+0x2d/0x110
[ 33.032605][ T1896] ? brcmf_usb_deq+0x1a7/0x260
[ 33.033087][ T1896] ? brcmf_usb_rx_fill_all+0x5a/0xf0
[ 33.033582][ T1896] brcmf_attach+0x246/0xd40
[ 33.034022][ T1896] ? wiphy_new_nm+0x1476/0x1d50
[ 33.034383][ T1896] ? kmemdup+0x30/0x40
[ 33.034722][ T1896] brcmf_usb_probe+0x12de/0x1690
[ 33.035223][ T1896] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[ 33.035833][ T1896] usb_probe_interface+0x25f/0x710
[ 33.036315][ T1896] really_probe+0x1be/0xa90
[ 33.036656][ T1896] __driver_probe_device+0x2ab/0x460
[ 33.037026][ T1896] ? usb_match_id.part.0+0x88/0xc0
[ 33.037383][ T1896] driver_probe_device+0x49/0x120
[ 33.037790][ T1896] __device_attach_driver+0x18a/0x250
[ 33.038300][ T1896] ? driver_allows_async_probing+0x120/0x120
[ 33.038986][ T1896] bus_for_each_drv+0x123/0x1a0
[ 33.039906][ T1896] ? bus_rescan_devices+0x20/0x20
[ 33.041412][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 33.041861][ T1896] ? trace_hardirqs_on+0x1c/0x120
[ 33.042330][ T1896] __device_attach+0x207/0x330
[ 33.042664][ T1896] ? device_bind_driver+0xb0/0xb0
[ 33.043026][ T1896] ? kobject_uevent_env+0x230/0x12c0
[ 33.043515][ T1896] bus_probe_device+0x1a2/0x260
[ 33.043914][ T1896] device_add+0xa61/0x1ce0
[ 33.044227][ T1896] ? __mutex_unlock_slowpath+0xe7/0x660
[ 33.044891][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550
[ 33.045531][ T1896] usb_set_configuration+0x984/0x1770
[ 33.046051][ T1896] ? kernfs_create_link+0x175/0x230
[ 33.046548][ T1896] usb_generic_driver_probe+0x69/0x90
[ 33.046931][ T1896] usb_probe_device+0x9c/0x220
[ 33.047434][ T1896] really_probe+0x1be/0xa90
[ 33.047760][ T1896] __driver_probe_device+0x2ab/0x460
[ 33.048134][ T1896] driver_probe_device+0x49/0x120
[ 33.048516][ T1896] __device_attach_driver+0x18a/0x250
[ 33.048910][ T1896] ? driver_allows_async_probing+0x120/0x120
[ 33.049437][ T1896] bus_for_each_drv+0x123/0x1a0
[ 33.049814][ T1896] ? bus_rescan_devices+0x20/0x20
[ 33.050164][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 33.050579][ T1896] ? trace_hardirqs_on+0x1c/0x120
[ 33.050936][ T1896] __device_attach+0x207/0x330
[ 33.051399][ T1896] ? device_bind_driver+0xb0/0xb0
[ 33.051888][ T1896] ? kobject_uevent_env+0x230/0x12c0
[ 33.052314][ T1896] bus_probe_device+0x1a2/0x260
[ 33.052688][ T1896] device_add+0xa61/0x1ce0
[ 33.053121][ T1896] ? __fw_devlink_link_to_suppliers+0x550/0x550
[ 33.053568][ T1896] usb_new_device.cold+0x463/0xf66
[ 33.053953][ T1896] ? hub_disconnect+0x400/0x400
[ 33.054313][ T1896] ? rwlock_bug.part.0+0x90/0x90
[ 33.054661][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 33.055094][ T1896] hub_event+0x10d5/0x3330
[ 33.055530][ T1896] ? hub_port_debounce+0x280/0x280
[ 33.055934][ T1896] ? __lock_acquire+0x1671/0x5790
[ 33.056387][ T1896] ? wq_calc_node_cpumask+0x170/0x2a0
[ 33.056924][ T1896] ? lock_release+0x640/0x640
[ 33.057383][ T1896] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 33.057916][ T1896] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 33.058402][ T1896] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 33.059019][ T1896] process_one_work+0x873/0x13e0
[ 33.059488][ T1896] ? lock_release+0x640/0x640
[ 33.059932][ T1896] ? pwq_dec_nr_in_flight+0x320/0x320
[ 33.060446][ T1896] ? rwlock_bug.part.0+0x90/0x90
[ 33.060898][ T1896] worker_thread+0x8b/0xd10
[ 33.061348][ T1896] ? __kthread_parkme+0xd9/0x1d0
[ 33.061810][ T1896] ? process_one_work+0x13e0/0x13e0
[ 33.062288][ T1896] kthread+0x379/0x450
[ 33.062660][ T1896] ? _raw_spin_unlock_irq+0x24/0x30
[ 33.063148][ T1896] ? set_kthread_struct+0x100/0x100
[ 33.063606][ T1896] ret_from_fork+0x1f/0x30
[ 33.064070][ T1896]
[ 33.064313][ T1896]
[ 33.064545][ T1896] addr ffffc90001d6efc8 is located in stack of task kworker/0:2/1896 at offset 512 in frame:
[ 33.065478][ T1896] brcmf_c_preinit_dcmds+0x0/0xc40
[ 33.065973][ T1896]
[ 33.066191][ T1896] this frame has 4 objects:
[ 33.066614][ T1896] [48, 56) 'ptr'
[ 33.066618][ T1896] [80, 148) 'revinfo'
[ 33.066957][ T1896] [192, 210) 'eventmask'
[ 33.067338][ T1896] [256, 512) 'buf'
[ 33.067742][ T1896]
[ 33.068304][ T1896] Memory state around the buggy address:
[ 33.068838][ T1896] ffffc90001d6ee80: f2 00 00 02 f2 f2 f2 f2 f2 00 00 00 00 00 00 00
[ 33.069545][ T1896] ffffc90001d6ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 33.070626][ T1896] >ffffc90001d6ef80: 00 00 00 00 00 00 00 00 00 f3 f3 f3 f3 f3 f3 f3
[ 33.072052][ T1896] ^
[ 33.073043][ T1896] ffffc90001d6f000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 33.074230][ T1896] ffffc90001d6f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 33.074914][ T1896] ==================================================================
[ 33.075713][ T1896] Disabling lock debugging due to kernel taint
Reviewed-by: Arend van Spriel<arend.vanspriel@broadcom.com>
Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221230075139.56591-1-jisoo.jang@yonsei.ac.kr
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit e7fcfe67f9f410736b758969477b17ea285e8e6c ]
The return value from the call to intel_tcc_get_tjmax() is int, which can
be a negative error code. However, the return value is being assigned to
an u32 variable 'tj_max', so making 'tj_max' an int.
Eliminate the following warning:
./drivers/thermal/intel/intel_soc_dts_iosf.c:394:5-11: WARNING: Unsigned expression compared with zero: tj_max < 0
Link: https://bugzilla.openanolis.cn/show_bug.cgi?id=3637
Reported-by: Abaci Robot <abaci@linux.alibaba.com>
Signed-off-by: Yang Li <yang.lee@linux.alibaba.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 0a06cadcc2a0044e4a117cc0e61436fc3a0dad69 ]
This patch fixes a stack-out-of-bounds read in brcmfmac that occurs
when 'buf' that is not null-terminated is passed as an argument of
strsep() in brcmf_c_preinit_dcmds(). This buffer is filled with a firmware
version string by memcpy() in brcmf_fil_iovar_data_get().
The patch ensures buf is null-terminated.
Found by a modified version of syzkaller.
[ 47.569679][ T1897] brcmfmac: brcmf_fw_alloc_request: using brcm/brcmfmac43236b for chip BCM43236/3
[ 47.582839][ T1897] brcmfmac: brcmf_c_process_clm_blob: no clm_blob available (err=-2), device may have limited channels available
[ 47.601565][ T1897] ==================================================================
[ 47.602574][ T1897] BUG: KASAN: stack-out-of-bounds in strsep+0x1b2/0x1f0
[ 47.603447][ T1897] Read of size 1 at addr ffffc90001f6f000 by task kworker/0:2/1897
[ 47.604336][ T1897]
[ 47.604621][ T1897] CPU: 0 PID: 1897 Comm: kworker/0:2 Tainted: G O 5.14.0+ #131
[ 47.605617][ T1897] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
[ 47.606907][ T1897] Workqueue: usb_hub_wq hub_event
[ 47.607453][ T1897] Call Trace:
[ 47.607801][ T1897] dump_stack_lvl+0x8e/0xd1
[ 47.608295][ T1897] print_address_description.constprop.0.cold+0xf/0x334
[ 47.609009][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609434][ T1897] ? strsep+0x1b2/0x1f0
[ 47.609863][ T1897] kasan_report.cold+0x83/0xdf
[ 47.610366][ T1897] ? strsep+0x1b2/0x1f0
[ 47.610882][ T1897] strsep+0x1b2/0x1f0
[ 47.611300][ T1897] ? brcmf_fil_iovar_data_get+0x3a/0xf0
[ 47.611883][ T1897] brcmf_c_preinit_dcmds+0x995/0xc40
[ 47.612434][ T1897] ? brcmf_c_set_joinpref_default+0x100/0x100
[ 47.613078][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 47.613662][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 47.614208][ T1897] ? lock_acquire+0x19d/0x4e0
[ 47.614704][ T1897] ? find_held_lock+0x2d/0x110
[ 47.615236][ T1897] ? brcmf_usb_deq+0x1a7/0x260
[ 47.615741][ T1897] ? brcmf_usb_rx_fill_all+0x5a/0xf0
[ 47.616288][ T1897] brcmf_attach+0x246/0xd40
[ 47.616758][ T1897] ? wiphy_new_nm+0x1703/0x1dd0
[ 47.617280][ T1897] ? kmemdup+0x43/0x50
[ 47.617720][ T1897] brcmf_usb_probe+0x12de/0x1690
[ 47.618244][ T1897] ? brcmf_usbdev_qinit.constprop.0+0x470/0x470
[ 47.618901][ T1897] usb_probe_interface+0x2aa/0x760
[ 47.619429][ T1897] ? usb_probe_device+0x250/0x250
[ 47.619950][ T1897] really_probe+0x205/0xb70
[ 47.620435][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.621048][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.621595][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.622209][ T1897] driver_probe_device+0x4e/0x150
[ 47.622739][ T1897] __device_attach_driver+0x1cc/0x2a0
[ 47.623287][ T1897] bus_for_each_drv+0x156/0x1d0
[ 47.623796][ T1897] ? bus_rescan_devices+0x30/0x30
[ 47.624309][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.624907][ T1897] ? trace_hardirqs_on+0x46/0x160
[ 47.625437][ T1897] __device_attach+0x23f/0x3a0
[ 47.625924][ T1897] ? device_bind_driver+0xd0/0xd0
[ 47.626433][ T1897] ? kobject_uevent_env+0x287/0x14b0
[ 47.627057][ T1897] bus_probe_device+0x1da/0x290
[ 47.627557][ T1897] device_add+0xb7b/0x1eb0
[ 47.628027][ T1897] ? wait_for_completion+0x290/0x290
[ 47.628593][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0
[ 47.629249][ T1897] usb_set_configuration+0xf59/0x16f0
[ 47.629829][ T1897] usb_generic_driver_probe+0x82/0xa0
[ 47.630385][ T1897] usb_probe_device+0xbb/0x250
[ 47.630927][ T1897] ? usb_suspend+0x590/0x590
[ 47.631397][ T1897] really_probe+0x205/0xb70
[ 47.631855][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.632469][ T1897] __driver_probe_device+0x311/0x4b0
[ 47.633002][ T1897] ? usb_generic_driver_match+0x75/0x90
[ 47.633573][ T1897] ? driver_allows_async_probing+0x130/0x130
[ 47.634170][ T1897] driver_probe_device+0x4e/0x150
[ 47.634703][ T1897] __device_attach_driver+0x1cc/0x2a0
[ 47.635248][ T1897] bus_for_each_drv+0x156/0x1d0
[ 47.635748][ T1897] ? bus_rescan_devices+0x30/0x30
[ 47.636271][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.636881][ T1897] ? trace_hardirqs_on+0x46/0x160
[ 47.637396][ T1897] __device_attach+0x23f/0x3a0
[ 47.637904][ T1897] ? device_bind_driver+0xd0/0xd0
[ 47.638426][ T1897] ? kobject_uevent_env+0x287/0x14b0
[ 47.638985][ T1897] bus_probe_device+0x1da/0x290
[ 47.639512][ T1897] device_add+0xb7b/0x1eb0
[ 47.639977][ T1897] ? __fw_devlink_link_to_suppliers+0x5a0/0x5a0
[ 47.640612][ T1897] ? kfree+0x14a/0x6b0
[ 47.641055][ T1897] ? __usb_get_extra_descriptor+0x116/0x160
[ 47.641679][ T1897] usb_new_device.cold+0x49c/0x1029
[ 47.642245][ T1897] ? hub_disconnect+0x450/0x450
[ 47.642756][ T1897] ? rwlock_bug.part.0+0x90/0x90
[ 47.643273][ T1897] ? _raw_spin_unlock_irq+0x24/0x30
[ 47.643822][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.644445][ T1897] hub_event+0x1c98/0x3950
[ 47.644939][ T1897] ? hub_port_debounce+0x2e0/0x2e0
[ 47.645467][ T1897] ? check_irq_usage+0x861/0xf20
[ 47.645975][ T1897] ? drain_workqueue+0x280/0x360
[ 47.646506][ T1897] ? lock_release+0x640/0x640
[ 47.646994][ T1897] ? rcu_read_lock_sched_held+0xa1/0xd0
[ 47.647572][ T1897] ? rcu_read_lock_bh_held+0xb0/0xb0
[ 47.648111][ T1897] ? lockdep_hardirqs_on_prepare+0x273/0x3e0
[ 47.648735][ T1897] process_one_work+0x92b/0x1460
[ 47.649262][ T1897] ? pwq_dec_nr_in_flight+0x330/0x330
[ 47.649816][ T1897] ? rwlock_bug.part.0+0x90/0x90
[ 47.650336][ T1897] worker_thread+0x95/0xe00
[ 47.650830][ T1897] ? __kthread_parkme+0x115/0x1e0
[ 47.651361][ T1897] ? process_one_work+0x1460/0x1460
[ 47.651904][ T1897] kthread+0x3a1/0x480
[ 47.652329][ T1897] ? set_kthread_struct+0x120/0x120
[ 47.652878][ T1897] ret_from_fork+0x1f/0x30
[ 47.653370][ T1897]
[ 47.653608][ T1897]
[ 47.653848][ T1897] addr ffffc90001f6f000 is located in stack of task kworker/0:2/1897 at offset 512 in frame:
[ 47.654891][ T1897] brcmf_c_preinit_dcmds+0x0/0xc40
[ 47.655442][ T1897]
[ 47.655690][ T1897] this frame has 4 objects:
[ 47.656151][ T1897] [48, 56) 'ptr'
[ 47.656159][ T1897] [80, 148) 'revinfo'
[ 47.656534][ T1897] [192, 210) 'eventmask'
[ 47.656953][ T1897] [256, 512) 'buf'
[ 47.657410][ T1897]
[ 47.658035][ T1897] Memory state around the buggy address:
[ 47.658743][ T1897] ffffc90001f6ef00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 47.659577][ T1897] ffffc90001f6ef80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 47.660394][ T1897] >ffffc90001f6f000: f3 f3 f3 f3 f3 f3 f3 f3 00 00 00 00 00 00 00 00
[ 47.661199][ T1897] ^
[ 47.661625][ T1897] ffffc90001f6f080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 47.662455][ T1897] ffffc90001f6f100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f1 f1
[ 47.663318][ T1897] ==================================================================
[ 47.664147][ T1897] Disabling lock debugging due to kernel taint
Reported-by: Dokyung Song <dokyungs@yonsei.ac.kr>
Reported-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Reported-by: Minsuk Kang <linuxlovemin@yonsei.ac.kr>
Signed-off-by: Jisoo Jang <jisoo.jang@yonsei.ac.kr>
Signed-off-by: Kalle Valo <kvalo@kernel.org>
Link: https://lore.kernel.org/r/20221115043458.37562-1-jisoo.jang@yonsei.ac.kr
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 3e74ec2f39362bffbd42854acbb67c7f4cb808f9 ]
In the event that an intent advertisement arrives on an unknown channel
the fifo is not advanced, resulting in the same message being handled
over and over.
Fixes: dacbb35e930f ("rpmsg: glink: Receive and store the remote intent buffers")
Signed-off-by: Bjorn Andersson <quic_bjorande@quicinc.com>
Reviewed-by: Chris Lew <quic_clew@quicinc.com>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230214234231.2069751-1-quic_bjorande@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit ebad8e731c1c06adf04621d6fd327b860c0861b5 ]
There are UAF bugs caused by do_submit_urb(). One of the KASan reports
is shown below:
[ 36.403605] BUG: KASAN: use-after-free in worker_thread+0x4a2/0x890
[ 36.406105] Read of size 8 at addr ffff8880059600e8 by task kworker/0:2/49
[ 36.408316]
[ 36.408867] CPU: 0 PID: 49 Comm: kworker/0:2 Not tainted 6.2.0-rc3-15798-g5a41237ad1d4-dir8
[ 36.411696] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584
[ 36.416157] Workqueue: 0x0 (events)
[ 36.417654] Call Trace:
[ 36.418546] <TASK>
[ 36.419320] dump_stack_lvl+0x96/0xd0
[ 36.420522] print_address_description+0x75/0x350
[ 36.421992] print_report+0x11b/0x250
[ 36.423174] ? _raw_spin_lock_irqsave+0x87/0xd0
[ 36.424806] ? __virt_addr_valid+0xcf/0x170
[ 36.426069] ? worker_thread+0x4a2/0x890
[ 36.427355] kasan_report+0x131/0x160
[ 36.428556] ? worker_thread+0x4a2/0x890
[ 36.430053] worker_thread+0x4a2/0x890
[ 36.431297] ? worker_clr_flags+0x90/0x90
[ 36.432479] kthread+0x166/0x190
[ 36.433493] ? kthread_blkcg+0x50/0x50
[ 36.434669] ret_from_fork+0x22/0x30
[ 36.435923] </TASK>
[ 36.436684]
[ 36.437215] Allocated by task 24:
[ 36.438289] kasan_set_track+0x50/0x80
[ 36.439436] __kasan_kmalloc+0x89/0xa0
[ 36.440566] smsusb_probe+0x374/0xc90
[ 36.441920] usb_probe_interface+0x2d1/0x4c0
[ 36.443253] really_probe+0x1d5/0x580
[ 36.444539] __driver_probe_device+0xe3/0x130
[ 36.446085] driver_probe_device+0x49/0x220
[ 36.447423] __device_attach_driver+0x19e/0x1b0
[ 36.448931] bus_for_each_drv+0xcb/0x110
[ 36.450217] __device_attach+0x132/0x1f0
[ 36.451470] bus_probe_device+0x59/0xf0
[ 36.452563] device_add+0x4ec/0x7b0
[ 36.453830] usb_set_configuration+0xc63/0xe10
[ 36.455230] usb_generic_driver_probe+0x3b/0x80
[ 36.456166] printk: console [ttyGS0] disabled
[ 36.456569] usb_probe_device+0x90/0x110
[ 36.459523] really_probe+0x1d5/0x580
[ 36.461027] __driver_probe_device+0xe3/0x130
[ 36.462465] driver_probe_device+0x49/0x220
[ 36.463847] __device_attach_driver+0x19e/0x1b0
[ 36.465229] bus_for_each_drv+0xcb/0x110
[ 36.466466] __device_attach+0x132/0x1f0
[ 36.467799] bus_probe_device+0x59/0xf0
[ 36.469010] device_add+0x4ec/0x7b0
[ 36.470125] usb_new_device+0x863/0xa00
[ 36.471374] hub_event+0x18c7/0x2220
[ 36.472746] process_one_work+0x34c/0x5b0
[ 36.474041] worker_thread+0x4b7/0x890
[ 36.475216] kthread+0x166/0x190
[ 36.476267] ret_from_fork+0x22/0x30
[ 36.477447]
[ 36.478160] Freed by task 24:
[ 36.479239] kasan_set_track+0x50/0x80
[ 36.480512] kasan_save_free_info+0x2b/0x40
[ 36.481808] ____kasan_slab_free+0x122/0x1a0
[ 36.483173] __kmem_cache_free+0xc4/0x200
[ 36.484563] smsusb_term_device+0xcd/0xf0
[ 36.485896] smsusb_probe+0xc85/0xc90
[ 36.486976] usb_probe_interface+0x2d1/0x4c0
[ 36.488303] really_probe+0x1d5/0x580
[ 36.489498] __driver_probe_device+0xe3/0x130
[ 36.491140] driver_probe_device+0x49/0x220
[ 36.492475] __device_attach_driver+0x19e/0x1b0
[ 36.493988] bus_for_each_drv+0xcb/0x110
[ 36.495171] __device_attach+0x132/0x1f0
[ 36.496617] bus_probe_device+0x59/0xf0
[ 36.497875] device_add+0x4ec/0x7b0
[ 36.498972] usb_set_configuration+0xc63/0xe10
[ 36.500264] usb_generic_driver_probe+0x3b/0x80
[ 36.501740] usb_probe_device+0x90/0x110
[ 36.503084] really_probe+0x1d5/0x580
[ 36.504241] __driver_probe_device+0xe3/0x130
[ 36.505548] driver_probe_device+0x49/0x220
[ 36.506766] __device_attach_driver+0x19e/0x1b0
[ 36.508368] bus_for_each_drv+0xcb/0x110
[ 36.509646] __device_attach+0x132/0x1f0
[ 36.510911] bus_probe_device+0x59/0xf0
[ 36.512103] device_add+0x4ec/0x7b0
[ 36.513215] usb_new_device+0x863/0xa00
[ 36.514736] hub_event+0x18c7/0x2220
[ 36.516130] process_one_work+0x34c/0x5b0
[ 36.517396] worker_thread+0x4b7/0x890
[ 36.518591] kthread+0x166/0x190
[ 36.519599] ret_from_fork+0x22/0x30
[ 36.520851]
[ 36.521405] Last potentially related work creation:
[ 36.523143] kasan_save_stack+0x3f/0x60
[ 36.524275] kasan_record_aux_stack_noalloc+0x9d/0xb0
[ 36.525831] insert_work+0x25/0x130
[ 36.527039] __queue_work+0x4d4/0x620
[ 36.528236] queue_work_on+0x72/0xb0
[ 36.529344] __usb_hcd_giveback_urb+0x13f/0x1b0
[ 36.530819] dummy_timer+0x350/0x1a40
[ 36.532149] call_timer_fn+0x2c/0x190
[ 36.533567] expire_timers+0x69/0x1f0
[ 36.534736] __run_timers+0x289/0x2d0
[ 36.535841] run_timer_softirq+0x2d/0x60
[ 36.537110] __do_softirq+0x116/0x380
[ 36.538377]
[ 36.538950] Second to last potentially related work creation:
[ 36.540855] kasan_save_stack+0x3f/0x60
[ 36.542084] kasan_record_aux_stack_noalloc+0x9d/0xb0
[ 36.543592] insert_work+0x25/0x130
[ 36.544891] __queue_work+0x4d4/0x620
[ 36.546168] queue_work_on+0x72/0xb0
[ 36.547328] __usb_hcd_giveback_urb+0x13f/0x1b0
[ 36.548805] dummy_timer+0x350/0x1a40
[ 36.550116] call_timer_fn+0x2c/0x190
[ 36.551570] expire_timers+0x69/0x1f0
[ 36.552762] __run_timers+0x289/0x2d0
[ 36.553916] run_timer_softirq+0x2d/0x60
[ 36.555118] __do_softirq+0x116/0x380
[ 36.556239]
[ 36.556807] The buggy address belongs to the object at ffff888005960000
[ 36.556807] which belongs to the cache kmalloc-4k of size 4096
[ 36.560652] The buggy address is located 232 bytes inside of
[ 36.560652] 4096-byte region [ffff888005960000, ffff888005961000)
[ 36.564791]
[ 36.565355] The buggy address belongs to the physical page:
[ 36.567212] page:000000004f0a0731 refcount:1 mapcount:0 mapping:0000000000000000 index:0x00
[ 36.570534] head:000000004f0a0731 order:3 compound_mapcount:0 subpages_mapcount:0 compound0
[ 36.573717] flags: 0x100000000010200(slab|head|node=0|zone=1)
[ 36.575481] raw: 0100000000010200 ffff888001042140 dead000000000122 0000000000000000
[ 36.577842] raw: 0000000000000000 0000000000040004 00000001ffffffff 0000000000000000
[ 36.580175] page dumped because: kasan: bad access detected
[ 36.581994]
[ 36.582548] Memory state around the buggy address:
[ 36.583983] ffff88800595ff80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[ 36.586240] ffff888005960000: fa fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 36.588884] >ffff888005960080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 36.591071] ^
[ 36.593295] ffff888005960100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 36.595705] ffff888005960180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
[ 36.598026] ==================================================================
[ 36.600224] Disabling lock debugging due to kernel taint
[ 36.602681] general protection fault, probably for non-canonical address 0x43600a000000060I
[ 36.607129] CPU: 0 PID: 49 Comm: kworker/0:2 Tainted: G B 6.2.0-rc3-15798-8
[ 36.611115] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g15584
[ 36.615026] Workqueue: events do_submit_urb
[ 36.616290] RIP: 0010:_raw_spin_lock_irqsave+0x8a/0xd0
[ 36.618107] Code: 24 00 00 00 00 48 89 df be 04 00 00 00 e8 9e b5 c6 fe 48 89 ef be 04 00 5
[ 36.623522] RSP: 0018:ffff888004b6fcf0 EFLAGS: 00010046
[ 36.625072] RAX: 0000000000000000 RBX: 043600a000000060 RCX: ffffffff9fc0e0d7
[ 36.627206] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff888004b6fcf0
[ 36.629813] RBP: ffff888004b6fcf0 R08: dffffc0000000000 R09: ffffed100096df9f
[ 36.631974] R10: dfffe9100096dfa0 R11: 1ffff1100096df9e R12: ffff888005960020
[ 36.634285] R13: ffff8880059600f0 R14: 0000000000000246 R15: 0000000000000001
[ 36.636438] FS: 0000000000000000(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
[ 36.639092] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 36.640951] CR2: 00007f07476819a3 CR3: 0000000004a34000 CR4: 00000000000006f0
[ 36.643411] Call Trace:
[ 36.644215] <TASK>
[ 36.644902] smscore_getbuffer+0x3e/0x1e0
[ 36.646147] do_submit_urb+0x4f/0x190
[ 36.647449] process_one_work+0x34c/0x5b0
[ 36.648777] worker_thread+0x4b7/0x890
[ 36.649984] ? worker_clr_flags+0x90/0x90
[ 36.651166] kthread+0x166/0x190
[ 36.652151] ? kthread_blkcg+0x50/0x50
[ 36.653547] ret_from_fork+0x22/0x30
[ 36.655051] </TASK>
[ 36.655733] Modules linked in:
[ 36.656787] ---[ end trace 0000000000000000 ]---
[ 36.658328] RIP: 0010:_raw_spin_lock_irqsave+0x8a/0xd0
[ 36.660045] Code: 24 00 00 00 00 48 89 df be 04 00 00 00 e8 9e b5 c6 fe 48 89 ef be 04 00 5
[ 36.665730] RSP: 0018:ffff888004b6fcf0 EFLAGS: 00010046
[ 36.667448] RAX: 0000000000000000 RBX: 043600a000000060 RCX: ffffffff9fc0e0d7
[ 36.669675] RDX: 0000000000000000 RSI: dffffc0000000000 RDI: ffff888004b6fcf0
[ 36.672645] RBP: ffff888004b6fcf0 R08: dffffc0000000000 R09: ffffed100096df9f
[ 36.674921] R10: dfffe9100096dfa0 R11: 1ffff1100096df9e R12: ffff888005960020
[ 36.677034] R13: ffff8880059600f0 R14: 0000000000000246 R15: 0000000000000001
[ 36.679184] FS: 0000000000000000(0000) GS:ffff88806d600000(0000) knlGS:0000000000000000
[ 36.681655] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 36.683383] CR2: 00007f07476819a3 CR3: 0000000004a34000 CR4: 00000000000006f0
[ 36.685733] Kernel panic - not syncing: Fatal exception
[ 36.688585] Kernel Offset: 0x1d400000 from 0xffffffff81000000 (relocation range: 0xfffffff)
[ 36.692199] ---[ end Kernel panic - not syncing: Fatal exception ]---
When the siano device is plugged in, it may call the following functions
to initialize the device.
smsusb_probe()-->smsusb_init_device()-->smscore_start_device().
When smscore_start_device() gets failed, the function smsusb_term_device()
will be called and smsusb_device_t will be deallocated. Although we use
usb_kill_urb() in smsusb_stop_streaming() to cancel transfer requests
and wait for them to finish, the worker threads that are scheduled by
smsusb_onresponse() may be still running. As a result, the UAF bugs
could happen.
We add cancel_work_sync() in smsusb_stop_streaming() in order that the
worker threads could finish before the smsusb_device_t is deallocated.
Fixes: dd47fbd40e6e ("[media] smsusb: don't sleep while atomic")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 6a4c664539e6de9b32b65ddcf767ec1bcc1d7f8a ]
If the media bus is unsupported, then return -EINVAL. Instead it
returned 'ret' which happened to be 0.
This fixes a smatch warning:
ov7670.c:1843 ov7670_parse_dt() warn: missing error code? 'ret'
Signed-off-by: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Fixes: 01b8444828fc ("media: v4l2: i2c: ov7670: Implement OF mbus configuration")
Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 29b0589a865b6f66d141d79b2dd1373e4e50fe17 ]
When the ene device is detaching, function ene_remove() will
be called. But there is no function to cancel tx_sim_timer
in ene_remove(), the timer handler ene_tx_irqsim() could race
with ene_remove(). As a result, the UAF bugs could happen,
the process is shown below.
(cleanup routine) | (timer routine)
| mod_timer(&dev->tx_sim_timer, ..)
ene_remove() | (wait a time)
| ene_tx_irqsim()
| dev->hw_lock //USE
| ene_tx_sample(dev) //USE
Fix by adding del_timer_sync(&dev->tx_sim_timer) in ene_remove(),
The tx_sim_timer could stop before ene device is deallocated.
What's more, The rc_unregister_device() and del_timer_sync()
should be called first in ene_remove() and the deallocated
functions such as free_irq(), release_region() and so on
should be called behind them. Because the rc_unregister_device()
is well synchronized. Otherwise, race conditions may happen. The
situations that may lead to race conditions are shown below.
Firstly, the rx receiver is disabled with ene_rx_disable()
before rc_unregister_device() in ene_remove(), which means it
can be enabled again if a process opens /dev/lirc0 between
ene_rx_disable() and rc_unregister_device().
Secondly, the irqaction descriptor is freed by free_irq()
before the rc device is unregistered, which means irqaction
descriptor may be accessed again after it is deallocated.
Thirdly, the timer can call ene_tx_sample() that can write
to the io ports, which means the io ports could be accessed
again after they are deallocated by release_region().
Therefore, the rc_unregister_device() and del_timer_sync()
should be called first in ene_remove().
Suggested by: Sean Young <sean@mess.org>
Fixes: 9ea53b74df9c ("V4L/DVB: STAGING: remove lirc_ene0100 driver")
Signed-off-by: Duoming Zhou <duoming@zju.edu.cn>
Signed-off-by: Sean Young <sean@mess.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 7485edb2b6ca5960205c0a49bedfd09bba30e521 ]
A memory leak was reported when testing ov772x with bpf mock device:
AssertionError: unreferenced object 0xffff888109afa7a8 (size 8):
comm "python3", pid 279, jiffies 4294805921 (age 20.681s)
hex dump (first 8 bytes):
80 22 88 15 81 88 ff ff ."......
backtrace:
[<000000009990b438>] __kmalloc_node+0x44/0x1b0
[<000000009e32f7d7>] kvmalloc_node+0x34/0x180
[<00000000faf48134>] v4l2_ctrl_handler_init_class+0x11d/0x180 [videodev]
[<00000000da376937>] ov772x_probe+0x1c3/0x68c [ov772x]
[<000000003f0d225e>] i2c_device_probe+0x28d/0x680
[<00000000e0b6db89>] really_probe+0x17c/0x3f0
[<000000001b19fcee>] __driver_probe_device+0xe3/0x170
[<0000000048370519>] driver_probe_device+0x49/0x120
[<000000005ead07a0>] __device_attach_driver+0xf7/0x150
[<0000000043f452b8>] bus_for_each_drv+0x114/0x180
[<00000000358e5596>] __device_attach+0x1e5/0x2d0
[<0000000043f83c5d>] bus_probe_device+0x126/0x140
[<00000000ee0f3046>] device_add+0x810/0x1130
[<00000000e0278184>] i2c_new_client_device+0x359/0x4f0
[<0000000070baf34f>] of_i2c_register_device+0xf1/0x110
[<00000000a9f2159d>] of_i2c_notify+0x100/0x160
unreferenced object 0xffff888119825c00 (size 256):
comm "python3", pid 279, jiffies 4294805921 (age 20.681s)
hex dump (first 32 bytes):
00 b4 a5 17 81 88 ff ff 00 5e 82 19 81 88 ff ff .........^......
10 5c 82 19 81 88 ff ff 10 5c 82 19 81 88 ff ff .\.......\......
backtrace:
[<000000009990b438>] __kmalloc_node+0x44/0x1b0
[<000000009e32f7d7>] kvmalloc_node+0x34/0x180
[<0000000073d88e0b>] v4l2_ctrl_new.cold+0x19b/0x86f [videodev]
[<00000000b1f576fb>] v4l2_ctrl_new_std+0x16f/0x210 [videodev]
[<00000000caf7ac99>] ov772x_probe+0x1fa/0x68c [ov772x]
[<000000003f0d225e>] i2c_device_probe+0x28d/0x680
[<00000000e0b6db89>] really_probe+0x17c/0x3f0
[<000000001b19fcee>] __driver_probe_device+0xe3/0x170
[<0000000048370519>] driver_probe_device+0x49/0x120
[<000000005ead07a0>] __device_attach_driver+0xf7/0x150
[<0000000043f452b8>] bus_for_each_drv+0x114/0x180
[<00000000358e5596>] __device_attach+0x1e5/0x2d0
[<0000000043f83c5d>] bus_probe_device+0x126/0x140
[<00000000ee0f3046>] device_add+0x810/0x1130
[<00000000e0278184>] i2c_new_client_device+0x359/0x4f0
[<0000000070baf34f>] of_i2c_register_device+0xf1/0x110
The reason is that if priv->hdl.error is set, ov772x_probe() jumps to the
error_mutex_destroy without doing v4l2_ctrl_handler_free(), and all
resources allocated in v4l2_ctrl_handler_init() and v4l2_ctrl_new_std()
are leaked.
Fixes: 1112babde214 ("media: i2c: Copy ov772x soc_camera sensor driver")
Signed-off-by: Yuan Can <yuancan@huawei.com>
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit dd74ed6c213003533e3abf4c204374ef01d86978 ]
There is a kmemleak when testing the media/i2c/ov5675.c with bpf mock
device:
AssertionError: unreferenced object 0xffff888107362160 (size 16):
comm "python3", pid 277, jiffies 4294832798 (age 20.722s)
hex dump (first 16 bytes):
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
backtrace:
[<00000000abe7d67c>] __kmalloc_node+0x44/0x1b0
[<000000008a725aac>] kvmalloc_node+0x34/0x180
[<000000009a53cd11>] v4l2_ctrl_handler_init_class+0x11d/0x180
[videodev]
[<0000000055b46db0>] ov5675_probe+0x38b/0x897 [ov5675]
[<00000000153d886c>] i2c_device_probe+0x28d/0x680
[<000000004afb7e8f>] really_probe+0x17c/0x3f0
[<00000000ff2f18e4>] __driver_probe_device+0xe3/0x170
[<000000000a001029>] driver_probe_device+0x49/0x120
[<00000000e39743c7>] __device_attach_driver+0xf7/0x150
[<00000000d32fd070>] bus_for_each_drv+0x114/0x180
[<000000009083ac41>] __device_attach+0x1e5/0x2d0
[<0000000015b4a830>] bus_probe_device+0x126/0x140
[<000000007813deaf>] device_add+0x810/0x1130
[<000000007becb867>] i2c_new_client_device+0x386/0x540
[<000000007f9cf4b4>] of_i2c_register_device+0xf1/0x110
[<00000000ebfdd032>] of_i2c_notify+0xfc/0x1f0
ov5675_init_controls() won't clean all the allocated resources in fail
path, which may causes the memleaks. Add v4l2_ctrl_handler_free() to
prevent memleak.
Fixes: bf27502b1f3b ("media: ov5675: Add support for OV5675 sensor")
Signed-off-by: Shang XiaoJing <shangxiaojing@huawei.com>
Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit da8e05f84a11c3cc3b0ba0a3c62d20e358002d99 ]
Add check for the return value of devm_regulator_get since it may return
error pointer.
Fixes: 448de7e7850b ("[media] omap3isp: OMAP3 ISP core")
Signed-off-by: Jiasheng Jiang <jiasheng@iscas.ac.cn>
Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 57f72170a2b2a362c35bb9407fc844eac5afdec1 ]
Any access to the dynamically allocated metadata region by the application
processor after assigning it to the remote Q6 will result in a XPU
violation. Fix this by replacing the dynamically allocated memory region
with a no-map carveout and unmap the modem metadata memory region before
passing control to the remote Q6.
Reported-and-tested-by: Amit Pundir <amit.pundir@linaro.org>
Fixes: 6c5a9dc2481b ("remoteproc: qcom: Make secure world call for mem ownership switch")
Signed-off-by: Sibi Sankar <quic_sibis@quicinc.com>
Reviewed-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230117085840.32356-7-quic_sibis@quicinc.com
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit 79200d5851c8e7179f68a4a6f162d8f1bde4986f ]
In the previous commits that added CLK_OPS_PARENT_ENABLE, support for
this flag was only added to rate change operations (rate setting and
reparent) and disabling unused subtree. It was not added to the
clock gate related operations. Any hardware driver that needs it for
these operations will either see bogus results, or worse, hang.
This has been seen on MT8192 and MT8195, where the imp_ii2_* clk
drivers set this, but dumping debugfs clk_summary would cause it
to hang.
Prepare parent on prepare and enable parent on enable dependencies are
already handled automatically by the core as part of its sequencing.
Whether the case for "enable parent on prepare" should be supported by
this flag or not is not clear, and thus ignored for now.
This change solely fixes the handling of clk_core_is_enabled, i.e.
enabling the parent clock when reading the hardware state. Unfortunately
clk_core_is_enabled is called in a variety of places, sometimes with
the enable clock already held. To avoid deadlocking, the core will
ignore readouts and just return false if CLK_OPS_PARENT_ENABLE is set
but the parent isn't currently enabled.
Fixes: fc8726a2c021 ("clk: core: support clocks which requires parents enable (part 2)")
Fixes: a4b3518d146f ("clk: core: support clocks which requires parents enable (part 1)")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20230103092330.494102-1-wenst@chromium.org
Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
|
[ Upstream commit cb81719e3c1165ef1bc33137dc628f750eed8ea4 ]
The gdsc_init() function will rewrite the CLK_DIS_WAIT field while
registering the GDSC (writing the value 0x2 by default). This will
override the setting done in the driver's probe function.
Set cx_gdsc.clk_dis_wait_val to 8 to follow the intention of the probe
function.
Fixes: 453361cdd757 ("clk: qcom: Add graphics clock controller driver for SDM845")
Reviewed-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Link: https://lore.kernel.org/r/20230201172305.993146-2-dmitry.baryshkov@linaro.org
Signed-off-by: Sasha Levin <sashal@kernel.org>
|
