This driver is known broken, as it computes the wrong SHA-1 and SHA-256
hashes. Correctness needs to be the first priority for cryptographic
code. Just disable it, allowing the standard (and actually correct)
SHA-1 and SHA-256 implementations to take priority.
Reported-by: larryw3i <larryw3i(a)yeah.net>
Closes: https://lore.kernel.org/r/3af01fec-b4d3-4d0c-9450-2b722d4bbe39@yeah.net/
Closes: https://lists.debian.org/debian-kernel/2025/09/msg00019.html
Closes: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1113996
Cc: stable(a)vger.kernel.org
Cc: AlanSong-oc(a)zhaoxin.com
Cc: CobeChen(a)zhaoxin.com
Cc: GeorgeXue(a)zhaoxin.com
Cc: HansHu(a)zhaoxin.com
Cc: LeoLiu-oc(a)zhaoxin.com
Cc: TonyWWang-oc(a)zhaoxin.com
Cc: YunShen(a)zhaoxin.com
Signed-off-by: Eric Biggers <ebiggers(a)kernel.org>
---
This patch is targeting crypto/master
drivers/crypto/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/Kconfig b/drivers/crypto/Kconfig
index a6688d54984c..16ea3e741350 100644
--- a/drivers/crypto/Kconfig
+++ b/drivers/crypto/Kconfig
@@ -38,11 +38,11 @@ config CRYPTO_DEV_PADLOCK_AES
If unsure say M. The compiled module will be
called padlock-aes.
config CRYPTO_DEV_PADLOCK_SHA
tristate "PadLock driver for SHA1 and SHA256 algorithms"
- depends on CRYPTO_DEV_PADLOCK
+ depends on CRYPTO_DEV_PADLOCK && BROKEN
select CRYPTO_HASH
select CRYPTO_SHA1
select CRYPTO_SHA256
help
Use VIA PadLock for SHA1/SHA256 algorithms.
base-commit: 59b0afd01b2ce353ab422ea9c8375b03db313a21
--
2.51.2
--
Hi,
PERDIS SUPER U is a leading retail group in France with numerous
outlets across the country. After reviewing your company profile and
products, we’re very interested in establishing a long-term partnership.
Kindly share your product catalog or website so we can review your
offerings and pricing. We are ready to place orders and begin
cooperation.Please note: Our payment terms are SWIFT, 14 days after
delivery.
Looking forward to your response.
Best regards,
Dominique Schelcher
Director, PERDIS SUPER U
RUE DE SAVOIE, 45600 SAINT-PÈRE-SUR-LOIRE
VAT: FR65380071464
www.magasins-u.com
The patch titled
Subject: unshare: fix nsproxy leak on set_cred_ucounts() error path
has been added to the -mm mm-nonmm-unstable branch. Its filename is
unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path.patch
This patch will shortly appear at
https://git.kernel.org/pub/scm/linux/kernel/git/akpm/25-new.git/tree/patche…
This patch will later appear in the mm-nonmm-unstable branch at
git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailing list as well
c) Ideally: find the original patch on the mailing list and do a
reply-to-all to that, adding suitable additional cc's
*** Remember to use Documentation/process/submit-checklist.rst when testing your code ***
The -mm tree is included into linux-next via the mm-everything
branch at git://git.kernel.org/pub/scm/linux/kernel/git/akpm/mm
and is updated there every 2-3 working days
------------------------------------------------------
From: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Subject: unshare: fix nsproxy leak on set_cred_ucounts() error path
Date: Tue, 18 Nov 2025 14:45:50 +0800
If unshare_nsproxy_namespaces() successfully creates the new_nsproxy, but
then set_cred_ucounts() fails, on its error path there is no cleanup for
new_nsproxy, so it is leaked. Let's fix that by freeing new_nsproxy if
it's not NULL on this error path.
Link: https://lkml.kernel.org/r/20251118064552.936962-1-ptikhomirov@virtuozzo.com
Fixes: 905ae01c4ae2a ("Add a reference to ucounts for each cred")
Signed-off-by: Pavel Tikhomirov <ptikhomirov(a)virtuozzo.com>
Acked-by: Alexey Gladkov <legion(a)kernel.org>
Reviewed-by: Liam R. Howlett <Liam.Howlett(a)oracle.com>
Cc: Ben Segall <bsegall(a)google.com>
Cc: Dietmar Eggemann <dietmar.eggemann(a)arm.com>
Cc: Eric Biederman <ebiederm(a)xmission.com>
Cc: Ingo Molnar <mingo(a)redhat.com>
Cc: Juri Lelli <juri.lelli(a)redhat.com>
Cc: Kees Cook <kees(a)kernel.org>
Cc: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com>
Cc: Mel Gorman <mgorman <mgorman(a)suse.de>
Cc: Michal Hocko <mhocko(a)suse.com>
Cc: Mike Rapoport <rppt(a)kernel.org>
Cc: Peter Zijlstra <peterz(a)infradead.org>
Cc: Steven Rostedt <rostedt(a)goodmis.org>
Cc: Suren Baghdasaryan <surenb(a)google.com>
Cc: Valentin Schneider <vschneid(a)redhat.com>
Cc: Vincent Guittot <vincent.guittot(a)linaro.org>
Cc: Vlastimil Babka <vbabka(a)suse.cz>
Cc: <stable(a)vger.kernel.org>
Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org>
---
kernel/fork.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
--- a/kernel/fork.c~unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path
+++ a/kernel/fork.c
@@ -3133,8 +3133,11 @@ int ksys_unshare(unsigned long unshare_f
if (new_cred) {
err = set_cred_ucounts(new_cred);
- if (err)
+ if (err) {
+ if (new_nsproxy)
+ free_nsproxy(new_nsproxy);
goto bad_unshare_cleanup_cred;
+ }
}
if (new_fs || new_fd || do_sysvsem || new_cred || new_nsproxy) {
_
Patches currently in -mm which might be from ptikhomirov(a)virtuozzo.com are
unshare-fix-nsproxy-leak-on-set_cred_ucounts-error-path.patch
Since kernel 6.17 display stack needs to reset the hardware properly to
ensure that we don't run into issues with the hardware configured by the
bootloader. MDSS reset is necessary to have working display when the
bootloader has already initialized it for the boot splash screen.
Signed-off-by: Alexey Minnekhanov <alexeymin(a)postmarketos.org>
---
Changes in v2:
- Added "Fixes" tag, pointing to commit which is the root cause for
exposing this "bug", which is only present since 6.17
- Extended commit messages
- Prepared series using correct user.email git setting
- Link to v1: https://lore.kernel.org/r/20251031-sdm660-mdss-reset-v1-0-14cb4e6836f2@post…
---
Alexey Minnekhanov (3):
dt-bindings: clock: mmcc-sdm660: Add missing MDSS reset
clk: qcom: mmcc-sdm660: Add missing MDSS reset
arm64: dts: qcom: sdm630: Add missing MDSS reset
arch/arm64/boot/dts/qcom/sdm630.dtsi | 1 +
drivers/clk/qcom/mmcc-sdm660.c | 1 +
include/dt-bindings/clock/qcom,mmcc-sdm660.h | 1 +
3 files changed, 3 insertions(+)
---
base-commit: 1cc41c88ef00de0f3216c5f4b9cfab47de1c49d3
change-id: 20251031-sdm660-mdss-reset-015a46a238b5
Best regards,
--
Alexey Minnekhanov <alexeymin(a)postmarketos.org>
From: Andrey Vatoropin <a.vatoropin(a)crpt.ru>
If allocation of cmd->t_task_cdb fails, it remains NULL but is later
dereferenced at the 'err' path.
In case of error reset NULL t_task_cdb value to point at the default
fixed-size buffer.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: 9e95fb805dc0 ("scsi: target: Fix NULL pointer dereference")
Cc: stable(a)vger.kernel.org
Signed-off-by: Andrey Vatoropin <a.vatoropin(a)crpt.ru>
---
drivers/target/target_core_transport.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/target/target_core_transport.c b/drivers/target/target_core_transport.c
index 0a76bdfe5528..88544c911949 100644
--- a/drivers/target/target_core_transport.c
+++ b/drivers/target/target_core_transport.c
@@ -1524,6 +1524,7 @@ target_cmd_init_cdb(struct se_cmd *cmd, unsigned char *cdb, gfp_t gfp)
if (scsi_command_size(cdb) > sizeof(cmd->__t_task_cdb)) {
cmd->t_task_cdb = kzalloc(scsi_command_size(cdb), gfp);
if (!cmd->t_task_cdb) {
+ cmd->t_task_cdb = &cmd->__t_task_cdb[0];
pr_err("Unable to allocate cmd->t_task_cdb"
" %u > sizeof(cmd->__t_task_cdb): %lu ops\n",
scsi_command_size(cdb),
--
2.43.0
impl_list_item_mod.rs calls container_of() without unsafe blocks at a
couple of places. Since container_of() is an unsafe macro / function,
the blocks are strictly necessary.
For unknown reasons, that problem was so far not visible and only gets
visible once one utilizes the list implementation from within the core
crate:
error[E0133]: call to unsafe function `core::ptr::mut_ptr::<impl *mut T>::byte_sub`
is unsafe and requires unsafe block
--> rust/kernel/lib.rs:252:29
|
252 | let container_ptr = field_ptr.byte_sub(offset).cast::<$Container>();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^ call to unsafe function
|
::: rust/kernel/drm/jq.rs:98:1
|
98 | / impl_list_item! {
99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
100 | | }
| |_- in this macro invocation
|
note: an unsafe function restricts its caller, but its body is safe by default
--> rust/kernel/list/impl_list_item_mod.rs:216:13
|
216 | unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
::: rust/kernel/drm/jq.rs:98:1
|
98 | / impl_list_item! {
99 | | impl ListItem<0> for BasicItem { using ListLinks { self.links }; }
100 | | }
| |_- in this macro invocation
= note: requested on the command line with `-D unsafe-op-in-unsafe-fn`
= note: this error originates in the macro `$crate::container_of` which comes
from the expansion of the macro `impl_list_item`
Add unsafe blocks to container_of to fix the issue.
Cc: stable(a)vger.kernel.org # v6.17+
Fixes: c77f85b347dd ("rust: list: remove OFFSET constants")
Suggested-by: Alice Ryhl <aliceryhl(a)google.com>
Signed-off-by: Philipp Stanner <phasta(a)kernel.org>
---
Changes in v2:
- Add unsafes to the list implementation instead of container_of
itself. (Alice, Miguel)
- Adjust commit message and Fixes: tag.
- Add stable-kernel for completeness.
---
rust/kernel/list/impl_list_item_mod.rs | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/rust/kernel/list/impl_list_item_mod.rs b/rust/kernel/list/impl_list_item_mod.rs
index 202bc6f97c13..7052095efde5 100644
--- a/rust/kernel/list/impl_list_item_mod.rs
+++ b/rust/kernel/list/impl_list_item_mod.rs
@@ -217,7 +217,7 @@ unsafe fn view_value(me: *mut $crate::list::ListLinks<$num>) -> *const Self {
// SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it
// points at the field `$field` in a value of type `Self`. Thus, reversing that
// operation is still in-bounds of the allocation.
- $crate::container_of!(me, Self, $($field).*)
+ unsafe { $crate::container_of!(me, Self, $($field).*) }
}
// GUARANTEES:
@@ -242,7 +242,7 @@ unsafe fn post_remove(me: *mut $crate::list::ListLinks<$num>) -> *const Self {
// SAFETY: `me` originates from the most recent call to `prepare_to_insert`, so it
// points at the field `$field` in a value of type `Self`. Thus, reversing that
// operation is still in-bounds of the allocation.
- $crate::container_of!(me, Self, $($field).*)
+ unsafe { $crate::container_of!(me, Self, $($field).*) }
}
}
)*};
@@ -270,9 +270,9 @@ unsafe fn prepare_to_insert(me: *const Self) -> *mut $crate::list::ListLinks<$nu
// SAFETY: The caller promises that `me` points at a valid value of type `Self`.
let links_field = unsafe { <Self as $crate::list::ListItem<$num>>::view_links(me) };
- let container = $crate::container_of!(
+ let container = unsafe { $crate::container_of!(
links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner
- );
+ ) };
// SAFETY: By the same reasoning above, `links_field` is a valid pointer.
let self_ptr = unsafe {
@@ -319,9 +319,9 @@ unsafe fn view_links(me: *const Self) -> *mut $crate::list::ListLinks<$num> {
// `ListArc` containing `Self` until the next call to `post_remove`. The value cannot
// be destroyed while a `ListArc` reference exists.
unsafe fn view_value(links_field: *mut $crate::list::ListLinks<$num>) -> *const Self {
- let container = $crate::container_of!(
+ let container = unsafe { $crate::container_of!(
links_field, $crate::list::ListLinksSelfPtr<Self, $num>, inner
- );
+ ) };
// SAFETY: By the same reasoning above, `links_field` is a valid pointer.
let self_ptr = unsafe {
--
2.49.0