- Linux-stable-mirror - lists.linaro.org

[PATCH AUTOSEL 5.15 01/12] md/md-bitmap: fix dm-raid max_write_behind setting

by Sasha Levin

From: Yu Kuai <yukuai3(a)huawei.com> [ Upstream commit 2afe17794cfed5f80295b1b9facd66e6f65e5002 ] It's supposed to be COUNTER_MAX / 2, not COUNTER_MAX. Link: https://lore.kernel.org/linux-raid/20250524061320.370630-14-yukuai1@huaweic… Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now I have a clear understanding. Let me analyze the specific code change in the commit: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Analysis of the Bug Fix ### 1. The Bug The code in `md_bitmap_new_disk_sb()` incorrectly validates `write_behind` against `COUNTER_MAX` instead of `COUNTER_MAX / 2`: ```c - if (write_behind > COUNTER_MAX) + if (write_behind > COUNTER_MAX / 2) write_behind = COUNTER_MAX / 2; ``` ### 2. Why This is a Real Bug The comment immediately above this code explicitly states: ```c /* - FIXME: write_behind for RAID1. If not specified, what - is a good choice? We choose COUNTER_MAX / 2 arbitrarily. */ ``` The intent is clearly to limit write_behind to `COUNTER_MAX / 2`, but the validation check was incorrectly comparing against `COUNTER_MAX`. This creates an inconsistency where: - Values between `COUNTER_MAX / 2` and `COUNTER_MAX` would pass the check - But then get clamped to `COUNTER_MAX / 2` anyway - This means the validation isn't serving its intended purpose ### 3. Impact on Users This bug affects: - **dm-raid users**: When creating new bitmap superblocks for RAID arrays with write-behind configured - **Data consistency**: While not causing data corruption, it creates confusion about the actual limits - **Configuration validation**: Users might set values that appear to be accepted but are silently reduced ### 4. Consistency with Other Code The fix aligns with the pattern used elsewhere: - In `dm-raid.c`: The validation correctly checks `value / 2 > COUNTER_MAX` (equivalent check for sector-based values) - The clamping value of `COUNTER_MAX / 2` is consistently used as the default throughout the codebase ### 5. Backport Criteria This commit meets the stable kernel backport criteria: - **It fixes a bug**: Incorrect validation logic that doesn't match the intended behavior - **Simple and contained**: One-line change with minimal risk - **Clear fix**: The correct value is obvious from the surrounding code and comment - **User-visible impact**: Affects configuration validation for dm-raid users ### 6. Similar Historical Commits Looking at the similar commits provided: - Commit #1 (backported): Added validation to prevent setting max_write_behind without write-mostly devices - Commit #4 (backported): Fixed missing bitmap updates with write-mostly devices Both of these were backported and dealt with correctness issues in the write-behind functionality, establishing a pattern that such fixes are considered stable-worthy. ### 7. Risk Assessment - **Low risk**: Single character change ('/' to '/ 2') - **Well-understood**: The correct limit is documented in the comment - **No ABI changes**: Just tightens an existing validation check - **Fail-safe**: Makes the validation more restrictive, not less ## Conclusion This is a clear bug fix that corrects an incorrect validation check to match the documented and intended behavior. The fix is trivial, safe, and addresses a real issue that affects dm-raid users. It should be backported to ensure consistent behavior across stable kernel versions. drivers/md/md-bitmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c index b26e22dd9ba2e..cb84a4ab8d70f 100644 --- a/drivers/md/md-bitmap.c +++ b/drivers/md/md-bitmap.c @@ -546,7 +546,7 @@ static int md_bitmap_new_disk_sb(struct bitmap *bitmap) * is a good choice? We choose COUNTER_MAX / 2 arbitrarily. */ write_behind = bitmap->mddev->bitmap_info.max_write_behind; - if (write_behind > COUNTER_MAX) + if (write_behind > COUNTER_MAX / 2) write_behind = COUNTER_MAX / 2; sb->write_behind = cpu_to_le32(write_behind); bitmap->mddev->bitmap_info.max_write_behind = write_behind; -- 2.39.5

4 weeks

1
11
0 0

[PATCH AUTOSEL 6.1 01/16] md/md-bitmap: fix dm-raid max_write_behind setting

by Sasha Levin

From: Yu Kuai <yukuai3(a)huawei.com> [ Upstream commit 2afe17794cfed5f80295b1b9facd66e6f65e5002 ] It's supposed to be COUNTER_MAX / 2, not COUNTER_MAX. Link: https://lore.kernel.org/linux-raid/20250524061320.370630-14-yukuai1@huaweic… Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now I have a clear understanding. Let me analyze the specific code change in the commit: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Analysis of the Bug Fix ### 1. The Bug The code in `md_bitmap_new_disk_sb()` incorrectly validates `write_behind` against `COUNTER_MAX` instead of `COUNTER_MAX / 2`: ```c - if (write_behind > COUNTER_MAX) + if (write_behind > COUNTER_MAX / 2) write_behind = COUNTER_MAX / 2; ``` ### 2. Why This is a Real Bug The comment immediately above this code explicitly states: ```c /* - FIXME: write_behind for RAID1. If not specified, what - is a good choice? We choose COUNTER_MAX / 2 arbitrarily. */ ``` The intent is clearly to limit write_behind to `COUNTER_MAX / 2`, but the validation check was incorrectly comparing against `COUNTER_MAX`. This creates an inconsistency where: - Values between `COUNTER_MAX / 2` and `COUNTER_MAX` would pass the check - But then get clamped to `COUNTER_MAX / 2` anyway - This means the validation isn't serving its intended purpose ### 3. Impact on Users This bug affects: - **dm-raid users**: When creating new bitmap superblocks for RAID arrays with write-behind configured - **Data consistency**: While not causing data corruption, it creates confusion about the actual limits - **Configuration validation**: Users might set values that appear to be accepted but are silently reduced ### 4. Consistency with Other Code The fix aligns with the pattern used elsewhere: - In `dm-raid.c`: The validation correctly checks `value / 2 > COUNTER_MAX` (equivalent check for sector-based values) - The clamping value of `COUNTER_MAX / 2` is consistently used as the default throughout the codebase ### 5. Backport Criteria This commit meets the stable kernel backport criteria: - **It fixes a bug**: Incorrect validation logic that doesn't match the intended behavior - **Simple and contained**: One-line change with minimal risk - **Clear fix**: The correct value is obvious from the surrounding code and comment - **User-visible impact**: Affects configuration validation for dm-raid users ### 6. Similar Historical Commits Looking at the similar commits provided: - Commit #1 (backported): Added validation to prevent setting max_write_behind without write-mostly devices - Commit #4 (backported): Fixed missing bitmap updates with write-mostly devices Both of these were backported and dealt with correctness issues in the write-behind functionality, establishing a pattern that such fixes are considered stable-worthy. ### 7. Risk Assessment - **Low risk**: Single character change ('/' to '/ 2') - **Well-understood**: The correct limit is documented in the comment - **No ABI changes**: Just tightens an existing validation check - **Fail-safe**: Makes the validation more restrictive, not less ## Conclusion This is a clear bug fix that corrects an incorrect validation check to match the documented and intended behavior. The fix is trivial, safe, and addresses a real issue that affects dm-raid users. It should be backported to ensure consistent behavior across stable kernel versions. drivers/md/md-bitmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c index 02629516748e4..dac27206cd3df 100644 --- a/drivers/md/md-bitmap.c +++ b/drivers/md/md-bitmap.c @@ -546,7 +546,7 @@ static int md_bitmap_new_disk_sb(struct bitmap *bitmap) * is a good choice? We choose COUNTER_MAX / 2 arbitrarily. */ write_behind = bitmap->mddev->bitmap_info.max_write_behind; - if (write_behind > COUNTER_MAX) + if (write_behind > COUNTER_MAX / 2) write_behind = COUNTER_MAX / 2; sb->write_behind = cpu_to_le32(write_behind); bitmap->mddev->bitmap_info.max_write_behind = write_behind; -- 2.39.5

4 weeks

1
15
0 0

[PATCH AUTOSEL 6.6 01/18] md/md-bitmap: fix dm-raid max_write_behind setting

by Sasha Levin

From: Yu Kuai <yukuai3(a)huawei.com> [ Upstream commit 2afe17794cfed5f80295b1b9facd66e6f65e5002 ] It's supposed to be COUNTER_MAX / 2, not COUNTER_MAX. Link: https://lore.kernel.org/linux-raid/20250524061320.370630-14-yukuai1@huaweic… Signed-off-by: Yu Kuai <yukuai3(a)huawei.com> Reviewed-by: Christoph Hellwig <hch(a)lst.de> Reviewed-by: Hannes Reinecke <hare(a)suse.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Now I have a clear understanding. Let me analyze the specific code change in the commit: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Analysis of the Bug Fix ### 1. The Bug The code in `md_bitmap_new_disk_sb()` incorrectly validates `write_behind` against `COUNTER_MAX` instead of `COUNTER_MAX / 2`: ```c - if (write_behind > COUNTER_MAX) + if (write_behind > COUNTER_MAX / 2) write_behind = COUNTER_MAX / 2; ``` ### 2. Why This is a Real Bug The comment immediately above this code explicitly states: ```c /* - FIXME: write_behind for RAID1. If not specified, what - is a good choice? We choose COUNTER_MAX / 2 arbitrarily. */ ``` The intent is clearly to limit write_behind to `COUNTER_MAX / 2`, but the validation check was incorrectly comparing against `COUNTER_MAX`. This creates an inconsistency where: - Values between `COUNTER_MAX / 2` and `COUNTER_MAX` would pass the check - But then get clamped to `COUNTER_MAX / 2` anyway - This means the validation isn't serving its intended purpose ### 3. Impact on Users This bug affects: - **dm-raid users**: When creating new bitmap superblocks for RAID arrays with write-behind configured - **Data consistency**: While not causing data corruption, it creates confusion about the actual limits - **Configuration validation**: Users might set values that appear to be accepted but are silently reduced ### 4. Consistency with Other Code The fix aligns with the pattern used elsewhere: - In `dm-raid.c`: The validation correctly checks `value / 2 > COUNTER_MAX` (equivalent check for sector-based values) - The clamping value of `COUNTER_MAX / 2` is consistently used as the default throughout the codebase ### 5. Backport Criteria This commit meets the stable kernel backport criteria: - **It fixes a bug**: Incorrect validation logic that doesn't match the intended behavior - **Simple and contained**: One-line change with minimal risk - **Clear fix**: The correct value is obvious from the surrounding code and comment - **User-visible impact**: Affects configuration validation for dm-raid users ### 6. Similar Historical Commits Looking at the similar commits provided: - Commit #1 (backported): Added validation to prevent setting max_write_behind without write-mostly devices - Commit #4 (backported): Fixed missing bitmap updates with write-mostly devices Both of these were backported and dealt with correctness issues in the write-behind functionality, establishing a pattern that such fixes are considered stable-worthy. ### 7. Risk Assessment - **Low risk**: Single character change ('/' to '/ 2') - **Well-understood**: The correct limit is documented in the comment - **No ABI changes**: Just tightens an existing validation check - **Fail-safe**: Makes the validation more restrictive, not less ## Conclusion This is a clear bug fix that corrects an incorrect validation check to match the documented and intended behavior. The fix is trivial, safe, and addresses a real issue that affects dm-raid users. It should be backported to ensure consistent behavior across stable kernel versions. drivers/md/md-bitmap.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/md/md-bitmap.c b/drivers/md/md-bitmap.c index 8317e07b326d0..21decb97bc050 100644 --- a/drivers/md/md-bitmap.c +++ b/drivers/md/md-bitmap.c @@ -589,7 +589,7 @@ static int md_bitmap_new_disk_sb(struct bitmap *bitmap) * is a good choice? We choose COUNTER_MAX / 2 arbitrarily. */ write_behind = bitmap->mddev->bitmap_info.max_write_behind; - if (write_behind > COUNTER_MAX) + if (write_behind > COUNTER_MAX / 2) write_behind = COUNTER_MAX / 2; sb->write_behind = cpu_to_le32(write_behind); bitmap->mddev->bitmap_info.max_write_behind = write_behind; -- 2.39.5

