- Jun 09, 2023
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20230607200900.915613242@linuxfoundation.org Tested-by:
Florian Fainelli <florian.fainelli@broadcom.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Chris Paterson (CIP) <chris.paterson2@renesas.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Salvatore Bonaccorso <carnil@debian.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Sudip Mukherjee <sudip.mukherjee@codethink.co.uk> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Arnd Bergmann authored
commit 1441a15d upstream. This is now a hidden symbol, so just drop the defconfig line. Fixes: 42d95d1b ("drm/rcar: stop using 'imply' for dependencies") Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Signed-off-by:
-
Theodore Ts'o authored
commit eb1f822c upstream. In commit a44be64b ("ext4: don't clear SB_RDONLY when remounting r/w until quota is re-enabled") we defer clearing tyhe SB_RDONLY flag in struct super. However, we didn't defer when we checked sb_rdonly() to determine the lazy itable init thread should be enabled, with the next result that the lazy inode table initialization would not be properly started. This can cause generic/231 to fail in ext4's nojournal mode. Fix this by moving when we decide to start or stop the lazy itable init thread to after we clear the SB_RDONLY flag when we are remounting the file system read/write. Fixes a44be64b ("ext4: don't clear SB_RDONLY when remounting r/w until...") Signed-off-by:
Theodore Ts'o <tytso@mit.edu> Link: https://lore.kernel.org/r/20230527035729.1001605-1-tytso@mit.edu Signed-off-by:
-
Matthieu Baerts authored
commit 715c78a8 upstream. Selftests are supposed to run on any kernels, including the old ones not supporting MPTCP. A new check is then added to make sure MPTCP is supported. If not, the test stops and is marked as "skipped". Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: b08fbf24 ("selftests: add test-cases for MPTCP MP_JOIN") Cc: stable@vger.kernel.org Acked-by:
Paolo Abeni <pabeni@redhat.com> Signed-off-by:
Matthieu Baerts <matthieu.baerts@tessares.net> Signed-off-by:
-
Matthieu Baerts authored
commit 9161f21c upstream. Selftests are supposed to run on any kernels, including the old ones not supporting MPTCP. A new check is then added to make sure MPTCP is supported. If not, the test stops and is marked as "skipped". Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: 1a418cb8 ("mptcp: simult flow self-tests") Cc: stable@vger.kernel.org Acked-by:
-
Matthieu Baerts authored
commit 46565acd upstream. Selftests are supposed to run on any kernels, including the old ones not supporting MPTCP. A new check is then added to make sure MPTCP is supported. If not, the test stops and is marked as "skipped". Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: df62f2ec ("selftests/mptcp: add diag interface tests") Cc: stable@vger.kernel.org Acked-by:
-
Sean Christopherson authored
commit 8347b994 upstream. Copy the incoming @data comman to an internal buffer so that callers can put SEV command buffers on the stack without running afoul of CONFIG_VMAP_STACK=y, i.e. without bombing on vmalloc'd pointers. As of today, the largest supported command takes a 68 byte buffer, i.e. pretty much every command can be put on the stack. Because sev_cmd_mutex is held for the entirety of a transaction, only a single bounce buffer is required. Use the internal buffer unconditionally, as the majority of in-kernel users will soon switch to using the stack. At that point, checking virt_addr_valid() becomes (negligible) overhead in most cases, and supporting both paths slightly increases complexity. Since the commands are all quite small, the cost of the copies is insignificant compared to the latency of communicating with the PSP. Allocate a full page for the buffer as opportunistic preparation for SEV-SNP, which requires the command buffer to be in firmware state for commands that trigger memory writes from the PSP firmware. Using a full page now will allow SEV-SNP support to simply transition the page as needed. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Borislav Petkov <bp@suse.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
Sean Christopherson <seanjc@google.com> Message-Id: <20210406224952.4177376-5-seanjc@google.com> Reviewed-by:
Brijesh Singh <brijesh.singh@amd.com> Acked-by:
Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
Paolo Bonzini <pbonzini@redhat.com> Cc: Ben Hutchings <benh@debian.org> Signed-off-by:
-
Sean Christopherson authored
commit d5760dee upstream. WARN on and reject SEV commands that provide a valid data pointer, but do not have a known, non-zero length. And conversely, reject commands that take a command buffer but none is provided (data is null). Aside from sanity checking input, disallowing a non-null pointer without a non-zero size will allow a future patch to cleanly handle vmalloc'd data by copying the data to an internal __pa() friendly buffer. Note, this also effectively prevents callers from using commands that have a non-zero length and are not known to the kernel. This is not an explicit goal, but arguably the side effect is a good thing from the kernel's perspective. Cc: Brijesh Singh <brijesh.singh@amd.com> Cc: Borislav Petkov <bp@suse.de> Cc: Tom Lendacky <thomas.lendacky@amd.com> Signed-off-by:
-
Ben Hutchings authored
adpt_isr() reads reply addresses from a hardware register, which should always be within the DMA address range of the device's pool of reply address buffers. In case the address is out of range, it tries to muddle on, converting to a virtual address using bus_to_virt(). bus_to_virt() does not take DMA addresses, and it doesn't make sense to try to handle the completion in this case. Ignore it and continue looping to service the interrupt. If a completion has been lost then the SCSI core should eventually time-out and trigger a reset. There is no corresponding upstream commit, because this driver was removed upstream. Fixes: 67af2b06 ("[SCSI] dpt_i2o: move from virt_to_bus/bus_to_virt ...") Signed-off-by:
Ben Hutchings <benh@debian.org> Signed-off-by:
-
Ben Hutchings authored
adpt_i2o_passthru() takes a user-provided message and passes it through to the hardware with appropriate translation of addresses and message IDs. It has a number of bugs: - When a message requires scatter/gather, it doesn't verify that the offset to the scatter/gather list is less than the message size. - When a message requires scatter/gather, it overwrites the DMA addresses with the user-space virtual addresses before unmapping the DMA buffers. - It reads the message from user memory multiple times. This allows user-space to change the message and bypass validation. - It assumes that the message is at least 4 words long, but doesn't check that. I tried fixing these, but even the maintainer of the corresponding user-space in Debian doesn't have the hardware any more. Instead, remove the pass-through ioctl (I2OUSRCMD) and supporting code. There is no corresponding upstream commit, because this driver was removed upstream. Fixes: 1da177e4 ("Linux-2.6.12-rc2") Fixes: 67af2b06 ("[SCSI] dpt_i2o: move from virt_to_bus/bus_to_virt ...") Signed-off-by:
-
Arnd Bergmann authored
commit 42d95d1b upstream. The meaning of the 'imply' keyword has changed recently, and neither the old meaning (select the symbol if its dependencies are met) nor the new meaning (enable it by default, but let the user set any other setting) is what we want here. Work around this by adding two more Kconfig options that lead to the correct behavior: if DRM_RCAR_USE_CMM and DRM_RCAR_USE_LVDS are enabled, that portion of the driver becomes usable, and no configuration results in a link error. This avoids a link failure: arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_begin': rcar_du_crtc.c:(.text+0x1444): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_enable': rcar_du_crtc.c:(.text+0x14d4): undefined reference to `rcar_cmm_enable' arm-linux-gnueabi-ld: rcar_du_crtc.c:(.text+0x1548): undefined reference to `rcar_cmm_setup' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_crtc.o: in function `rcar_du_crtc_atomic_disable': rcar_du_crtc.c:(.text+0x18b8): undefined reference to `rcar_cmm_disable' arm-linux-gnueabi-ld: drivers/gpu/drm/rcar-du/rcar_du_kms.o: in function `rcar_du_modeset_init': Link: https://lore.kernel.org/all/20200417155553.675905-5-arnd@arndb.de/ Signed-off-by:
Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
Randy Dunlap <rdunlap@infradead.org> Signed-off-by:
Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Cc: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Arnd Bergmann authored
commit d7a7d721 upstream. FIELD_GET() must only be used with a mask that is a compile-time constant: drivers/media/platform/ti-vpe/cal.h: In function 'cal_read_field': include/linux/compiler_types.h:320:38: error: call to '__compiletime_assert_247' declared with attribute error: FIELD_GET: mask is not constant include/linux/bitfield.h:46:3: note: in expansion of macro 'BUILD_BUG_ON_MSG' 46 | BUILD_BUG_ON_MSG(!__builtin_constant_p(_mask), \ | ^~~~~~~~~~~~~~~~ drivers/media/platform/ti-vpe/cal.h:220:9: note: in expansion of macro 'FIELD_GET' 220 | return FIELD_GET(mask, cal_read(cal, offset)); | ^~~~~~~~~ The problem here is that the function is not always inlined. Mark it __always_inline to avoid the problem. Signed-off-by:
Hans Verkuil <hverkuil-cisco@xs4all.nl> Signed-off-by:
Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Cc: Dan Carpenter <dan.carpenter@linaro.org> Signed-off-by:
-
Lino Sanfilippo authored
commit 0c7e66e5 upstream. The TIS interrupt handler at least has to read and write the interrupt status register. In case of SPI both operations result in a call to tpm_tis_spi_transfer() which uses the bus_lock_mutex of the spi device and thus must only be called from a sleepable context. To ensure this request a threaded interrupt handler. Signed-off-by:
Lino Sanfilippo <l.sanfilippo@kunbus.com> Tested-by:
Michael Niewöhner <linux@mniewoehner.de> Tested-by:
Jarkko Sakkinen <jarkko@kernel.org> Reviewed-by:
-
Jim Wylder authored
commit 39815141 upstream. Currently, when regmap_raw_write() splits the data, it uses the max_raw_write value defined for the bus. For any bus that includes the target register address in the max_raw_write value, the chunked transmission will always exceed the maximum transmission length. To avoid this problem, subtract the length of the register and the padding from the maximum transmission. Signed-off-by:
Jim Wylder <jwylder@google.com> Link: https://lore.kernel.org/r/20230517152444.3690870-2-jwylder@google.com Signed-off-by:
Mark Brown <broonie@kernel.org> Signed-off-by:
-
Roberto Sassu authored
commit c3d03e8e upstream. Commit ac4e97ab ("scatterlist: sg_set_buf() argument must be in linear mapping") checks that both the signature and the digest reside in the linear mapping area. However, more recently commit ba14a194 ("fork: Add generic vmalloced stack support") made it possible to move the stack in the vmalloc area, which is not contiguous, and thus not suitable for sg_set_buf() which needs adjacent pages. Always make a copy of the signature and digest in the same buffer used to store the key and its parameters, and pass them to sg_init_one(). Prefer it to conditionally doing the copy if necessary, to keep the code simple. The buffer allocated with kmalloc() is in the linear mapping area. Cc: stable@vger.kernel.org # 4.9.x Fixes: ba14a194 ("fork: Add generic vmalloced stack support") Link: https://lore.kernel.org/linux-integrity/Y4pIpxbjBdajymBJ@sol.localdomain/ Suggested-by:
Eric Biggers <ebiggers@kernel.org> Signed-off-by:
Roberto Sassu <roberto.sassu@huawei.com> Reviewed-by:
Eric Biggers <ebiggers@google.com> Tested-by:
Stefan Berger <stefanb@linux.ibm.com> Signed-off-by:
-
Sean Christopherson authored
commit 8b703a49 upstream. Increment vcpu->stat.exits when handling a fastpath VM-Exit without going through any part of the "slow" path. Not bumping the exits stat can result in wildly misleading exit counts, e.g. if the primary reason the guest is exiting is to program the TSC deadline timer. Fixes: 404d5d7b ("KVM: X86: Introduce more exit_fastpath_completion enum values") Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20230602011920.787844-2-seanjc@google.com Signed-off-by:
-
Mirsad Goran Todorovac authored
commit 48e15602 upstream. The following kernel memory leak was noticed after running tools/testing/selftests/firmware/fw_run_tests.sh: [root@pc-mtodorov firmware]# cat /sys/kernel/debug/kmemleak . . . unreferenced object 0xffff955389bc3400 (size 1024): comm "test_firmware-0", pid 5451, jiffies 4294944822 (age 65.652s) hex dump (first 32 bytes): 47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567.......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0 [<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240 [<ffffffff962704de>] kmalloc_trace+0x2e/0xc0 [<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180 [<ffffffff95fd813b>] kthread+0x10b/0x140 [<ffffffff95e033e9>] ret_from_fork+0x29/0x50 unreferenced object 0xffff9553c334b400 (size 1024): comm "test_firmware-1", pid 5452, jiffies 4294944822 (age 65.652s) hex dump (first 32 bytes): 47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567.......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0 [<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240 [<ffffffff962704de>] kmalloc_trace+0x2e/0xc0 [<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180 [<ffffffff95fd813b>] kthread+0x10b/0x140 [<ffffffff95e033e9>] ret_from_fork+0x29/0x50 unreferenced object 0xffff9553c334f000 (size 1024): comm "test_firmware-2", pid 5453, jiffies 4294944822 (age 65.652s) hex dump (first 32 bytes): 47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567.......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0 [<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240 [<ffffffff962704de>] kmalloc_trace+0x2e/0xc0 [<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180 [<ffffffff95fd813b>] kthread+0x10b/0x140 [<ffffffff95e033e9>] ret_from_fork+0x29/0x50 unreferenced object 0xffff9553c3348400 (size 1024): comm "test_firmware-3", pid 5454, jiffies 4294944822 (age 65.652s) hex dump (first 32 bytes): 47 48 34 35 36 37 0a 00 00 00 00 00 00 00 00 00 GH4567.......... 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace: [<ffffffff962f5dec>] slab_post_alloc_hook+0x8c/0x3c0 [<ffffffff962fcca4>] __kmem_cache_alloc_node+0x184/0x240 [<ffffffff962704de>] kmalloc_trace+0x2e/0xc0 [<ffffffff9665b42d>] test_fw_run_batch_request+0x9d/0x180 [<ffffffff95fd813b>] kthread+0x10b/0x140 [<ffffffff95e033e9>] ret_from_fork+0x29/0x50 [root@pc-mtodorov firmware]# Note that the size 1024 corresponds to the size of the test firmware buffer. The actual number of the buffers leaked is around 70-110, depending on the test run. The cause of the leak is the following: request_partial_firmware_into_buf() and request_firmware_into_buf() provided firmware buffer isn't released on release_firmware(), we have allocated it and we are responsible for deallocating it manually. This is introduced in a number of context where previously only release_firmware() was called, which was insufficient. Reported-by:
Mirsad Goran Todorovac <mirsad.todorovac@alu.unizg.hr> Fixes: 7feebfa4 ("test_firmware: add support for request_firmware_into_buf") Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Dan Carpenter <error27@gmail.com> Cc: Takashi Iwai <tiwai@suse.de> Cc: Luis Chamberlain <mcgrof@kernel.org> Cc: Russ Weight <russell.h.weight@intel.com> Cc: Tianfei zhang <tianfei.zhang@intel.com> Cc: Christophe JAILLET <christophe.jaillet@wanadoo.fr> Cc: Zhengchao Shao <shaozhengchao@huawei.com> Cc: Colin Ian King <colin.i.king@gmail.com> Cc: linux-kernel@vger.kernel.org Cc: Kees Cook <keescook@chromium.org> Cc: Scott Branden <sbranden@broadcom.com> Cc: Luis R. Rodriguez <mcgrof@kernel.org> Cc: linux-kselftest@vger.kernel.org Cc: stable@vger.kernel.org # v5.4 Signed-off-by:
-
Christophe JAILLET authored
commit 134f49de upstream. If an error occurs after reset_control_deassert(), it must be re-asserted, as already done in the .remove() function. Fixes: c6825c63 ("serial: 8250_tegra: Create Tegra specific 8250 driver") Cc: stable <stable@kernel.org> Signed-off-by:
Christophe JAILLET <christophe.jaillet@wanadoo.fr> Link: https://lore.kernel.org/r/f8130f35339cc80edc6b9aac4bb2a60b60a226bf.1684063511.git.christophe.jaillet@wanadoo.fr Signed-off-by:
-
Helge Deller authored
commit d78bd6cc upstream. syzbot repored this bug in the softcursor code: BUG: KASAN: null-ptr-deref in soft_cursor+0x384/0x6b4 drivers/video/fbdev/core/softcursor.c:70 Read of size 16 at addr 0000000000000200 by task kworker/u4:1/12 CPU: 0 PID: 12 Comm: kworker/u4:1 Not tainted 6.4.0-rc3-syzkaller-geb0f1697d729 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/28/2023 Workqueue: events_power_efficient fb_flashcursor Call trace: dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:233 show_stack+0x2c/0x44 arch/arm64/kernel/stacktrace.c:240 __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106 print_report+0xe4/0x514 mm/kasan/report.c:465 kasan_report+0xd4/0x130 mm/kasan/report.c:572 kasan_check_range+0x264/0x2a4 mm/kasan/generic.c:187 __asan_memcpy+0x3c/0x84 mm/kasan/shadow.c:105 soft_cursor+0x384/0x6b4 drivers/video/fbdev/core/softcursor.c:70 bit_cursor+0x113c/0x1a64 drivers/video/fbdev/core/bitblit.c:377 fb_flashcursor+0x35c/0x54c drivers/video/fbdev/core/fbcon.c:380 process_one_work+0x788/0x12d4 kernel/workqueue.c:2405 worker_thread+0x8e0/0xfe8 kernel/workqueue.c:2552 kthread+0x288/0x310 kernel/kthread.c:379 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:853 This fix let bit_cursor() bail out early when a font bitmap isn't available yet. Signed-off-by:
Helge Deller <deller@gmx.de> Reported-by:
<syzbot+d910bd780e6efac35869@syzkaller.appspotmail.com> Acked-by:
Sam Ravnborg <sam@ravnborg.org> Cc: stable@kernel.org Signed-off-by:
-
Theodore Ts'o authored
commit aff3bea9 upstream. Treat i_data_sem for ea_inodes as being in their own lockdep class to avoid lockdep complaints about ext4_setattr's use of inode_lock() on normal inodes potentially causing lock ordering with i_data_sem on ea_inodes in ext4_xattr_inode_write(). However, ea_inodes will be operated on by ext4_setattr(), so this isn't a problem. Cc: stable@kernel.org Link: https://syzkaller.appspot.com/bug?extid=298c5d8fb4a128bc27b0 Reported-by:
<syzbot+298c5d8fb4a128bc27b0@syzkaller.appspotmail.com> Signed-off-by:
-
Theodore Ts'o authored
commit 2bc7e7c1 upstream. An ea_inode stores the value of an extended attribute; it can not have extended attributes itself, or this will cause recursive nightmares. Add a check in ext4_iget() to make sure this is the case. Cc: stable@kernel.org Reported-by:
<syzbot+e44749b6ba4d0434cd47@syzkaller.appspotmail.com> Signed-off-by:
-
Theodore Ts'o authored
commit b928dfdc upstream. If the ea_inode has been pushed out of the inode cache while there is still a reference in the mb_cache, the lockdep subclass will not be set on the inode, which can lead to some lockdep false positives. Fixes: 33d201e0 ("ext4: fix lockdep warning about recursive inode locking") Cc: stable@kernel.org Reported-by:
<syzbot+d4b971e744b1f5439336@syzkaller.appspotmail.com> Signed-off-by:
-
Theodore Ts'o authored
commit b3e6bcb9 upstream. Add a new flag, EXT4_IGET_EA_INODE which indicates whether the inode is expected to have the EA_INODE flag or not. If the flag is not set/clear as expected, then fail the iget() operation and mark the file system as corrupted. This commit also makes the ext4_iget() always perform the is_bad_inode() check even when the inode is already inode cache. This allows us to remove the is_bad_inode() check from the callers of ext4_iget() in the ea_inode code. Reported-by:
<syzbot+cbb68193bdb95af4340a@syzkaller.appspotmail.com> Reported-by:
<syzbot+62120febbd1ee3c3c860@syzkaller.appspotmail.com> Reported-by:
<syzbot+edce54daffee36421b4c@syzkaller.appspotmail.com> Cc: stable@kernel.org Signed-off-by:
-
Matthieu Baerts authored
commit 0f4955a4 upstream. Selftests are supposed to run on any kernels, including the old ones not supporting MPTCP. A new check is then added to make sure MPTCP is supported. If not, the test stops and is marked as "skipped". Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: eedbc685 ("selftests: add PM netlink functional tests") Cc: stable@vger.kernel.org Acked-by:
-
Matthieu Baerts authored
commit d83013bd upstream. Selftests are supposed to run on any kernels, including the old ones not supporting MPTCP. A new check is then added to make sure MPTCP is supported. If not, the test stops and is marked as "skipped". Note that this check can also mark the test as failed if 'SELFTESTS_MPTCP_LIB_EXPECT_ALL_FEATURES' env var is set to 1: by doing that, we can make sure a test is not being skipped by mistake. A new shared file is added here to be able to re-used the same check in the different selftests we have. Link: https://github.com/multipath-tcp/mptcp_net-next/issues/368 Fixes: 048d19d4 ("mptcp: add basic kselftest for mptcp") Cc: stable@vger.kernel.org Acked-by:
-
Pietro Borrello authored
commit 81d0fa4c upstream. All callers of trace_probe_primary_from_call() check the return value to be non NULL. However, the function returns list_first_entry(&tpe->probes, ...) which can never be NULL. Additionally, it does not check for the list being possibly empty, possibly causing a type confusion on empty lists. Use list_first_entry_or_null() which solves both problems. Link: https://lore.kernel.org/linux-trace-kernel/20230128-list-entry-null-check-v1-1-8bde6a3da2ef@diag.uniroma1.it/ Fixes: 60d53e2c ("tracing/probe: Split trace_event related data from trace_probe") Signed-off-by:
Pietro Borrello <borrello@diag.uniroma1.it> Reviewed-by:
Steven Rostedt (Google) <rostedt@goodmis.org> Acked-by:
Masami Hiramatsu (Google) <mhiramat@kernel.org> Acked-by:
Mukesh Ojha <quic_mojha@quicinc.com> Cc: stable@vger.kernel.org Signed-off-by:
-
Paul Moore authored
commit 42c4e97e upstream. The Linux Kernel currently only requires make v3.82 while the grouped target functionality requires make v4.3. Removed the grouped target introduced in 4ce1f694 ("selinux: ensure av_permissions.h is built when needed") as well as the multiple header file targets in the make rule. This effectively reverts the problem commit. We will revisit this change when make >= 4.3 is required by the rest of the kernel. Cc: stable@vger.kernel.org Fixes: 4ce1f694 ("selinux: ensure av_permissions.h is built when needed") Reported-by:
Erwan Velu <e.velu@criteo.com> Reported-by:
Luiz Capitulino <luizcap@amazon.com> Tested-by:
Paul Moore <paul@paul-moore.com> Signed-off-by:
-
pengfuyuan authored
commit 5ad9b471 upstream. When compiling on a MIPS 64-bit machine we get these warnings: In file included from ./arch/mips/include/asm/cacheflush.h:13, from ./include/linux/cacheflush.h:5, from ./include/linux/highmem.h:8, from ./include/linux/bvec.h:10, from ./include/linux/blk_types.h:10, from ./include/linux/blkdev.h:9, from fs/btrfs/disk-io.c:7: fs/btrfs/disk-io.c: In function ‘csum_tree_block’: fs/btrfs/disk-io.c:100:34: error: array subscript 1 is above array bounds of ‘struct page *[1]’ [-Werror=array-bounds] 100 | kaddr = page_address(buf->pages[i]); | ~~~~~~~~~~^~~ ./include/linux/mm.h:2135:48: note: in definition of macro ‘page_address’ 2135 | #define page_address(page) lowmem_page_address(page) | ^~~~ cc1: all warnings being treated as errors We can check if i overflows to solve the problem. However, this doesn't make much sense, since i == 1 and num_pages == 1 doesn't execute the body of the loop. In addition, i < num_pages can also ensure that buf->pages[i] will not cross the boundary. Unfortunately, this doesn't help with the problem observed here: gcc still complains. To fix this add a compile-time condition for the extent buffer page array size limit, which would eventually lead to eliminating the whole for loop. CC: stable@vger.kernel.org # 5.10+ Signed-off-by:
pengfuyuan <pengfuyuan@kylinos.cn> Reviewed-by:
David Sterba <dsterba@suse.com> Signed-off-by:
-
Sherry Sun authored
commit 2474e054 upstream. LPUART IP now has two known bugs, one is that CTS has higher priority than the break signal, which causes the break signal sending through UARTCTRL_SBK may impacted by the CTS input if the HW flow control is enabled. It exists on all platforms we support in this driver. So we add a workaround patch for this issue: commit c4c81db5 ("tty: serial: fsl_lpuart: disable the CTS when send break signal"). Another IP bug is i.MX8QM LPUART may have an additional break character being sent after SBK was cleared. It may need to add some delay between clearing SBK and re-enabling CTS to ensure that the SBK latch are completely cleared. But we found that during the delay period before CTS is enabled, there is still a risk that Bluetooth data in TX FIFO may be sent out during this period because of break off and CTS disabled(even if BT sets CTS line deasserted, data is still sent to BT). Due to this risk, we have to drop the CTS-disabling workaround for SBK bugs, use TXINV seems to be a better way to replace SBK feature and avoid above risk. Also need to disable the transmitter to prevent any data from being sent out during break, then invert the TX line to send break. Then disable the TXINV when turn off break and re-enable transmitter. Fixes: c4c81db5 ("tty: serial: fsl_lpuart: disable the CTS when send break signal") Cc: stable <stable@kernel.org> Signed-off-by:
Sherry Sun <sherry.sun@nxp.com> Link: https://lore.kernel.org/r/20230519094751.28948-1-sherry.sun@nxp.com Signed-off-by:
-
Deren Wu authored
commit a99d21ce upstream. We may get an empty response with zero length at the beginning of the driver start and get following UBSAN error. Since there is no content(SDRT_NONE) for the response, just return and skip the response handling to avoid this problem. Test pass : SDIO wifi throughput test with this patch [ 126.980684] UBSAN: array-index-out-of-bounds in drivers/mmc/host/vub300.c:1719:12 [ 126.980709] index -1 is out of range for type 'u32 [4]' [ 126.980729] CPU: 4 PID: 9 Comm: kworker/u16:0 Tainted: G E 6.3.0-rc4-mtk-local-202304272142 #1 [ 126.980754] Hardware name: Intel(R) Client Systems NUC8i7BEH/NUC8BEB, BIOS BECFL357.86A.0081.2020.0504.1834 05/04/2020 [ 126.980770] Workqueue: kvub300c vub300_cmndwork_thread [vub300] [ 126.980833] Call Trace: [ 126.980845] <TASK> [ 126.980860] dump_stack_lvl+0x48/0x70 [ 126.980895] dump_stack+0x10/0x20 [ 126.980916] ubsan_epilogue+0x9/0x40 [ 126.980944] __ubsan_handle_out_of_bounds+0x70/0x90 [ 126.980979] vub300_cmndwork_thread+0x58e7/0x5e10 [vub300] [ 126.981018] ? _raw_spin_unlock+0x18/0x40 [ 126.981042] ? finish_task_switch+0x175/0x6f0 [ 126.981070] ? __switch_to+0x42e/0xda0 [ 126.981089] ? __switch_to_asm+0x3a/0x80 [ 126.981129] ? __pfx_vub300_cmndwork_thread+0x10/0x10 [vub300] [ 126.981174] ? __kasan_check_read+0x11/0x20 [ 126.981204] process_one_work+0x7ee/0x13d0 [ 126.981246] worker_thread+0x53c/0x1240 [ 126.981291] kthread+0x2b8/0x370 [ 126.981312] ? __pfx_worker_thread+0x10/0x10 [ 126.981336] ? __pfx_kthread+0x10/0x10 [ 126.981359] ret_from_fork+0x29/0x50 [ 126.981400] </TASK> Fixes: 88095e7b ("mmc: Add new VUB300 USB-to-SD/SDIO/MMC driver") Signed-off-by:
Deren Wu <deren.wu@mediatek.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/048cd6972c50c33c2e8f81d5228fed928519918b.1683987673.git.deren.wu@mediatek.com Signed-off-by:
Ulf Hansson <ulf.hansson@linaro.org> Signed-off-by:
-
Martin Liška authored
commit 32329216 upstream. Fixes the following GCC warning: drivers/net/ethernet/sun/cassini.c:1316:29: error: comparison between two arrays [-Werror=array-compare] drivers/net/ethernet/sun/cassini.c:3783:34: error: comparison between two arrays [-Werror=array-compare] Note that 2 arrays should be compared by comparing of their addresses: note: use ‘&cas_prog_workaroundtab[0] == &cas_prog_null[0]’ to compare the addresses Signed-off-by:
Martin Liska <mliska@suse.cz> Signed-off-by:
David S. Miller <davem@davemloft.net> Signed-off-by:
-
Linus Torvalds authored
commit f7d63b50 upstream. [ Upstream commit 49beadbd ] While the concept of checking for dangling pointers to local variables at function exit is really interesting, the gcc-12 implementation is not compatible with reality, and results in false positives. For example, gcc sees us putting things on a local list head allocated on the stack, which involves exactly those kinds of pointers to the local stack entry: In function ‘__list_add’, inlined from ‘list_add_tail’ at include/linux/list.h:102:2, inlined from ‘rebuild_snap_realms’ at fs/ceph/snap.c:434:2: include/linux/list.h:74:19: warning: storing the address of local variable ‘realm_queue’ in ‘*&realm_27(D)->rebuild_item.prev’ [-Wdangling-pointer=] 74 | new->prev = prev; | ~~~~~~~~~~^~~~~~ But then gcc - understandably - doesn't really understand the big picture how the doubly linked list works, so doesn't see how we then end up emptying said list head in a loop and the pointer we added has been removed. Gcc also complains about us (intentionally) using this as a way to store a kind of fake stack trace, eg drivers/acpi/acpica/utdebug.c:40:38: warning: storing the address of local variable ‘current_sp’ in ‘acpi_gbl_entry_stack_pointer’ [-Wdangling-pointer=] 40 | acpi_gbl_entry_stack_pointer = ¤t_sp; | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~ which is entirely reasonable from a compiler standpoint, and we may want to change those kinds of patterns, but not not. So this is one of those "it would be lovely if the compiler were to complain about us leaving dangling pointers to the stack", but not this way. Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org> Signed-off-by:
-
Kees Cook authored
commit e3128a9d upstream. In builds with -Warray-bounds, casts from smaller objects to larger objects will produce warnings. These can be overly conservative, but since -Warray-bounds has been finding legitimate bugs, it is desirable to turn it on globally. Instead of casting a u32 to a larger object, redefine the u32 portion of the header to a separate struct that can be used for both u32 operations and the distinct header fields. Silences this warning: drivers/net/wireless/ath/ath6kl/htc_mbox.c: In function 'htc_wait_for_ctrl_msg': drivers/net/wireless/ath/ath6kl/htc_mbox.c:2275:20: error: array subscript 'struct htc_frame_hdr[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds] 2275 | if (htc_hdr->eid != ENDPOINT_0) | ^~ drivers/net/wireless/ath/ath6kl/htc_mbox.c:2264:13: note: while referencing 'look_ahead' 2264 | u32 look_ahead; | ^~~~~~~~~~ This change results in no executable instruction differences. Signed-off-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Kalle Valo <quic_kvalo@quicinc.com> Link: https://lore.kernel.org/r/20211207063538.2767954-1-keescook@chromium.org Signed-off-by:
-
Adam Borowski authored
commit e5b5d254 upstream. Address of a field inside a struct can't possibly be null; gcc-12 warns about this. Signed-off-by:
Adam Borowski <kilobyte@angband.pl> Signed-off-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
-
Kees Cook authored
commit aeb84412 upstream. GCC 11 (incorrectly[1]) assumes that literal values cast to (void *) should be treated like a NULL pointer with an offset, and raises diagnostics when doing bounds checking under -Warray-bounds. GCC 12 got "smarter" about finding these: In function 'rdfs8', inlined from 'vga_recalc_vertical' at /srv/code/arch/x86/boot/video-mode.c:124:29, inlined from 'set_mode' at /srv/code/arch/x86/boot/video-mode.c:163:3: /srv/code/arch/x86/boot/boot.h:114:9: warning: array subscript 0 is outside array bounds of 'u8[0]' {aka 'unsigned char[]'} [-Warray-bounds] 114 | asm volatile("movb %%fs:%1,%0" : "=q" (v) : "m" (*(u8 *)addr)); | ^~~ This has been solved in other places[2] already by using the recently added absolute_pointer() macro. Do the same here. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99578 [2] https://lore.kernel.org/all/20210912160149.2227137-1-linux@roeck-us.net/ Signed-off-by:
Borislav Petkov <bp@suse.de> Reviewed-by:
-
Damien Le Moal authored
commit 7f875850 upstream. For devices not attached to a port multiplier and managed directly by libata, the device number passed to ata_find_dev() must always be lower than the maximum number of devices returned by ata_link_max_devices(). That is 1 for SATA devices or 2 for an IDE link with master+slave devices. This device number is the SCSI device ID which matches these constraints as the IDs are generated per port and so never exceed the maximum number of devices for the link being used. However, for libsas managed devices, SCSI device IDs are assigned per struct scsi_host, leading to device IDs for SATA devices that can be well in excess of libata per-link maximum number of devices. This results in ata_find_dev() to always return NULL for libsas managed devices except for the first device of the target scsi_host with ID (device number) equal to 0. This issue is visible by executing the hdparm utility, which fails. E.g.: hdparm -i /dev/sdX /dev/sdX: HDIO_GET_IDENTITY failed: No message of desired type Fix this by rewriting ata_find_dev() to ignore the device number for non-PMP attached devices with a link with at most 1 device, that is SATA devices. For these, the device number 0 is always used to return the correct pointer to the struct ata_device of the port link. This change excludes IDE master/slave setups (maximum number of devices per link is 2) and port-multiplier attached devices. Also, to be consistant with the fact that SCSI device IDs and channel numbers used as device numbers are both unsigned int, change the devno argument of ata_find_dev() to unsigned int. Reported-by:
Xingui Yang <yangxingui@huawei.com> Fixes: 41bda9c9 ("libata-link: update hotplug to handle PMP links") Cc: stable@vger.kernel.org Signed-off-by:
Damien Le Moal <dlemoal@kernel.org> Reviewed-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Bart Van Assche authored
commit 6d074ce2 upstream. gcc 13 may assign another type to enumeration constants than gcc 12. Split the large enum at the top of source file stex.c such that the type of the constants used in time expressions is changed back to the same type chosen by gcc 12. This patch suppresses compiler warnings like this one: In file included from ./include/linux/bitops.h:7, from ./include/linux/kernel.h:22, from drivers/scsi/stex.c:13: drivers/scsi/stex.c: In function ‘stex_common_handshake’: ./include/linux/typecheck.h:12:25: error: comparison of distinct pointer types lacks a cast [-Werror] 12 | (void)(&__dummy == &__dummy2); \ | ^~ ./include/linux/jiffies.h:106:10: note: in expansion of macro ‘typecheck’ 106 | typecheck(unsigned long, b) && \ | ^~~~~~~~~ drivers/scsi/stex.c:1035:29: note: in expansion of macro ‘time_after’ 1035 | if (time_after(jiffies, before + MU_MAX_DELAY * HZ)) { | ^~~~~~~~~~ See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107405 . Cc: stable@vger.kernel.org Acked-by:
Bart Van Assche <bvanassche@acm.org> Link: https://lore.kernel.org/r/20230529195034.3077-1-bvanassche@acm.org Signed-off-by:
Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by:
-
Richard Acayan authored
commit 46248400 upstream. The channel's rpmsg object allows new invocations to be made. After old invocations are already interrupted, the driver shouldn't try to invoke anymore. Invalidating the rpmsg at the end of the driver removal function makes it easy to cause a race condition in userspace. Even closing a file descriptor before the driver finishes its cleanup can cause an invocation via fastrpc_release_current_dsp_process() and subsequent timeout. Invalidate the channel before the invocations are interrupted to make sure that no invocations can be created to hang after the device closes. Fixes: c68cfb71 ("misc: fastrpc: Add support for context Invoke method") Cc: stable <stable@kernel.org> Signed-off-by:
Richard Acayan <mailingradian@gmail.com> Signed-off-by:
Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20230523152550.438363-5-srinivas.kandagatla@linaro.org Signed-off-by:
-
Richard Acayan authored
commit b6a06285 upstream. The return value is initialized as -1, or -EPERM. The completion of an invocation implies that the return value is set appropriately, but "Permission denied" does not accurately describe the outcome of the invocation. Set the invocation's return value to a more appropriate "Broken pipe", as the cleanup breaks the driver's connection with rpmsg. Fixes: c68cfb71 ("misc: fastrpc: Add support for context Invoke method") Cc: stable <stable@kernel.org> Signed-off-by:
-
Uttkarsh Aggarwal authored
commit efb6b535 upstream. While exercising the unbind path, with the current implementation the functionfs_unbind would be calling which waits for the ffs->mutex to be available, however within the same time ffs_ep0_read is invoked & if no setup packets are pending, it will invoke function wait_event_interruptible_exclusive_locked_irq which by definition waits for the ev.count to be increased inside the same mutex for which functionfs_unbind is waiting. This creates deadlock situation because the functionfs_unbind won't get the lock until ev.count is increased which can only happen if the caller ffs_func_unbind can proceed further. Following is the illustration: CPU1 CPU2 ffs_func_unbind() ffs_ep0_read() mutex_lock(ffs->mutex) wait_event(ffs->ev.count) functionfs_unbind() mutex_lock(ffs->mutex) mutex_unlock(ffs->mutex) ffs_event_add() <deadlock> Fix this by moving the event unbind before functionfs_unbind to ensure the ev.count is incrased properly. Fixes: 6a19da11 ("usb: gadget: f_fs: Prevent race during ffs_ep0_queue_wait") Cc: stable <stable@kernel.org> Signed-off-by:
Uttkarsh Aggarwal <quic_uaggarwa@quicinc.com> Link: https://lore.kernel.org/r/20230525092854.7992-1-quic_uaggarwa@quicinc.com Signed-off-by:
-
