--- /dev/null
+From da9065caa594d19b26e1a030fd0cc27bd365d685 Mon Sep 17 00:00:00 2001
+From: Gui-Dong Han <2045gemini@gmail.com>
+Date: Fri, 22 Dec 2023 23:12:41 +0800
+Subject: Bluetooth: Fix atomicity violation in {min,max}_key_size_set
+
+From: Gui-Dong Han <2045gemini@gmail.com>
+
+commit da9065caa594d19b26e1a030fd0cc27bd365d685 upstream.
+
+In min_key_size_set():
+ if (val > hdev->le_max_key_size || val < SMP_MIN_ENC_KEY_SIZE)
+ return -EINVAL;
+ hci_dev_lock(hdev);
+ hdev->le_min_key_size = val;
+ hci_dev_unlock(hdev);
+
+In max_key_size_set():
+ if (val > SMP_MAX_ENC_KEY_SIZE || val < hdev->le_min_key_size)
+ return -EINVAL;
+ hci_dev_lock(hdev);
+ hdev->le_max_key_size = val;
+ hci_dev_unlock(hdev);
+
+The atomicity violation occurs due to concurrent execution of set_min and
+set_max funcs.Consider a scenario where setmin writes a new, valid 'min'
+value, and concurrently, setmax writes a value that is greater than the
+old 'min' but smaller than the new 'min'. In this case, setmax might check
+against the old 'min' value (before acquiring the lock) but write its
+value after the 'min' has been updated by setmin. This leads to a
+situation where the 'max' value ends up being smaller than the 'min'
+value, which is an inconsistency.
+
+This possible bug is found by an experimental static analysis tool
+developed by our team, BassCheck[1]. This tool analyzes the locking APIs
+to extract function pairs that can be concurrently executed, and then
+analyzes the instructions in the paired functions to identify possible
+concurrency bugs including data races and atomicity violations. The above
+possible bug is reported when our tool analyzes the source code of
+Linux 5.17.
+
+To resolve this issue, it is suggested to encompass the validity checks
+within the locked sections in both set_min and set_max funcs. The
+modification ensures that the validation of 'val' against the
+current min/max values is atomic, thus maintaining the integrity of the
+settings. With this patch applied, our tool no longer reports the bug,
+with the kernel configuration allyesconfig for x86_64. Due to the lack of
+associated hardware, we cannot test the patch in runtime testing, and just
+verify it according to the code logic.
+
+[1] https://sites.google.com/view/basscheck/
+
+Fixes: 18f81241b74f ("Bluetooth: Move {min,max}_key_size debugfs ...")
+Cc: stable@vger.kernel.org
+Signed-off-by: Gui-Dong Han <2045gemini@gmail.com>
+Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ net/bluetooth/hci_debugfs.c | 12 ++++++++----
+ 1 file changed, 8 insertions(+), 4 deletions(-)
+
+--- a/net/bluetooth/hci_debugfs.c
++++ b/net/bluetooth/hci_debugfs.c
+@@ -994,10 +994,12 @@ static int min_key_size_set(void *data,
+ {
+ struct hci_dev *hdev = data;
+
+- if (val > hdev->le_max_key_size || val < SMP_MIN_ENC_KEY_SIZE)
++ hci_dev_lock(hdev);
++ if (val > hdev->le_max_key_size || val < SMP_MIN_ENC_KEY_SIZE) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->le_min_key_size = val;
+ hci_dev_unlock(hdev);
+
+@@ -1022,10 +1024,12 @@ static int max_key_size_set(void *data,
+ {
+ struct hci_dev *hdev = data;
+
+- if (val > SMP_MAX_ENC_KEY_SIZE || val < hdev->le_min_key_size)
++ hci_dev_lock(hdev);
++ if (val > SMP_MAX_ENC_KEY_SIZE || val < hdev->le_min_key_size) {
++ hci_dev_unlock(hdev);
+ return -EINVAL;
++ }
+
+- hci_dev_lock(hdev);
+ hdev->le_max_key_size = val;
+ hci_dev_unlock(hdev);
+
--- /dev/null
+From 15e4c1f462279b4e128f27de48133e0debe9e0df Mon Sep 17 00:00:00 2001
+From: Nam Cao <namcao@linutronix.de>
+Date: Mon, 18 Dec 2023 10:57:30 +0100
+Subject: fbdev: flush deferred work in fb_deferred_io_fsync()
+
+From: Nam Cao <namcao@linutronix.de>
+
+commit 15e4c1f462279b4e128f27de48133e0debe9e0df upstream.
+
+The driver's fsync() is supposed to flush any pending operation to
+hardware. It is implemented in this driver by cancelling the queued
+deferred IO first, then schedule it for "immediate execution" by calling
+schedule_delayed_work() again with delay=0. However, setting delay=0
+only means the work is scheduled immediately, it does not mean the work
+is executed immediately. There is no guarantee that the work is finished
+after schedule_delayed_work() returns. After this driver's fsync()
+returns, there can still be pending work. Furthermore, if close() is
+called by users immediately after fsync(), the pending work gets
+cancelled and fsync() may do nothing.
+
+To ensure that the deferred IO completes, use flush_delayed_work()
+instead. Write operations to this driver either write to the device
+directly, or invoke schedule_delayed_work(); so by flushing the
+workqueue, it can be guaranteed that all previous writes make it to the
+device.
+
+Fixes: 5e841b88d23d ("fb: fsync() method for deferred I/O flush.")
+Cc: stable@vger.kernel.org
+Signed-off-by: Nam Cao <namcao@linutronix.de>
+Reviewed-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
+Signed-off-by: Helge Deller <deller@gmx.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/video/fbdev/core/fb_defio.c | 6 +-----
+ 1 file changed, 1 insertion(+), 5 deletions(-)
+
+--- a/drivers/video/fbdev/core/fb_defio.c
++++ b/drivers/video/fbdev/core/fb_defio.c
+@@ -78,11 +78,7 @@ int fb_deferred_io_fsync(struct file *fi
+ return 0;
+
+ inode_lock(inode);
+- /* Kill off the delayed work */
+- cancel_delayed_work_sync(&info->deferred_work);
+-
+- /* Run it immediately */
+- schedule_delayed_work(&info->deferred_work, 0);
++ flush_delayed_work(&info->deferred_work);
+ inode_unlock(inode);
+
+ return 0;
--- /dev/null
+From 2fb96ecf68bc1fb55508d22ebaf9518eaeb1a088 Mon Sep 17 00:00:00 2001
+From: Jens Axboe <axboe@kernel.dk>
+Date: Mon, 22 Jan 2024 12:30:07 -0700
+Subject: io_uring/rw: ensure io->bytes_done is always initialized
+
+From: Jens Axboe <axboe@kernel.dk>
+
+commit 0a535eddbe0dc1de4386046ab849f08aeb2f8faf upstream.
+
+If IOSQE_ASYNC is set and we fail importing an iovec for a readv or
+writev request, then we leave ->bytes_done uninitialized and hence the
+eventual failure CQE posted can potentially have a random res value
+rather than the expected -EINVAL.
+
+Setup ->bytes_done before potentially failing, so we have a consistent
+value if we fail the request early.
+
+Cc: stable@vger.kernel.org
+Reported-by: xingwei lee <xrivendell7@gmail.com>
+Signed-off-by: Jens Axboe <axboe@kernel.dk>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ io_uring/io_uring.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/io_uring/io_uring.c
++++ b/io_uring/io_uring.c
+@@ -3485,14 +3485,17 @@ static inline int io_rw_prep_async(struc
+ struct iovec *iov = iorw->fast_iov;
+ int ret;
+
++ iorw->bytes_done = 0;
++ iorw->free_iovec = NULL;
++
+ ret = io_import_iovec(rw, req, &iov, &iorw->iter, false);
+ if (unlikely(ret < 0))
+ return ret;
+
+- iorw->bytes_done = 0;
+- iorw->free_iovec = iov;
+- if (iov)
++ if (iov) {
++ iorw->free_iovec = iov;
+ req->flags |= REQ_F_NEED_CLEANUP;
++ }
+ iov_iter_save_state(&iorw->iter, &iorw->iter_state);
+ return 0;
+ }
--- /dev/null
+From 9320fc509b87b4d795fb37112931e2f4f8b5c55f Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Uwe=20Kleine-K=C3=B6nig?= <u.kleine-koenig@pengutronix.de>
+Date: Sat, 6 Jan 2024 15:13:03 +0100
+Subject: pwm: jz4740: Don't use dev_err_probe() in .request()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+From: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+
+commit 9320fc509b87b4d795fb37112931e2f4f8b5c55f upstream.
+
+dev_err_probe() is only supposed to be used in probe functions. While it
+probably doesn't hurt, both the EPROBE_DEFER handling and calling
+device_set_deferred_probe_reason() are conceptually wrong in the request
+callback. So replace the call by dev_err() and a separate return
+statement.
+
+This effectively reverts commit c0bfe9606e03 ("pwm: jz4740: Simplify
+with dev_err_probe()").
+
+Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
+Link: https://lore.kernel.org/r/20240106141302.1253365-2-u.kleine-koenig@pengutronix.de
+Fixes: c0bfe9606e03 ("pwm: jz4740: Simplify with dev_err_probe()")
+Cc: stable@vger.kernel.org
+Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ drivers/pwm/pwm-jz4740.c | 7 ++++---
+ 1 file changed, 4 insertions(+), 3 deletions(-)
+
+--- a/drivers/pwm/pwm-jz4740.c
++++ b/drivers/pwm/pwm-jz4740.c
+@@ -60,9 +60,10 @@ static int jz4740_pwm_request(struct pwm
+ snprintf(name, sizeof(name), "timer%u", pwm->hwpwm);
+
+ clk = clk_get(chip->dev, name);
+- if (IS_ERR(clk))
+- return dev_err_probe(chip->dev, PTR_ERR(clk),
+- "Failed to get clock\n");
++ if (IS_ERR(clk)) {
++ dev_err(chip->dev, "error %pe: Failed to get clock\n", clk);
++ return PTR_ERR(clk);
++ }
+
+ err = clk_prepare_enable(clk);
+ if (err < 0) {
--- /dev/null
+From 21528c69a0d8483f7c6345b1a0bc8d8975e9a172 Mon Sep 17 00:00:00 2001
+From: Stefan Berger <stefanb@linux.ibm.com>
+Date: Sun, 19 Nov 2023 20:12:48 -0500
+Subject: rootfs: Fix support for rootfstype= when root= is given
+
+From: Stefan Berger <stefanb@linux.ibm.com>
+
+commit 21528c69a0d8483f7c6345b1a0bc8d8975e9a172 upstream.
+
+Documentation/filesystems/ramfs-rootfs-initramfs.rst states:
+
+ If CONFIG_TMPFS is enabled, rootfs will use tmpfs instead of ramfs by
+ default. To force ramfs, add "rootfstype=ramfs" to the kernel command
+ line.
+
+This currently does not work when root= is provided since then
+saved_root_name contains a string and rootfstype= is ignored. Therefore,
+ramfs is currently always chosen when root= is provided.
+
+The current behavior for rootfs's filesystem is:
+
+ root= | rootfstype= | chosen rootfs filesystem
+ ------------+-------------+--------------------------
+ unspecified | unspecified | tmpfs
+ unspecified | tmpfs | tmpfs
+ unspecified | ramfs | ramfs
+ provided | ignored | ramfs
+
+rootfstype= should be respected regardless whether root= is given,
+as shown below:
+
+ root= | rootfstype= | chosen rootfs filesystem
+ ------------+-------------+--------------------------
+ unspecified | unspecified | tmpfs (as before)
+ unspecified | tmpfs | tmpfs (as before)
+ unspecified | ramfs | ramfs (as before)
+ provided | unspecified | ramfs (compatibility with before)
+ provided | tmpfs | tmpfs (new)
+ provided | ramfs | ramfs (new)
+
+This table represents the new behavior.
+
+Fixes: 6e19eded3684 ("initmpfs: use initramfs if rootfstype= or root= specified")
+Cc: <stable@vger.kernel.org>
+Signed-off-by: Rob Landley <rob@landley.net>
+Link: https://lore.kernel.org/lkml/8244c75f-445e-b15b-9dbf-266e7ca666e2@landley.net/
+Reviewed-and-Tested-by: Mimi Zohar <zohar@linux.ibm.com>
+Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
+Link: https://lore.kernel.org/r/20231120011248.396012-1-stefanb@linux.ibm.com
+Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+---
+ init/do_mounts.c | 9 ++++++---
+ 1 file changed, 6 insertions(+), 3 deletions(-)
+
+--- a/init/do_mounts.c
++++ b/init/do_mounts.c
+@@ -649,7 +649,10 @@ struct file_system_type rootfs_fs_type =
+
+ void __init init_rootfs(void)
+ {
+- if (IS_ENABLED(CONFIG_TMPFS) && !saved_root_name[0] &&
+- (!root_fs_names || strstr(root_fs_names, "tmpfs")))
+- is_tmpfs = true;
++ if (IS_ENABLED(CONFIG_TMPFS)) {
++ if (!saved_root_name[0] && !root_fs_names)
++ is_tmpfs = true;
++ else if (root_fs_names && !!strstr(root_fs_names, "tmpfs"))
++ is_tmpfs = true;
++ }
+ }
serial-imx-ensure-that-imx_uart_rs485_config-is-called-with-enabled-clock.patch
alsa-oxygen-fix-right-channel-of-capture-volume-mixer.patch
alsa-hda-relatek-enable-mute-led-on-hp-laptop-15s-fq2xxx.patch
+fbdev-flush-deferred-work-in-fb_deferred_io_fsync.patch
+pwm-jz4740-don-t-use-dev_err_probe-in-.request.patch
+io_uring-rw-ensure-io-bytes_done-is-always-initialized.patch
+rootfs-fix-support-for-rootfstype-when-root-is-given.patch
+bluetooth-fix-atomicity-violation-in-min-max-_key_size_set.patch
projects / thirdparty / kernel / stable-queue.git / commitdiff