4 weeks

1
17
0 0

[PATCH AUTOSEL 6.12 01/23] nvme-tcp: fix I/O stalls on congested sockets

by Sasha Levin

From: Hannes Reinecke <hare(a)kernel.org> [ Upstream commit f42d4796ee100fade86086d1cf98537fb4d326c8 ] When the socket is busy processing nvme_tcp_try_recv() might return -EAGAIN, but this doesn't automatically imply that the sending side is blocked, too. So check if there are pending requests once nvme_tcp_try_recv() returns -EAGAIN and continue with the sending loop to avoid I/O stalls. Signed-off-by: Hannes Reinecke <hare(a)kernel.org> Acked-by: Chris Leech <cleech(a)redhat.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Based on my analysis of the commit and comparison with similar commits, here is my determination: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a real user-impacting bug**: The commit addresses I/O stalls on congested sockets, which is a serious issue that can cause system hangs or severe performance degradation. When the socket is congested and `nvme_tcp_try_recv()` returns -EAGAIN, the current code incorrectly assumes that the sending side is also blocked, leading to I/O stalls. 2. **Small and contained fix**: The changes are minimal and localized to the `nvme_tcp_io_work()` function: - Changes `nvme_tcp_try_recv()` to return 0 instead of -EAGAIN to prevent premature exit - Adds a check after receive processing to see if the socket became writable - Only 5 lines of actual code changes 3. **Clear logic fix**: The patch addresses a specific logic error where: - The receive side returns -EAGAIN (socket would block on receive) - But this doesn't mean the send side is also blocked - The fix checks if there are pending requests and if the socket is writable after receive processing 4. **Similar to other backported fixes**: Looking at the historical commits: - Commit #2 (backported): Fixed hangs waiting for icresp response - Commit #3 (backported): Fixed wrong stop condition in io_work - Commit #4 (backported): Fixed UAF when detecting digest errors - Commit #5 (backported): Fixed possible null deref on timed out connections All these commits that were backported involved fixing hangs, stalls, or error conditions in the nvme-tcp driver. 5. **No architectural changes**: The commit doesn't introduce new features or change the architecture. It simply adds a missing check to prevent I/O stalls, which aligns with stable kernel criteria. 6. **Critical subsystem**: NVMe-TCP is used for storage access, and I/O stalls can have severe consequences for system stability and data integrity. The specific code changes show: - `return consumed == -EAGAIN ? 0 : consumed;` - prevents treating EAGAIN as an error - The new check `if (nvme_tcp_queue_has_pending(queue) && sk_stream_is_writeable(queue->sock->sk))` ensures that if there are pending requests and the socket is writable after receive processing, we continue processing instead of stalling. This is exactly the type of bug fix that should be backported to stable kernels to ensure reliable storage operation. drivers/nvme/host/tcp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c index 4cc72be28c731..13ede6e309092 100644 --- a/drivers/nvme/host/tcp.c +++ b/drivers/nvme/host/tcp.c @@ -1349,7 +1349,7 @@ static int nvme_tcp_try_recv(struct nvme_tcp_queue *queue) queue->nr_cqe = 0; consumed = sock->ops->read_sock(sk, &rd_desc, nvme_tcp_recv_skb); release_sock(sk); - return consumed; + return consumed == -EAGAIN ? 0 : consumed; } static void nvme_tcp_io_work(struct work_struct *w) @@ -1377,6 +1377,11 @@ static void nvme_tcp_io_work(struct work_struct *w) else if (unlikely(result < 0)) return; + /* did we get some space after spending time in recv? */ + if (nvme_tcp_queue_has_pending(queue) && + sk_stream_is_writeable(queue->sock->sk)) + pending = true; + if (!pending || !queue->rd_enabled) return; -- 2.39.5

4 weeks

1
22
0 0

[PATCH AUTOSEL 6.14 01/29] nvme-tcp: fix I/O stalls on congested sockets

by Sasha Levin

From: Hannes Reinecke <hare(a)kernel.org> [ Upstream commit f42d4796ee100fade86086d1cf98537fb4d326c8 ] When the socket is busy processing nvme_tcp_try_recv() might return -EAGAIN, but this doesn't automatically imply that the sending side is blocked, too. So check if there are pending requests once nvme_tcp_try_recv() returns -EAGAIN and continue with the sending loop to avoid I/O stalls. Signed-off-by: Hannes Reinecke <hare(a)kernel.org> Acked-by: Chris Leech <cleech(a)redhat.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Christoph Hellwig <hch(a)lst.de> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Based on my analysis of the commit and comparison with similar commits, here is my determination: **YES** This commit should be backported to stable kernel trees for the following reasons: 1. **Fixes a real user-impacting bug**: The commit addresses I/O stalls on congested sockets, which is a serious issue that can cause system hangs or severe performance degradation. When the socket is congested and `nvme_tcp_try_recv()` returns -EAGAIN, the current code incorrectly assumes that the sending side is also blocked, leading to I/O stalls. 2. **Small and contained fix**: The changes are minimal and localized to the `nvme_tcp_io_work()` function: - Changes `nvme_tcp_try_recv()` to return 0 instead of -EAGAIN to prevent premature exit - Adds a check after receive processing to see if the socket became writable - Only 5 lines of actual code changes 3. **Clear logic fix**: The patch addresses a specific logic error where: - The receive side returns -EAGAIN (socket would block on receive) - But this doesn't mean the send side is also blocked - The fix checks if there are pending requests and if the socket is writable after receive processing 4. **Similar to other backported fixes**: Looking at the historical commits: - Commit #2 (backported): Fixed hangs waiting for icresp response - Commit #3 (backported): Fixed wrong stop condition in io_work - Commit #4 (backported): Fixed UAF when detecting digest errors - Commit #5 (backported): Fixed possible null deref on timed out connections All these commits that were backported involved fixing hangs, stalls, or error conditions in the nvme-tcp driver. 5. **No architectural changes**: The commit doesn't introduce new features or change the architecture. It simply adds a missing check to prevent I/O stalls, which aligns with stable kernel criteria. 6. **Critical subsystem**: NVMe-TCP is used for storage access, and I/O stalls can have severe consequences for system stability and data integrity. The specific code changes show: - `return consumed == -EAGAIN ? 0 : consumed;` - prevents treating EAGAIN as an error - The new check `if (nvme_tcp_queue_has_pending(queue) && sk_stream_is_writeable(queue->sock->sk))` ensures that if there are pending requests and the socket is writable after receive processing, we continue processing instead of stalling. This is exactly the type of bug fix that should be backported to stable kernels to ensure reliable storage operation. drivers/nvme/host/tcp.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c index d991baa82a1c2..a2e825e37b38b 100644 --- a/drivers/nvme/host/tcp.c +++ b/drivers/nvme/host/tcp.c @@ -1349,7 +1349,7 @@ static int nvme_tcp_try_recv(struct nvme_tcp_queue *queue) queue->nr_cqe = 0; consumed = sock->ops->read_sock(sk, &rd_desc, nvme_tcp_recv_skb); release_sock(sk); - return consumed; + return consumed == -EAGAIN ? 0 : consumed; } static void nvme_tcp_io_work(struct work_struct *w) @@ -1377,6 +1377,11 @@ static void nvme_tcp_io_work(struct work_struct *w) else if (unlikely(result < 0)) return; + /* did we get some space after spending time in recv? */ + if (nvme_tcp_queue_has_pending(queue) && + sk_stream_is_writeable(queue->sock->sk)) + pending = true; + if (!pending || !queue->rd_enabled) return; -- 2.39.5

4 weeks

1
28
0 0

[PATCH AUTOSEL 6.15 01/35] wifi: iwlwifi: mld: Move regulatory domain initialization

by Sasha Levin

From: Ilan Peer <ilan.peer(a)intel.com> [ Upstream commit f81aa834bfa91c827f290b62a245e23c5ad2813c ] The regulatory domain information was initialized every time the FW was loaded and the device was restarted. This was unnecessary and useless as at this stage the wiphy channels information was not setup yet so while the regulatory domain was set to the wiphy, the channel information was not updated. In case that a specific MCC was configured during FW initialization then following updates with this MCC are ignored, and thus the wiphy channels information is left with information not matching the regulatory domain. This commit moves the regulatory domain initialization to after the operational firmware is started, i.e., after the wiphy channels were configured and the regulatory information is needed. Signed-off-by: Ilan Peer <ilan.peer(a)intel.com> Reviewed-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> Link: https://patch.msgid.link/20250604061200.f138a7382093.I2fd8b3e99be13c2687da4… Signed-off-by: Miri Korenblit <miriam.rachel.korenblit(a)intel.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Bug Fix Nature The commit fixes a real bug where regulatory domain information and wiphy channel configurations become mismatched. Specifically, from the commit message: 1. **Timing Issue**: The regulatory domain was being initialized in `iwl_mld_load_fw()` before wiphy channels were properly configured 2. **Update Failures**: When a specific MCC (Mobile Country Code) was configured during FW initialization, subsequent updates with the same MCC would be ignored, leaving channel information inconsistent with the regulatory domain ## Code Analysis The changes are minimal and low-risk: - **Removed from `iwl_mld_load_fw()`**: Lines removing the `iwl_mld_init_mcc()` call and its error handling - **Added to `iwl_mld_start_fw()`**: The same call is added after `iwl_mld_config_fw()`, ensuring proper initialization order ## Comparison with Similar Commits Most relevant is Similar Commit #4 (marked YES for backporting), which addressed regulatory domain update issues when firmware starts. That commit fixed the handling of `MCC_RESP_ILLEGAL` responses to ensure channel lists were properly updated - a closely related regulatory compliance issue. ## Stable Kernel Criteria This commit meets the stable kernel requirements: 1. **Fixes a real bug**: Regulatory domain/channel mismatch is a serious issue affecting wireless compliance 2. **Small and contained**: Only moves a function call to the correct initialization sequence 3. **Low regression risk**: No new logic introduced, just reordering existing initialization 4. **Important functionality**: Regulatory compliance is critical for legal wireless operation 5. **Clear root cause**: The issue and fix are well-understood and documented ## Repository Context From examining the kernel repository, I found that regulatory domain initialization has been an ongoing concern in iwlwifi, with multiple fixes addressing timing and synchronization issues. The `lar_regdom_set` flag is critical for preventing operations (like scans) before regulatory setup is complete. The fix ensures that `iwl_mld_init_mcc()` is called after the firmware is fully configured (`iwl_mld_config_fw()`), which is the proper time when wiphy channels are set up and ready to receive regulatory updates. This is precisely the type of bug fix that stable kernels should receive - it corrects a specific functional issue without introducing architectural changes or new features. drivers/net/wireless/intel/iwlwifi/mld/fw.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/net/wireless/intel/iwlwifi/mld/fw.c b/drivers/net/wireless/intel/iwlwifi/mld/fw.c index 4b083d447ee2f..6be9366bd4b14 100644 --- a/drivers/net/wireless/intel/iwlwifi/mld/fw.c +++ b/drivers/net/wireless/intel/iwlwifi/mld/fw.c @@ -339,10 +339,6 @@ int iwl_mld_load_fw(struct iwl_mld *mld) if (ret) goto err; - ret = iwl_mld_init_mcc(mld); - if (ret) - goto err; - mld->fw_status.running = true; return 0; @@ -535,6 +531,10 @@ int iwl_mld_start_fw(struct iwl_mld *mld) if (ret) goto error; + ret = iwl_mld_init_mcc(mld); + if (ret) + goto error; + return 0; error: -- 2.39.5

4 weeks

1
34
0 0

[PATCH 5.15 v3 00/16] ITS mitigation

by Pawan Gupta

v3: - Added patches: x86/its: Fix build errors when CONFIG_MODULES=n x86/its: FineIBT-paranoid vs ITS v2: - Added missing patch to 6.1 backport. This is a backport of mitigation for Indirect Target Selection (ITS). ITS is a bug in some Intel CPUs that affects indirect branches including RETs in the first half of a cacheline. Mitigation is to relocate the affected branches to an ITS-safe thunk. Below additional upstream commits are required to cover some of the special cases like indirects in asm and returns in static calls: cfceff8526a4 ("x86/speculation: Simplify and make CALL_NOSPEC consistent") 052040e34c08 ("x86/speculation: Add a conditional CS prefix to CALL_NOSPEC") c8c81458863a ("x86/speculation: Remove the extra #ifdef around CALL_NOSPEC") d2408e043e72 ("x86/alternative: Optimize returns patching") 4ba89dd6ddec ("x86/alternatives: Remove faulty optimization") [1] https://github.com/torvalds/linux/commit/6f5bf947bab06f37ff931c359fd5770c4d… --- Borislav Petkov (AMD) (1): x86/alternative: Optimize returns patching Eric Biggers (1): x86/its: Fix build errors when CONFIG_MODULES=n Josh Poimboeuf (1): x86/alternatives: Remove faulty optimization Pawan Gupta (10): x86/speculation: Simplify and make CALL_NOSPEC consistent x86/speculation: Add a conditional CS prefix to CALL_NOSPEC x86/speculation: Remove the extra #ifdef around CALL_NOSPEC Documentation: x86/bugs/its: Add ITS documentation x86/its: Enumerate Indirect Target Selection (ITS) bug x86/its: Add support for ITS-safe indirect thunk x86/its: Add support for ITS-safe return thunk x86/its: Enable Indirect Target Selection mitigation x86/its: Add "vmexit" option to skip mitigation on some CPUs x86/its: Align RETs in BHB clear sequence to avoid thunking Peter Zijlstra (3): x86,nospec: Simplify {JMP,CALL}_NOSPEC x86/its: Use dynamic thunks for indirect branches x86/its: FineIBT-paranoid vs ITS Documentation/ABI/testing/sysfs-devices-system-cpu | 1 + Documentation/admin-guide/hw-vuln/index.rst | 1 + .../hw-vuln/indirect-target-selection.rst | 156 +++++++++++++ Documentation/admin-guide/kernel-parameters.txt | 15 ++ arch/x86/Kconfig | 11 + arch/x86/entry/entry_64.S | 20 +- arch/x86/include/asm/alternative.h | 32 +++ arch/x86/include/asm/cpufeatures.h | 3 + arch/x86/include/asm/msr-index.h | 8 + arch/x86/include/asm/nospec-branch.h | 57 +++-- arch/x86/kernel/alternative.c | 243 ++++++++++++++++++++- arch/x86/kernel/cpu/bugs.c | 139 +++++++++++- arch/x86/kernel/cpu/common.c | 63 +++++- arch/x86/kernel/ftrace.c | 2 +- arch/x86/kernel/module.c | 7 + arch/x86/kernel/static_call.c | 2 +- arch/x86/kernel/vmlinux.lds.S | 10 + arch/x86/kvm/x86.c | 4 +- arch/x86/lib/retpoline.S | 39 ++++ arch/x86/net/bpf_jit_comp.c | 8 +- drivers/base/cpu.c | 8 + include/linux/cpu.h | 2 + include/linux/module.h | 5 + 23 files changed, 793 insertions(+), 43 deletions(-) --- change-id: 20250512-its-5-15-0e0385221e32

4 weeks

3
34
0 0

[PATCH 6.14 00/24] 6.14.11-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.14.11 release. There are 24 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon, 09 Jun 2025 10:07:05 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.14.11-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.14.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 6.14.11-rc1 Aurabindo Pillai <aurabindo.pillai(a)amd.com> Revert "drm/amd/display: more liberal vmin/vmax update for freesync" Xu Yang <xu.yang_2(a)nxp.com> dt-bindings: phy: imx8mq-usb: fix fsl,phy-tx-vboost-level-microvolt property Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> dt-bindings: usb: cypress,hx3: Add support for all variants David Lechner <dlechner(a)baylibre.com> dt-bindings: pwm: adi,axi-pwmgen: Fix clocks Sergey Senozhatsky <senozhatsky(a)chromium.org> thunderbolt: Do not double dequeue a configuration request Carlos Llamas <cmllamas(a)google.com> binder: fix yet another UAF in binder_devices Dmitry Antipov <dmantipov(a)yandex.ru> binder: fix use-after-free in binderfs_evict_inode() Dave Penkler <dpenkler(a)gmail.com> usb: usbtmc: Fix timeout value in get_stb Arnd Bergmann <arnd(a)arndb.de> nvmem: rmem: select CONFIG_CRC32 Dustin Lundquist <dustin(a)null-ptr.net> serial: jsm: fix NPE during jsm_uart_port_init Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Bluetooth: hci_qca: move the SoC type check to the right place Qasim Ijaz <qasdev00(a)gmail.com> usb: typec: ucsi: fix Clang -Wsign-conversion warning Charles Yeh <charlesyeh522(a)gmail.com> USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB Hongyu Xie <xiehongyu1(a)kylinos.cn> usb: storage: Ignore UAS driver for SanDisk 3.2 Gen2 storage device Jiayi Li <lijiayi(a)kylinos.cn> usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE Mike Marshall <hubcap(a)omnibond.com> orangefs: adjust counting code to recover from 665575cf Alexandre Mergnat <amergnat(a)baylibre.com> rtc: Fix offset calculation for .start_secs < 0 Alexandre Mergnat <amergnat(a)baylibre.com> rtc: Make rtc_time64_to_tm() support dates before 1970 Sakari Ailus <sakari.ailus(a)linux.intel.com> Documentation: ACPI: Use all-string data node references Gautham R. Shenoy <gautham.shenoy(a)amd.com> acpi-cpufreq: Fix nominal_freq units to KHz in get_max_boost_ratio() Pritam Manohar Sutar <pritam.sutar(a)samsung.com> clk: samsung: correct clock summary for hsi1 block Gabor Juhos <j4g8y7(a)gmail.com> pinctrl: armada-37xx: set GPIO output value before setting direction Gabor Juhos <j4g8y7(a)gmail.com> pinctrl: armada-37xx: use correct OUTPUT_VAL register for GPIOs > 31 Pan Taixi <pantaixi(a)huaweicloud.com> tracing: Fix compilation warning on arm32 ------------- Diffstat: .../bindings/phy/fsl,imx8mq-usb-phy.yaml | 3 +-- .../devicetree/bindings/pwm/adi,axi-pwmgen.yaml | 13 +++++++++-- .../devicetree/bindings/usb/cypress,hx3.yaml | 19 +++++++++++++--- .../acpi/dsd/data-node-references.rst | 26 ++++++++++------------ Documentation/firmware-guide/acpi/dsd/graph.rst | 11 ++++----- Documentation/firmware-guide/acpi/dsd/leds.rst | 7 +----- Makefile | 4 ++-- drivers/android/binder.c | 16 +++++++++++-- drivers/android/binder_internal.h | 8 +++++-- drivers/android/binderfs.c | 2 +- drivers/bluetooth/hci_qca.c | 14 ++++++------ drivers/clk/samsung/clk-exynosautov920.c | 2 +- drivers/cpufreq/acpi-cpufreq.c | 2 +- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 16 +++++-------- drivers/nvmem/Kconfig | 1 + drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 14 +++++++----- drivers/rtc/class.c | 2 +- drivers/rtc/lib.c | 24 +++++++++++++++----- drivers/thunderbolt/ctl.c | 5 +++++ drivers/tty/serial/jsm/jsm_tty.c | 1 + drivers/usb/class/usbtmc.c | 4 +++- drivers/usb/core/quirks.c | 3 +++ drivers/usb/serial/pl2303.c | 2 ++ drivers/usb/storage/unusual_uas.h | 7 ++++++ drivers/usb/typec/ucsi/ucsi.h | 2 +- fs/orangefs/inode.c | 9 ++++---- kernel/trace/trace.c | 2 +- 27 files changed, 139 insertions(+), 80 deletions(-)

4 weeks

8
31
0 0

[PATCH 6.12 00/24] 6.12.33-rc1 review

by Greg Kroah-Hartman

This is the start of the stable review cycle for the 6.12.33 release. There are 24 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know. Responses should be made by Mon, 09 Jun 2025 10:07:05 +0000. Anything received after that time might be too late. The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v6.x/stable-review/patch-6.12.33-rc… or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-6.12.y and the diffstat can be found below. thanks, greg k-h ------------- Pseudo-Shortlog of commits: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> Linux 6.12.33-rc1 Aurabindo Pillai <aurabindo.pillai(a)amd.com> Revert "drm/amd/display: more liberal vmin/vmax update for freesync" Xu Yang <xu.yang_2(a)nxp.com> dt-bindings: phy: imx8mq-usb: fix fsl,phy-tx-vboost-level-microvolt property Lukasz Czechowski <lukasz.czechowski(a)thaumatec.com> dt-bindings: usb: cypress,hx3: Add support for all variants Sergey Senozhatsky <senozhatsky(a)chromium.org> thunderbolt: Do not double dequeue a configuration request Dave Penkler <dpenkler(a)gmail.com> usb: usbtmc: Fix timeout value in get_stb Dustin Lundquist <dustin(a)null-ptr.net> serial: jsm: fix NPE during jsm_uart_port_init Bartosz Golaszewski <bartosz.golaszewski(a)linaro.org> Bluetooth: hci_qca: move the SoC type check to the right place Qasim Ijaz <qasdev00(a)gmail.com> usb: typec: ucsi: fix Clang -Wsign-conversion warning Charles Yeh <charlesyeh522(a)gmail.com> USB: serial: pl2303: add new chip PL2303GC-Q20 and PL2303GT-2AB Hongyu Xie <xiehongyu1(a)kylinos.cn> usb: storage: Ignore UAS driver for SanDisk 3.2 Gen2 storage device Jiayi Li <lijiayi(a)kylinos.cn> usb: quirks: Add NO_LPM quirk for SanDisk Extreme 55AE Jon Hunter <jonathanh(a)nvidia.com> Revert "cpufreq: tegra186: Share policy per cluster" Ming Lei <ming.lei(a)redhat.com> block: fix adding folio to bio Ajay Agarwal <ajayagarwal(a)google.com> PCI/ASPM: Disable L1 before disabling L1 PM Substates Karol Wachowski <karol.wachowski(a)intel.com> accel/ivpu: Update power island delays Maciej Falkowski <maciej.falkowski(a)linux.intel.com> accel/ivpu: Add initial Panther Lake support Alexandre Mergnat <amergnat(a)baylibre.com> rtc: Fix offset calculation for .start_secs < 0 Alexandre Mergnat <amergnat(a)baylibre.com> rtc: Make rtc_time64_to_tm() support dates before 1970 Sakari Ailus <sakari.ailus(a)linux.intel.com> Documentation: ACPI: Use all-string data node references Gautham R. Shenoy <gautham.shenoy(a)amd.com> acpi-cpufreq: Fix nominal_freq units to KHz in get_max_boost_ratio() Gabor Juhos <j4g8y7(a)gmail.com> pinctrl: armada-37xx: set GPIO output value before setting direction Gabor Juhos <j4g8y7(a)gmail.com> pinctrl: armada-37xx: use correct OUTPUT_VAL register for GPIOs > 31 Chao Yu <chao(a)kernel.org> f2fs: fix to avoid accessing uninitialized curseg Pan Taixi <pantaixi(a)huaweicloud.com> tracing: Fix compilation warning on arm32 ------------- Diffstat: .../bindings/phy/fsl,imx8mq-usb-phy.yaml | 3 +- .../devicetree/bindings/usb/cypress,hx3.yaml | 19 ++++- .../acpi/dsd/data-node-references.rst | 26 +++--- Documentation/firmware-guide/acpi/dsd/graph.rst | 11 +-- Documentation/firmware-guide/acpi/dsd/leds.rst | 7 +- Makefile | 4 +- block/bio.c | 11 ++- drivers/accel/ivpu/ivpu_drv.c | 1 + drivers/accel/ivpu/ivpu_drv.h | 10 ++- drivers/accel/ivpu/ivpu_fw.c | 3 + drivers/accel/ivpu/ivpu_hw_40xx_reg.h | 2 + drivers/accel/ivpu/ivpu_hw_ip.c | 49 +++++++---- drivers/bluetooth/hci_qca.c | 14 ++-- drivers/cpufreq/acpi-cpufreq.c | 2 +- drivers/cpufreq/tegra186-cpufreq.c | 7 -- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 16 ++-- drivers/pci/pcie/aspm.c | 94 ++++++++++++---------- drivers/pinctrl/mvebu/pinctrl-armada-37xx.c | 14 ++-- drivers/rtc/class.c | 2 +- drivers/rtc/lib.c | 24 ++++-- drivers/thunderbolt/ctl.c | 5 ++ drivers/tty/serial/jsm/jsm_tty.c | 1 + drivers/usb/class/usbtmc.c | 4 +- drivers/usb/core/quirks.c | 3 + drivers/usb/serial/pl2303.c | 2 + drivers/usb/storage/unusual_uas.h | 7 ++ drivers/usb/typec/ucsi/ucsi.h | 2 +- fs/f2fs/inode.c | 7 ++ fs/f2fs/segment.h | 9 ++- kernel/trace/trace.c | 2 +- 30 files changed, 218 insertions(+), 143 deletions(-)

4 weeks

9
32
0 0

[PATCH 5.10] tracing: Do not let histogram values have some modifiers

by Denis Arefev

From: "Steven Rostedt (Google)" <rostedt(a)goodmis.org> commit e0213434fe3e4a0d118923dc98d31e7ff1cd9e45 upstream. Histogram values can not be strings, stacktraces, graphs, symbols, syscalls, or grouped in buckets or log. Give an error if a value is set to do so. Note, the histogram code was not prepared to handle these modifiers for histograms and caused a bug. Mark Rutland reported: # echo 'p:copy_to_user __arch_copy_to_user n=$arg2' >> /sys/kernel/tracing/kprobe_events # echo 'hist:keys=n:vals=hitcount.buckets=8:sort=hitcount' > /sys/kernel/tracing/events/kprobes/copy_to_user/trigger # cat /sys/kernel/tracing/events/kprobes/copy_to_user/hist [ 143.694628] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 143.695190] Mem abort info: [ 143.695362] ESR = 0x0000000096000004 [ 143.695604] EC = 0x25: DABT (current EL), IL = 32 bits [ 143.695889] SET = 0, FnV = 0 [ 143.696077] EA = 0, S1PTW = 0 [ 143.696302] FSC = 0x04: level 0 translation fault [ 143.702381] Data abort info: [ 143.702614] ISV = 0, ISS = 0x00000004 [ 143.702832] CM = 0, WnR = 0 [ 143.703087] user pgtable: 4k pages, 48-bit VAs, pgdp=00000000448f9000 [ 143.703407] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 143.704137] Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP [ 143.704714] Modules linked in: [ 143.705273] CPU: 0 PID: 133 Comm: cat Not tainted 6.2.0-00003-g6fc512c10a7c #3 [ 143.706138] Hardware name: linux,dummy-virt (DT) [ 143.706723] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 143.707120] pc : hist_field_name.part.0+0x14/0x140 [ 143.707504] lr : hist_field_name.part.0+0x104/0x140 [ 143.707774] sp : ffff800008333a30 [ 143.707952] x29: ffff800008333a30 x28: 0000000000000001 x27: 0000000000400cc0 [ 143.708429] x26: ffffd7a653b20260 x25: 0000000000000000 x24: ffff10d303ee5800 [ 143.708776] x23: ffffd7a6539b27b0 x22: ffff10d303fb8c00 x21: 0000000000000001 [ 143.709127] x20: ffff10d303ec2000 x19: 0000000000000000 x18: 0000000000000000 [ 143.709478] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 [ 143.709824] x14: 0000000000000000 x13: 203a6f666e692072 x12: 6567676972742023 [ 143.710179] x11: 0a230a6d6172676f x10: 000000000000002c x9 : ffffd7a6521e018c [ 143.710584] x8 : 000000000000002c x7 : 7f7f7f7f7f7f7f7f x6 : 000000000000002c [ 143.710915] x5 : ffff10d303b0103e x4 : ffffd7a653b20261 x3 : 000000000000003d [ 143.711239] x2 : 0000000000020001 x1 : 0000000000000001 x0 : 0000000000000000 [ 143.711746] Call trace: [ 143.712115] hist_field_name.part.0+0x14/0x140 [ 143.712642] hist_field_name.part.0+0x104/0x140 [ 143.712925] hist_field_print+0x28/0x140 [ 143.713125] event_hist_trigger_print+0x174/0x4d0 [ 143.713348] hist_show+0xf8/0x980 [ 143.713521] seq_read_iter+0x1bc/0x4b0 [ 143.713711] seq_read+0x8c/0xc4 [ 143.713876] vfs_read+0xc8/0x2a4 [ 143.714043] ksys_read+0x70/0xfc [ 143.714218] __arm64_sys_read+0x24/0x30 [ 143.714400] invoke_syscall+0x50/0x120 [ 143.714587] el0_svc_common.constprop.0+0x4c/0x100 [ 143.714807] do_el0_svc+0x44/0xd0 [ 143.714970] el0_svc+0x2c/0x84 [ 143.715134] el0t_64_sync_handler+0xbc/0x140 [ 143.715334] el0t_64_sync+0x190/0x194 [ 143.715742] Code: a9bd7bfd 910003fd a90153f3 aa0003f3 (f9400000) [ 143.716510] ---[ end trace 0000000000000000 ]--- Segmentation fault Link: https://lkml.kernel.org/r/20230302020810.559462599@goodmis.org Cc: stable(a)vger.kernel.org Cc: Masami Hiramatsu <mhiramat(a)kernel.org> Cc: Andrew Morton <akpm(a)linux-foundation.org> Fixes: c6afad49d127f ("tracing: Add hist trigger 'sym' and 'sym-offset' modifiers") Reported-by: Mark Rutland <mark.rutland(a)arm.com> Tested-by: Mark Rutland <mark.rutland(a)arm.com> Signed-off-by: Steven Rostedt (Google) <rostedt(a)goodmis.org> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2023-53093 Link: https://nvd.nist.gov/vuln/detail/CVE-2023-53093 --- kernel/trace/trace_events_hist.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/kernel/trace/trace_events_hist.c b/kernel/trace/trace_events_hist.c index a0342b45a06d..e4f76e5ac6df 100644 --- a/kernel/trace/trace_events_hist.c +++ b/kernel/trace/trace_events_hist.c @@ -3705,6 +3705,15 @@ static int __create_val_field(struct hist_trigger_data *hist_data, goto out; } + /* Some types cannot be a value */ + if (hist_field->flags & (HIST_FIELD_FL_GRAPH | HIST_FIELD_FL_PERCENT | + HIST_FIELD_FL_BUCKET | HIST_FIELD_FL_LOG2 | + HIST_FIELD_FL_SYM | HIST_FIELD_FL_SYM_OFFSET | + HIST_FIELD_FL_SYSCALL | HIST_FIELD_FL_STACKTRACE)) { + hist_err(file->tr, HIST_ERR_BAD_FIELD_MODIFIER, errpos(field_str)); + ret = -EINVAL; + } + hist_data->fields[val_idx] = hist_field; ++hist_data->n_vals; -- 2.43.0

4 weeks

1
0
0 0

[PATCH 5.10] KVM: arm64: Tear down vGIC on failed vCPU creation

by Denis Arefev

From: Will Deacon <will(a)kernel.org> commit 250f25367b58d8c65a1b060a2dda037eea09a672 upstream. If kvm_arch_vcpu_create() fails to share the vCPU page with the hypervisor, we propagate the error back to the ioctl but leave the vGIC vCPU data initialised. Note only does this leak the corresponding memory when the vCPU is destroyed but it can also lead to use-after-free if the redistributor device handling tries to walk into the vCPU. Add the missing cleanup to kvm_arch_vcpu_create(), ensuring that the vGIC vCPU structures are destroyed on error. Cc: <stable(a)vger.kernel.org> Cc: Marc Zyngier <maz(a)kernel.org> Cc: Oliver Upton <oliver.upton(a)linux.dev> Cc: Quentin Perret <qperret(a)google.com> Signed-off-by: Will Deacon <will(a)kernel.org> Reviewed-by: Marc Zyngier <maz(a)kernel.org> Link: https://lore.kernel.org/r/20250314133409.9123-1-will@kernel.org Signed-off-by: Oliver Upton <oliver.upton(a)linux.dev> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2025-37849 Link: https://nvd.nist.gov/vuln/detail/cve-2025-37849 --- arch/arm64/kvm/arm.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/arch/arm64/kvm/arm.c b/arch/arm64/kvm/arm.c index afe8be2fef88..3adaa3216baf 100644 --- a/arch/arm64/kvm/arm.c +++ b/arch/arm64/kvm/arm.c @@ -294,7 +294,12 @@ int kvm_arch_vcpu_create(struct kvm_vcpu *vcpu) if (err) return err; - return create_hyp_mappings(vcpu, vcpu + 1, PAGE_HYP); + err = kvm_share_hyp(vcpu, vcpu + 1); + if (err) + kvm_vgic_vcpu_destroy(vcpu); + + return err; + } void kvm_arch_vcpu_postcreate(struct kvm_vcpu *vcpu) -- 2.43.0

4 weeks

1
0
0 0

[RESEND PATCH] arm64: dts: rockchip: Remove workaround that prevented Turing RK1 GPU power regulator control

by Sam Edwards

The RK3588 GPU power domain cannot be activated unless the external power regulator is already on. When GPU support was added to this DT, we had no way to represent this requirement, so `regulator-always-on` was added to the `vdd_gpu_s0` regulator in order to ensure stability. A later patch series (see "Fixes:" commit) resolved this shortcoming, but that commit left the workaround -- and rendered the comment above it no longer correct. Remove the workaround to allow the GPU power regulator to power off, now that the DT includes the necessary information to power it back on correctly. Fixes: f94500eb7328b ("arm64: dts: rockchip: Add GPU power domain regulator dependency for RK3588") Signed-off-by: Sam Edwards <CFSworks(a)gmail.com> Cc: <stable(a)vger.kernel.org> --- Hi friends, This is a patch from about two weeks ago that I failed to address to all relevant recipients, so I'm resending it with the recipients of the "Fixes:" commit included, as I should have done originally. The original thread had no discussion. Well wishes, Sam --- arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi | 11 ----------- 1 file changed, 11 deletions(-) diff --git a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi index 60ad272982ad..6daea8961fdd 100644 --- a/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi +++ b/arch/arm64/boot/dts/rockchip/rk3588-turing-rk1.dtsi @@ -398,17 +398,6 @@ rk806_dvs3_null: dvs3-null-pins { regulators { vdd_gpu_s0: vdd_gpu_mem_s0: dcdc-reg1 { - /* - * RK3588's GPU power domain cannot be enabled - * without this regulator active, but it - * doesn't have to be on when the GPU PD is - * disabled. Because the PD binding does not - * currently allow us to express this - * relationship, we have no choice but to do - * this instead: - */ - regulator-always-on; - regulator-boot-on; regulator-min-microvolt = <550000>; regulator-max-microvolt = <950000>; -- 2.48.1

4 weeks

2
1
0 0

[PATCH 5.10] codel: remove sch->q.qlen check before qdisc_tree_reduce_backlog()

by Denis Arefev

From: Cong Wang <xiyou.wangcong(a)gmail.com> commit 342debc12183b51773b3345ba267e9263bdfaaef upstream. After making all ->qlen_notify() callbacks idempotent, now it is safe to remove the check of qlen!=0 from both fq_codel_dequeue() and codel_qdisc_dequeue(). Reported-by: Gerrard Tai <gerrard.tai(a)starlabs.sg> Fixes: 4b549a2ef4be ("fq_codel: Fair Queue Codel AQM") Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM") Signed-off-by: Cong Wang <xiyou.wangcong(a)gmail.com> Reviewed-by: Simon Horman <horms(a)kernel.org> Link: https://patch.msgid.link/20250403211636.166257-1-xiyou.wangcong@gmail.com Acked-by: Jamal Hadi Salim <jhs(a)mojatatu.com> Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2025-37798 Link: https://nvd.nist.gov/vuln/detail/CVE-2025-37798 --- net/sched/sch_codel.c | 5 +---- net/sched/sch_fq_codel.c | 6 ++---- 2 files changed, 3 insertions(+), 8 deletions(-) diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c index d99c7386e24e..0d4228bfd1a0 100644 --- a/net/sched/sch_codel.c +++ b/net/sched/sch_codel.c @@ -95,10 +95,7 @@ static struct sk_buff *codel_qdisc_dequeue(struct Qdisc *sch) &q->stats, qdisc_pkt_len, codel_get_enqueue_time, drop_func, dequeue_func); - /* We cant call qdisc_tree_reduce_backlog() if our qlen is 0, - * or HTB crashes. Defer it for next round. - */ - if (q->stats.drop_count && sch->q.qlen) { + if (q->stats.drop_count) { qdisc_tree_reduce_backlog(sch, q->stats.drop_count, q->stats.drop_len); q->stats.drop_count = 0; q->stats.drop_len = 0; diff --git a/net/sched/sch_fq_codel.c b/net/sched/sch_fq_codel.c index 60dbc549e991..3c1efe360def 100644 --- a/net/sched/sch_fq_codel.c +++ b/net/sched/sch_fq_codel.c @@ -314,10 +314,8 @@ static struct sk_buff *fq_codel_dequeue(struct Qdisc *sch) } qdisc_bstats_update(sch, skb); flow->deficit -= qdisc_pkt_len(skb); - /* We cant call qdisc_tree_reduce_backlog() if our qlen is 0, - * or HTB crashes. Defer it for next round. - */ - if (q->cstats.drop_count && sch->q.qlen) { + + if (q->cstats.drop_count) { qdisc_tree_reduce_backlog(sch, q->cstats.drop_count, q->cstats.drop_len); q->cstats.drop_count = 0; -- 2.43.0

4 weeks

1
0
0 0

[PATCH 5.10] cifs: fix potential memory leaks in session setup

by Denis Arefev

From: Paulo Alcantara <pc(a)cjr.nz> commit 2fe58d977ee05da5bb89ef5dc4f5bf2dc15db46f upstream. Make sure to free cifs_ses::auth_key.response before allocating it as we might end up leaking memory in reconnect or mounting. Signed-off-by: Paulo Alcantara (SUSE) <pc(a)cjr.nz> Signed-off-by: Steve French <stfrench(a)microsoft.com> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2023-53008 Link: https://nvd.nist.gov/vuln/detail/CVE-2023-53008 --- fs/cifs/cifsencrypt.c | 1 + fs/cifs/sess.c | 2 ++ fs/cifs/smb2pdu.c | 1 + 3 files changed, 4 insertions(+) diff --git a/fs/cifs/cifsencrypt.c b/fs/cifs/cifsencrypt.c index 9daa256f69d4..c75bcdc987e0 100644 --- a/fs/cifs/cifsencrypt.c +++ b/fs/cifs/cifsencrypt.c @@ -371,6 +371,7 @@ build_avpair_blob(struct cifs_ses *ses, const struct nls_table *nls_cp) * ( for NTLMSSP_AV_NB_DOMAIN_NAME followed by NTLMSSP_AV_EOL ) + * unicode length of a netbios domain name */ + kfree_sensitive(ses->auth_key.response); ses->auth_key.len = size + 2 * dlen; ses->auth_key.response = kzalloc(ses->auth_key.len, GFP_KERNEL); if (!ses->auth_key.response) { diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c index cf6fd138d8d5..d4e215674597 100644 --- a/fs/cifs/sess.c +++ b/fs/cifs/sess.c @@ -601,6 +601,7 @@ int decode_ntlmssp_challenge(char *bcc_ptr, int blob_len, return -EINVAL; } if (tilen) { + kfree_sensitive(ses->auth_key.response); ses->auth_key.response = kmemdup(bcc_ptr + tioffset, tilen, GFP_KERNEL); if (!ses->auth_key.response) { @@ -1335,6 +1336,7 @@ sess_auth_kerberos(struct sess_data *sess_data) goto out_put_spnego_key; } + kfree_sensitive(ses->auth_key.response); ses->auth_key.response = kmemdup(msg->data, msg->sesskey_len, GFP_KERNEL); if (!ses->auth_key.response) { diff --git a/fs/cifs/smb2pdu.c b/fs/cifs/smb2pdu.c index 4197096e7fdb..15f9faa1e20a 100644 --- a/fs/cifs/smb2pdu.c +++ b/fs/cifs/smb2pdu.c @@ -1360,6 +1360,7 @@ SMB2_auth_kerberos(struct SMB2_sess_data *sess_data) /* keep session key if binding */ if (!ses->binding) { + kfree_sensitive(ses->auth_key.response); ses->auth_key.response = kmemdup(msg->data, msg->sesskey_len, GFP_KERNEL); if (!ses->auth_key.response) { -- 2.43.0

4 weeks

1
0
0 0

Request for backporting rtla fix into 6.15-stable

by Tomas Glozar

Hello, Please pull the following upstream patch to 6.15-stable: 8020361d51ee "rtla: Define _GNU_SOURCE in timerlat_bpf.c" This fixes an rtla bug that was introduced in 6.15 and was expected to be merged into 6.15, hence it was not tagged with Cc: stable, but did not make it. Thanks, Tomas

4 weeks

1
0
0 0

[PATCH 5.10] sched/task_stack: fix object_is_on_stack() for KASAN tagged pointers

by Denis Arefev

From: Qun-Wei Lin <qun-wei.lin(a)mediatek.com> commit fd7b4f9f46d46acbc7af3a439bb0d869efdc5c58 upstream. When CONFIG_KASAN_SW_TAGS and CONFIG_KASAN_STACK are enabled, the object_is_on_stack() function may produce incorrect results due to the presence of tags in the obj pointer, while the stack pointer does not have tags. This discrepancy can lead to incorrect stack object detection and subsequently trigger warnings if CONFIG_DEBUG_OBJECTS is also enabled. Example of the warning: ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at lib/debugobjects.c:557 __debug_object_init+0x330/0x364 Modules linked in: CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 6.12.0-rc5 #4 Hardware name: linux,dummy-virt (DT) pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __debug_object_init+0x330/0x364 lr : __debug_object_init+0x330/0x364 sp : ffff800082ea7b40 x29: ffff800082ea7b40 x28: 98ff0000c0164518 x27: 98ff0000c0164534 x26: ffff800082d93ec8 x25: 0000000000000001 x24: 1cff0000c00172a0 x23: 0000000000000000 x22: ffff800082d93ed0 x21: ffff800081a24418 x20: 3eff800082ea7bb0 x19: efff800000000000 x18: 0000000000000000 x17: 00000000000000ff x16: 0000000000000047 x15: 206b63617473206e x14: 0000000000000018 x13: ffff800082ea7780 x12: 0ffff800082ea78e x11: 0ffff800082ea790 x10: 0ffff800082ea79d x9 : 34d77febe173e800 x8 : 34d77febe173e800 x7 : 0000000000000001 x6 : 0000000000000001 x5 : feff800082ea74b8 x4 : ffff800082870a90 x3 : ffff80008018d3c4 x2 : 0000000000000001 x1 : ffff800082858810 x0 : 0000000000000050 Call trace: __debug_object_init+0x330/0x364 debug_object_init_on_stack+0x30/0x3c schedule_hrtimeout_range_clock+0xac/0x26c schedule_hrtimeout+0x1c/0x30 wait_task_inactive+0x1d4/0x25c kthread_bind_mask+0x28/0x98 init_rescuer+0x1e8/0x280 workqueue_init+0x1a0/0x3cc kernel_init_freeable+0x118/0x200 kernel_init+0x28/0x1f0 ret_from_fork+0x10/0x20 ---[ end trace 0000000000000000 ]--- ODEBUG: object 3eff800082ea7bb0 is NOT on stack ffff800082ea0000, but annotated. ------------[ cut here ]------------ Link: https://lkml.kernel.org/r/20241113042544.19095-1-qun-wei.lin@mediatek.com Signed-off-by: Qun-Wei Lin <qun-wei.lin(a)mediatek.com> Cc: Andrew Yang <andrew.yang(a)mediatek.com> Cc: AngeloGioacchino Del Regno <angelogioacchino.delregno(a)collabora.com> Cc: Casper Li <casper.li(a)mediatek.com> Cc: Catalin Marinas <catalin.marinas(a)arm.com> Cc: Chinwen Chang <chinwen.chang(a)mediatek.com> Cc: Kent Overstreet <kent.overstreet(a)linux.dev> Cc: Matthias Brugger <matthias.bgg(a)gmail.com> Cc: Pasha Tatashin <pasha.tatashin(a)soleen.com> Cc: Shakeel Butt <shakeel.butt(a)linux.dev> Cc: <stable(a)vger.kernel.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> [Denis: minor fix to resolve merge conflict.] Signed-off-by: Denis Arefev <arefev(a)swemel.ru> --- Backport fix for CVE-2024-53128 Link: https://nvd.nist.gov/vuln/detail/CVE-2024-53128 --- include/linux/sched/task_stack.h | 3 +++ 1 file changed, 3 insertions(+) diff --git a/include/linux/sched/task_stack.h b/include/linux/sched/task_stack.h index 879a5c8f930b..7aa1235a5bbe 100644 --- a/include/linux/sched/task_stack.h +++ b/include/linux/sched/task_stack.h @@ -8,6 +8,8 @@ #include <linux/sched.h> #include <linux/magic.h> +#include <linux/refcount.h> +#include <linux/kasan.h> #ifdef CONFIG_THREAD_INFO_IN_TASK @@ -86,6 +88,7 @@ static inline int object_is_on_stack(const void *obj) { void *stack = task_stack_page(current); + obj = kasan_reset_tag(obj); return (obj >= stack) && (obj < (stack + THREAD_SIZE)); } -- 2.43.0

4 weeks

1
0
0 0

[PATCH v2] ALSA: hda/realtek - Add mute LED support for HP Victus 16-s1xxx and HP Victus 15-fa1xxx

by edip＠medip.dev

From: Edip Hazuri <edip(a)medip.dev> The mute led on those laptops is using ALC245 but requires a quirk to work This patch enables the existing quirk for the devices. Tested on my Victus 16-s1011nt Laptop and my friend's Victus 15-fa1xxx. The LED behaviour works as intended. v2: - add new entries according to (PCI) SSID order - link to v1: https://lore.kernel.org/linux-sound/20250607105051.41162-1-edip@medip.dev/#R Cc: <stable(a)vger.kernel.org> Signed-off-by: Edip Hazuri <edip(a)medip.dev> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index cd0d7ba73..c70bee626 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10787,6 +10787,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8b97, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), SND_PCI_QUIRK(0x103c, 0x8bb3, "HP Slim OMEN", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8bb4, "HP Slim OMEN", ALC287_FIXUP_CS35L41_I2C_2), + SND_PCI_QUIRK(0x103c, 0x8bc8, "HP Victus 15-fa1xxx", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8bcd, "HP Omen 16-xd0xxx", ALC245_FIXUP_HP_MUTE_LED_V1_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8bdd, "HP Envy 17", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8bde, "HP Envy 17", ALC287_FIXUP_CS35L41_I2C_2), @@ -10840,6 +10841,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8c91, "HP EliteBook 660", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8c96, "HP", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), SND_PCI_QUIRK(0x103c, 0x8c97, "HP ZBook", ALC236_FIXUP_HP_MUTE_LED_MICMUTE_VREF), + SND_PCI_QUIRK(0x103c, 0x8c9c, "HP Victus 16-s1xxx (MB 8C9C)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8ca1, "HP ZBook Power", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8ca2, "HP ZBook Power", ALC236_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8ca4, "HP ZBook Fury", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), -- 2.49.0

4 weeks, 1 day

2
1
0 0

[PATCH] platform/x86/intel-uncore-freq: Fail module load when plat_info is NULL

by Srinivas Pandruvada

Address a Smatch static checker warning regarding an unchecked dereference in the function call: set_cdie_id(i, cluster_info, plat_info) when plat_info is NULL. Instead of addressing this one case, in general if plat_info is NULL then it can cause other issues. For example in a two package system it will give warning for duplicate sysfs entry as package ID will be always zero for both packages when creating string for attribute group name. plat_info is derived from TPMI ID TPMI_BUS_INFO, which is integral to the core TPMI design. Therefore, it should not be NULL on a production platform. Consequently, the module should fail to load if plat_info is NULL. Reported-by: Dan Carpenter <dan.carpenter(a)linaro.org> Closes: https://lore.kernel.org/platform-driver-x86/aEKvGCLd1qmX04Tc@stanley.mounta… Fixes: 8a54e2253e4c ("platform/x86/intel-uncore-freq: Uncore frequency control via TPMI") Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada(a)linux.intel.com> Cc: stable(a)vger.kernel.org --- .../x86/intel/uncore-frequency/uncore-frequency-tpmi.c | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c index 1c7b2f2716ca..44d9948ed224 100644 --- a/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c +++ b/drivers/platform/x86/intel/uncore-frequency/uncore-frequency-tpmi.c @@ -511,10 +511,13 @@ static int uncore_probe(struct auxiliary_device *auxdev, const struct auxiliary_ /* Get the package ID from the TPMI core */ plat_info = tpmi_get_platform_data(auxdev); - if (plat_info) - pkg = plat_info->package_id; - else + if (unlikely(!plat_info)) { dev_info(&auxdev->dev, "Platform information is NULL\n"); + ret = -ENODEV; + goto err_rem_common; + } + + pkg = plat_info->package_id; for (i = 0; i < num_resources; ++i) { struct tpmi_uncore_power_domain_info *pd_info; -- 2.49.0

4 weeks, 1 day

2
1
0 0

[PATCH] ALSA: hda/realtek - Add mute LED support for HP Victus 16-s1xxx and HP Victus 15-fa1xxx

by edip＠medip.dev

From: Edip Hazuri <edip(a)medip.dev> The mute led on those laptops is using ALC245 but requires a quirk to work This patch enables the existing quirk for the devices. Tested on my Victus 16-s1011nt Laptop and my friend's Victus 15-fa1xxx. The LED behaviour works as intended. Cc: <stable(a)vger.kernel.org> Signed-off-by: Edip Hazuri <edip(a)medip.dev> --- sound/pci/hda/patch_realtek.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/sound/pci/hda/patch_realtek.c b/sound/pci/hda/patch_realtek.c index cd0d7ba73..1e07da9c6 100644 --- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -10733,6 +10733,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8a0f, "HP Pavilion 14-ec1xxx", ALC287_FIXUP_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8a20, "HP Laptop 15s-fq5xxx", ALC236_FIXUP_HP_MUTE_LED_COEFBIT2), SND_PCI_QUIRK(0x103c, 0x8a25, "HP Victus 16-d1xxx (MB 8A25)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), + SND_PCI_QUIRK(0x103c, 0x8c9c, "HP Victus 16-s1xxx (MB 8C9C)", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8a28, "HP Envy 13", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8a29, "HP Envy 15", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8a2a, "HP Envy 15", ALC287_FIXUP_CS35L41_I2C_2), @@ -10805,6 +10806,7 @@ static const struct hda_quirk alc269_fixup_tbl[] = { SND_PCI_QUIRK(0x103c, 0x8c16, "HP Spectre x360 2-in-1 Laptop 16-aa0xxx", ALC245_FIXUP_HP_SPECTRE_X360_16_AA0XXX), SND_PCI_QUIRK(0x103c, 0x8c17, "HP Spectre 16", ALC287_FIXUP_CS35L41_I2C_2), SND_PCI_QUIRK(0x103c, 0x8c21, "HP Pavilion Plus Laptop 14-ey0XXX", ALC245_FIXUP_HP_X360_MUTE_LEDS), + SND_PCI_QUIRK(0x103c, 0x8bc8, "HP Victus 15-fa1xxx", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8c30, "HP Victus 15-fb1xxx", ALC245_FIXUP_HP_MUTE_LED_COEFBIT), SND_PCI_QUIRK(0x103c, 0x8c46, "HP EliteBook 830 G11", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), SND_PCI_QUIRK(0x103c, 0x8c47, "HP EliteBook 840 G11", ALC245_FIXUP_CS35L41_SPI_2_HP_GPIO_LED), -- 2.49.0

4 weeks, 1 day

2
1
0 0

Re: [External] Re: [PATCH v7 1/4] serial: 8250: fix panic due to PSLVERR

by yunhui cui

Hi, On Fri, Jun 6, 2025 at 6:40 PM Greg KH <gregkh(a)linuxfoundation.org> wrote: > > On Wed, May 28, 2025 at 02:26:06PM +0800, Yunhui Cui wrote: > > When the PSLVERR_RESP_EN parameter is set to 1, the device generates > > an error response if an attempt is made to read an empty RBR (Receive > > Buffer Register) while the FIFO is enabled. > > > > In serial8250_do_startup(), calling serial_port_out(port, UART_LCR, > > UART_LCR_WLEN8) triggers dw8250_check_lcr(), which invokes > > dw8250_force_idle() and serial8250_clear_and_reinit_fifos(). The latter > > function enables the FIFO via serial_out(p, UART_FCR, p->fcr). > > Execution proceeds to the serial_port_in(port, UART_RX). > > This satisfies the PSLVERR trigger condition. > > > > When another CPU (e.g., using printk()) is accessing the UART (UART > > is busy), the current CPU fails the check (value & ~UART_LCR_SPAR) == > > (lcr & ~UART_LCR_SPAR) in dw8250_check_lcr(), causing it to enter > > dw8250_force_idle(). > > > > Put serial_port_out(port, UART_LCR, UART_LCR_WLEN8) under the port->lock > > to fix this issue. > > > > Panic backtrace: > > [ 0.442336] Oops - unknown exception [#1] > > [ 0.442343] epc : dw8250_serial_in32+0x1e/0x4a > > [ 0.442351] ra : serial8250_do_startup+0x2c8/0x88e > > ... > > [ 0.442416] console_on_rootfs+0x26/0x70 > > > > Fixes: c49436b657d0 ("serial: 8250_dw: Improve unwritable LCR workaround") > > Link: https://lore.kernel.org/all/84cydt5peu.fsf@jogness.linutronix.de/T/ > > Signed-off-by: Yunhui Cui <cuiyunhui(a)bytedance.com> > > --- > > drivers/tty/serial/8250/8250_port.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/drivers/tty/serial/8250/8250_port.c b/drivers/tty/serial/8250/8250_port.c > > index 6d7b8c4667c9c..07fe818dffa34 100644 > > --- a/drivers/tty/serial/8250/8250_port.c > > +++ b/drivers/tty/serial/8250/8250_port.c > > @@ -2376,9 +2376,10 @@ int serial8250_do_startup(struct uart_port *port) > > /* > > * Now, initialize the UART > > */ > > - serial_port_out(port, UART_LCR, UART_LCR_WLEN8); > > > > uart_port_lock_irqsave(port, &flags); > > + serial_port_out(port, UART_LCR, UART_LCR_WLEN8); > > + > > if (up->port.flags & UPF_FOURPORT) { > > if (!up->port.irq) > > up->port.mctrl |= TIOCM_OUT1; > > -- > > 2.39.5 > > > > > > Hi, > > This is the friendly patch-bot of Greg Kroah-Hartman. You have sent him > a patch that has triggered this response. He used to manually respond > to these common problems, but in order to save his sanity (he kept > writing the same thing over and over, yet to different people), I was > created. Hopefully you will not take offence and will fix the problem > in your patch and resubmit it so that it can be accepted into the Linux > kernel tree. > > You are receiving this message because of the following common error(s) > as indicated below: > > - You have marked a patch with a "Fixes:" tag for a commit that is in an > older released kernel, yet you do not have a cc: stable line in the > signed-off-by area at all, which means that the patch will not be > applied to any older kernel releases. To properly fix this, please > follow the documented rules in the > Documentation/process/stable-kernel-rules.rst file for how to resolve > this. Okay, update under v8. > > If you wish to discuss this problem further, or you have questions about > how to resolve this issue, please feel free to respond to this email and > Greg will reply once he has dug out from the pending patches received > from other developers. > > thanks, > > greg k-h's patch email bot Thanks, Yunhui

4 weeks, 1 day

1
0
0 0

[PATCH 5.10 00/14] backport for CVE-2025-37948 and CVE-2025-37963

by Pu Lehui

From: Pu Lehui <pulehui(a)huawei.com> The backport mainly refers to the merge tag [0], and the corresponding patches are: arm64: proton-pack: Add new CPUs 'k' values for branch mitigation arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs arm64: proton-pack: Expose whether the branchy loop k value arm64: proton-pack: Expose whether the platform is mitigated by firmware arm64: insn: Add support for encoding DSB Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [0] Douglas Anderson (3): arm64: errata: Assume that unknown CPUs _are_ vulnerable to Spectre BHB arm64: errata: Add KRYO 2XX/3XX/4XX silver cores to Spectre BHB safe list arm64: errata: Add newer ARM cores to the spectre_bhb_loop_affected() lists Hou Tao (2): arm64: move AARCH64_BREAK_FAULT into insn-def.h arm64: insn: add encoders for atomic operations James Morse (6): arm64: insn: Add support for encoding DSB arm64: proton-pack: Expose whether the platform is mitigated by firmware arm64: proton-pack: Expose whether the branchy loop k value arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users arm64: proton-pack: Add new CPUs 'k' values for branch mitigation Julien Thierry (1): arm64: insn: Add barrier encodings Liu Song (1): arm64: spectre: increase parameters that can be used to turn off bhb mitigation individually Will Deacon (1): arm64: errata: Add missing sentinels to Spectre-BHB MIDR arrays .../admin-guide/kernel-parameters.txt | 5 + arch/arm64/include/asm/cputype.h | 2 + arch/arm64/include/asm/debug-monitors.h | 12 - arch/arm64/include/asm/insn.h | 114 +++++++++- arch/arm64/include/asm/spectre.h | 4 +- arch/arm64/kernel/insn.c | 199 +++++++++++++++-- arch/arm64/kernel/proton-pack.c | 206 +++++++++++------- arch/arm64/net/bpf_jit.h | 11 +- arch/arm64/net/bpf_jit_comp.c | 58 ++++- 9 files changed, 488 insertions(+), 123 deletions(-) -- 2.34.1

4 weeks, 1 day

2
28
0 0

[PATCH 5.15 0/9] backport for CVE-2025-37948 and CVE-2025-37963

by Pu Lehui

From: Pu Lehui <pulehui(a)huawei.com> The backport mainly refers to the merge tag [0], and the corresponding patches are: arm64: proton-pack: Add new CPUs 'k' values for branch mitigation arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs arm64: proton-pack: Expose whether the branchy loop k value arm64: proton-pack: Expose whether the platform is mitigated by firmware arm64: insn: Add support for encoding DSB Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?… [0] Hou Tao (2): arm64: move AARCH64_BREAK_FAULT into insn-def.h arm64: insn: add encoders for atomic operations James Morse (6): arm64: insn: Add support for encoding DSB arm64: proton-pack: Expose whether the platform is mitigated by firmware arm64: proton-pack: Expose whether the branchy loop k value arm64: bpf: Add BHB mitigation to the epilogue for cBPF programs arm64: bpf: Only mitigate cBPF programs loaded by unprivileged users arm64: proton-pack: Add new CPUs 'k' values for branch mitigation Liu Song (1): arm64: spectre: increase parameters that can be used to turn off bhb mitigation individually .../admin-guide/kernel-parameters.txt | 5 + arch/arm64/include/asm/cputype.h | 2 + arch/arm64/include/asm/debug-monitors.h | 12 -- arch/arm64/include/asm/insn-def.h | 14 ++ arch/arm64/include/asm/insn.h | 81 ++++++- arch/arm64/include/asm/spectre.h | 3 + arch/arm64/kernel/proton-pack.c | 21 +- arch/arm64/lib/insn.c | 199 ++++++++++++++++-- arch/arm64/net/bpf_jit.h | 11 +- arch/arm64/net/bpf_jit_comp.c | 58 ++++- 10 files changed, 366 insertions(+), 40 deletions(-) -- 2.34.1

4 weeks, 1 day

2
18
0 0

Mobile World Congress Shanghai 2025 (Verified) Attendee's List!

by Delilah Murray

Hi, We're excited to offer exclusive access to the “Mobile World Congress Shanghai 2025” Visitor Contact List. Event Recap:- Date: 18 - 20 Jun 2025 Location: Shanghai, China Registrants Counts: 42,276 Visitors Contacts Data Fields Available: Individual Email Address, Cell Phone Number, Contact Name, Job Title, Company Name, Website, Physical Address, LinkedIn Profile, and more. This list gives you a direct line to your ideal audience—no gatekeepers, no guesswork. If you're interested in the list, just reply "Send me Pricing" or sample? Best regards, Delilah Murray Sr. Marketing Manager Prefer not to receive these emails? Just reply “NOT INTERESTED”.

4 weeks, 1 day

1
0
0 0

[PATCH AUTOSEL 6.15 01/10] ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ] If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename to contain special characters. Reported-by: Philipp Kerling <pkerling(a)casix.org> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Based on my analysis of both the commit message and code changes, examining the Linux kernel repository context: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Nature of the Change This is a **legitimate bug fix** that addresses a functional issue where SMB3.1.1 POSIX extension clients cannot create files with characters that are valid in POSIX filesystems but blocked by ksmbd's Windows- centric filename validation. ## Code Analysis ### Key Changes: 1. **Early POSIX context detection** (lines 2906-2925): The code now checks for SMB2_CREATE_POSIX_CONTEXT early in the function 2. **Conditional validation bypass**: The critical change at lines 3161-3164 where `ksmbd_validate_filename(name)` is only called when `posix_ctxt == false` 3. **Structural improvement**: Moving POSIX context parsing before filename validation, which is the logical order ### What Gets Bypassed: The `ksmbd_validate_filename()` function normally blocks characters like `"`, `<`, `>`, `|`, `?`, `*`, and control characters. For POSIX extensions, these restrictions are inappropriate since POSIX filesystems can safely handle most of these characters. ## Security Assessment ### Low Security Risk: 1. **Limited Scope**: Only affects clients explicitly using SMB3.1.1 POSIX extensions (`tcon->posix_extensions` must be enabled) 2. **VFS Protection**: Linux VFS layer provides underlying security validation 3. **No Path Traversal**: Higher-level path validation still prevents `../` sequences 4. **Standards Compliance**: Aligns with Microsoft's SMB3.1.1 POSIX extension specification ### Justification for the Change: - **User Report**: Philipp Kerling reported this as a functional issue - **Interoperability**: Essential for proper POSIX-aware SMB client functionality - **Standards Adherence**: SMB3.1.1 POSIX extensions are designed to allow POSIX filename semantics ## Comparison with Similar Commits This follows the pattern of other backported ksmbd commits: - **Similar to Commit #4**: Another filename validation fix that was backported (moving leading slash check) - **Similar scope**: Limited, well-contained change to specific subsystem - **Bug fix nature**: Addresses functional issue rather than adding new features ## Stable Tree Criteria Compliance ✅ **Fixes important bug**: Enables legitimate POSIX client functionality ✅ **Small and contained**: Changes only affect POSIX extension code path ✅ **Minimal regression risk**: Protected by existing VFS validation ✅ **Clear side effects**: Well-understood behavior change ✅ **No architectural changes**: Simple conditional logic modification ## Recommendation This commit represents a **low-risk bug fix** that enables proper SMB3.1.1 POSIX extension functionality without introducing significant security vulnerabilities. The change is well-scoped, addresses a legitimate user issue, and maintains appropriate security boundaries through existing VFS-level protections. fs/smb/server/smb2pdu.c | 53 +++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index f2a2be8467c66..d4058b623e9c4 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2874,7 +2874,7 @@ int smb2_open(struct ksmbd_work *work) int req_op_level = 0, open_flags = 0, may_flags = 0, file_info = 0; int rc = 0; int contxt_cnt = 0, query_disk_id = 0; - int maximal_access_ctxt = 0, posix_ctxt = 0; + bool maximal_access_ctxt = false, posix_ctxt = false; int s_type = 0; int next_off = 0; char *name = NULL; @@ -2903,6 +2903,27 @@ int smb2_open(struct ksmbd_work *work) return create_smb2_pipe(work); } + if (req->CreateContextsOffset && tcon->posix_extensions) { + context = smb2_find_context_vals(req, SMB2_CREATE_TAG_POSIX, 16); + if (IS_ERR(context)) { + rc = PTR_ERR(context); + goto err_out2; + } else if (context) { + struct create_posix *posix = (struct create_posix *)context; + + if (le16_to_cpu(context->DataOffset) + + le32_to_cpu(context->DataLength) < + sizeof(struct create_posix) - 4) { + rc = -EINVAL; + goto err_out2; + } + ksmbd_debug(SMB, "get posix context\n"); + + posix_mode = le32_to_cpu(posix->Mode); + posix_ctxt = true; + } + } + if (req->NameLength) { name = smb2_get_name((char *)req + le16_to_cpu(req->NameOffset), le16_to_cpu(req->NameLength), @@ -2925,9 +2946,11 @@ int smb2_open(struct ksmbd_work *work) goto err_out2; } - rc = ksmbd_validate_filename(name); - if (rc < 0) - goto err_out2; + if (posix_ctxt == false) { + rc = ksmbd_validate_filename(name); + if (rc < 0) + goto err_out2; + } if (ksmbd_share_veto_filename(share, name)) { rc = -ENOENT; @@ -3085,28 +3108,6 @@ int smb2_open(struct ksmbd_work *work) rc = -EBADF; goto err_out2; } - - if (tcon->posix_extensions) { - context = smb2_find_context_vals(req, - SMB2_CREATE_TAG_POSIX, 16); - if (IS_ERR(context)) { - rc = PTR_ERR(context); - goto err_out2; - } else if (context) { - struct create_posix *posix = - (struct create_posix *)context; - if (le16_to_cpu(context->DataOffset) + - le32_to_cpu(context->DataLength) < - sizeof(struct create_posix) - 4) { - rc = -EINVAL; - goto err_out2; - } - ksmbd_debug(SMB, "get posix context\n"); - - posix_mode = le32_to_cpu(posix->Mode); - posix_ctxt = 1; - } - } } if (ksmbd_override_fsids(work)) { -- 2.39.5

4 weeks, 1 day

2
11
0 0

[PATCH AUTOSEL 6.14 01/10] ksmbd: allow a filename to contain special characters on SMB3.1.1 posix extension

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit dc3e0f17f74558e8a2fce00608855f050de10230 ] If client send SMB2_CREATE_POSIX_CONTEXT to ksmbd, Allow a filename to contain special characters. Reported-by: Philipp Kerling <pkerling(a)casix.org> Signed-off-by: Namjae Jeon <linkinjeon(a)kernel.org> Signed-off-by: Steve French <stfrench(a)microsoft.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- Based on my analysis of both the commit message and code changes, examining the Linux kernel repository context: **YES** This commit should be backported to stable kernel trees. Here's my extensive analysis: ## Nature of the Change This is a **legitimate bug fix** that addresses a functional issue where SMB3.1.1 POSIX extension clients cannot create files with characters that are valid in POSIX filesystems but blocked by ksmbd's Windows- centric filename validation. ## Code Analysis ### Key Changes: 1. **Early POSIX context detection** (lines 2906-2925): The code now checks for SMB2_CREATE_POSIX_CONTEXT early in the function 2. **Conditional validation bypass**: The critical change at lines 3161-3164 where `ksmbd_validate_filename(name)` is only called when `posix_ctxt == false` 3. **Structural improvement**: Moving POSIX context parsing before filename validation, which is the logical order ### What Gets Bypassed: The `ksmbd_validate_filename()` function normally blocks characters like `"`, `<`, `>`, `|`, `?`, `*`, and control characters. For POSIX extensions, these restrictions are inappropriate since POSIX filesystems can safely handle most of these characters. ## Security Assessment ### Low Security Risk: 1. **Limited Scope**: Only affects clients explicitly using SMB3.1.1 POSIX extensions (`tcon->posix_extensions` must be enabled) 2. **VFS Protection**: Linux VFS layer provides underlying security validation 3. **No Path Traversal**: Higher-level path validation still prevents `../` sequences 4. **Standards Compliance**: Aligns with Microsoft's SMB3.1.1 POSIX extension specification ### Justification for the Change: - **User Report**: Philipp Kerling reported this as a functional issue - **Interoperability**: Essential for proper POSIX-aware SMB client functionality - **Standards Adherence**: SMB3.1.1 POSIX extensions are designed to allow POSIX filename semantics ## Comparison with Similar Commits This follows the pattern of other backported ksmbd commits: - **Similar to Commit #4**: Another filename validation fix that was backported (moving leading slash check) - **Similar scope**: Limited, well-contained change to specific subsystem - **Bug fix nature**: Addresses functional issue rather than adding new features ## Stable Tree Criteria Compliance ✅ **Fixes important bug**: Enables legitimate POSIX client functionality ✅ **Small and contained**: Changes only affect POSIX extension code path ✅ **Minimal regression risk**: Protected by existing VFS validation ✅ **Clear side effects**: Well-understood behavior change ✅ **No architectural changes**: Simple conditional logic modification ## Recommendation This commit represents a **low-risk bug fix** that enables proper SMB3.1.1 POSIX extension functionality without introducing significant security vulnerabilities. The change is well-scoped, addresses a legitimate user issue, and maintains appropriate security boundaries through existing VFS-level protections. fs/smb/server/smb2pdu.c | 53 +++++++++++++++++++++-------------------- 1 file changed, 27 insertions(+), 26 deletions(-) diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index f2a2be8467c66..d4058b623e9c4 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -2874,7 +2874,7 @@ int smb2_open(struct ksmbd_work *work) int req_op_level = 0, open_flags = 0, may_flags = 0, file_info = 0; int rc = 0; int contxt_cnt = 0, query_disk_id = 0; - int maximal_access_ctxt = 0, posix_ctxt = 0; + bool maximal_access_ctxt = false, posix_ctxt = false; int s_type = 0; int next_off = 0; char *name = NULL; @@ -2903,6 +2903,27 @@ int smb2_open(struct ksmbd_work *work) return create_smb2_pipe(work); } + if (req->CreateContextsOffset && tcon->posix_extensions) { + context = smb2_find_context_vals(req, SMB2_CREATE_TAG_POSIX, 16); + if (IS_ERR(context)) { + rc = PTR_ERR(context); + goto err_out2; + } else if (context) { + struct create_posix *posix = (struct create_posix *)context; + + if (le16_to_cpu(context->DataOffset) + + le32_to_cpu(context->DataLength) < + sizeof(struct create_posix) - 4) { + rc = -EINVAL; + goto err_out2; + } + ksmbd_debug(SMB, "get posix context\n"); + + posix_mode = le32_to_cpu(posix->Mode); + posix_ctxt = true; + } + } + if (req->NameLength) { name = smb2_get_name((char *)req + le16_to_cpu(req->NameOffset), le16_to_cpu(req->NameLength), @@ -2925,9 +2946,11 @@ int smb2_open(struct ksmbd_work *work) goto err_out2; } - rc = ksmbd_validate_filename(name); - if (rc < 0) - goto err_out2; + if (posix_ctxt == false) { + rc = ksmbd_validate_filename(name); + if (rc < 0) + goto err_out2; + } if (ksmbd_share_veto_filename(share, name)) { rc = -ENOENT; @@ -3085,28 +3108,6 @@ int smb2_open(struct ksmbd_work *work) rc = -EBADF; goto err_out2; } - - if (tcon->posix_extensions) { - context = smb2_find_context_vals(req, - SMB2_CREATE_TAG_POSIX, 16); - if (IS_ERR(context)) { - rc = PTR_ERR(context); - goto err_out2; - } else if (context) { - struct create_posix *posix = - (struct create_posix *)context; - if (le16_to_cpu(context->DataOffset) + - le32_to_cpu(context->DataLength) < - sizeof(struct create_posix) - 4) { - rc = -EINVAL; - goto err_out2; - } - ksmbd_debug(SMB, "get posix context\n"); - - posix_mode = le32_to_cpu(posix->Mode); - posix_ctxt = 1; - } - } } if (ksmbd_override_fsids(work)) { -- 2.39.5

4 weeks, 1 day

2
11
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror