October 2024 - Linux-stable-mirror

[PATCH AUTOSEL 6.6 01/20] ksmbd: override fsids for share path check

by Sasha Levin

From: Namjae Jeon <linkinjeon(a)kernel.org> [ Upstream commit a018c1b636e79b60149b41151ded7c2606d8606e ] Sangsoo reported that a DAC denial error occurred when accessing files through the ksmbd thread. This patch override fsids for share path check. Reported-by: Sangsoo Lee <constant.lee(a)samsung.com> 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> --- fs/smb/server/mgmt/share_config.c | 15 ++++++++++++--- fs/smb/server/mgmt/share_config.h | 4 +++- fs/smb/server/mgmt/tree_connect.c | 9 +++++---- fs/smb/server/mgmt/tree_connect.h | 4 ++-- fs/smb/server/smb2pdu.c | 2 +- fs/smb/server/smb_common.c | 9 +++++++-- fs/smb/server/smb_common.h | 2 ++ 7 files changed, 32 insertions(+), 13 deletions(-) diff --git a/fs/smb/server/mgmt/share_config.c b/fs/smb/server/mgmt/share_config.c index e0a6b758094fc..d8d03070ae44b 100644 --- a/fs/smb/server/mgmt/share_config.c +++ b/fs/smb/server/mgmt/share_config.c @@ -15,6 +15,7 @@ #include "share_config.h" #include "user_config.h" #include "user_session.h" +#include "../connection.h" #include "../transport_ipc.h" #include "../misc.h" @@ -120,12 +121,13 @@ static int parse_veto_list(struct ksmbd_share_config *share, return 0; } -static struct ksmbd_share_config *share_config_request(struct unicode_map *um, +static struct ksmbd_share_config *share_config_request(struct ksmbd_work *work, const char *name) { struct ksmbd_share_config_response *resp; struct ksmbd_share_config *share = NULL; struct ksmbd_share_config *lookup; + struct unicode_map *um = work->conn->um; int ret; resp = ksmbd_ipc_share_config_request(name); @@ -181,7 +183,14 @@ static struct ksmbd_share_config *share_config_request(struct unicode_map *um, KSMBD_SHARE_CONFIG_VETO_LIST(resp), resp->veto_list_sz); if (!ret && share->path) { + if (__ksmbd_override_fsids(work, share)) { + kill_share(share); + share = NULL; + goto out; + } + ret = kern_path(share->path, 0, &share->vfs_path); + ksmbd_revert_fsids(work); if (ret) { ksmbd_debug(SMB, "failed to access '%s'\n", share->path); @@ -214,7 +223,7 @@ static struct ksmbd_share_config *share_config_request(struct unicode_map *um, return share; } -struct ksmbd_share_config *ksmbd_share_config_get(struct unicode_map *um, +struct ksmbd_share_config *ksmbd_share_config_get(struct ksmbd_work *work, const char *name) { struct ksmbd_share_config *share; @@ -227,7 +236,7 @@ struct ksmbd_share_config *ksmbd_share_config_get(struct unicode_map *um, if (share) return share; - return share_config_request(um, name); + return share_config_request(work, name); } bool ksmbd_share_veto_filename(struct ksmbd_share_config *share, diff --git a/fs/smb/server/mgmt/share_config.h b/fs/smb/server/mgmt/share_config.h index 5f591751b9236..d4ac2dd4de204 100644 --- a/fs/smb/server/mgmt/share_config.h +++ b/fs/smb/server/mgmt/share_config.h @@ -11,6 +11,8 @@ #include <linux/path.h> #include <linux/unicode.h> +struct ksmbd_work; + struct ksmbd_share_config { char *name; char *path; @@ -68,7 +70,7 @@ static inline void ksmbd_share_config_put(struct ksmbd_share_config *share) __ksmbd_share_config_put(share); } -struct ksmbd_share_config *ksmbd_share_config_get(struct unicode_map *um, +struct ksmbd_share_config *ksmbd_share_config_get(struct ksmbd_work *work, const char *name); bool ksmbd_share_veto_filename(struct ksmbd_share_config *share, const char *filename); diff --git a/fs/smb/server/mgmt/tree_connect.c b/fs/smb/server/mgmt/tree_connect.c index d2c81a8a11dda..94a52a75014a4 100644 --- a/fs/smb/server/mgmt/tree_connect.c +++ b/fs/smb/server/mgmt/tree_connect.c @@ -16,17 +16,18 @@ #include "user_session.h" struct ksmbd_tree_conn_status -ksmbd_tree_conn_connect(struct ksmbd_conn *conn, struct ksmbd_session *sess, - const char *share_name) +ksmbd_tree_conn_connect(struct ksmbd_work *work, const char *share_name) { struct ksmbd_tree_conn_status status = {-ENOENT, NULL}; struct ksmbd_tree_connect_response *resp = NULL; struct ksmbd_share_config *sc; struct ksmbd_tree_connect *tree_conn = NULL; struct sockaddr *peer_addr; + struct ksmbd_conn *conn = work->conn; + struct ksmbd_session *sess = work->sess; int ret; - sc = ksmbd_share_config_get(conn->um, share_name); + sc = ksmbd_share_config_get(work, share_name); if (!sc) return status; @@ -61,7 +62,7 @@ ksmbd_tree_conn_connect(struct ksmbd_conn *conn, struct ksmbd_session *sess, struct ksmbd_share_config *new_sc; ksmbd_share_config_del(sc); - new_sc = ksmbd_share_config_get(conn->um, share_name); + new_sc = ksmbd_share_config_get(work, share_name); if (!new_sc) { pr_err("Failed to update stale share config\n"); status.ret = -ESTALE; diff --git a/fs/smb/server/mgmt/tree_connect.h b/fs/smb/server/mgmt/tree_connect.h index 6377a70b811c8..a42cdd0510411 100644 --- a/fs/smb/server/mgmt/tree_connect.h +++ b/fs/smb/server/mgmt/tree_connect.h @@ -13,6 +13,7 @@ struct ksmbd_share_config; struct ksmbd_user; struct ksmbd_conn; +struct ksmbd_work; enum { TREE_NEW = 0, @@ -50,8 +51,7 @@ static inline int test_tree_conn_flag(struct ksmbd_tree_connect *tree_conn, struct ksmbd_session; struct ksmbd_tree_conn_status -ksmbd_tree_conn_connect(struct ksmbd_conn *conn, struct ksmbd_session *sess, - const char *share_name); +ksmbd_tree_conn_connect(struct ksmbd_work *work, const char *share_name); void ksmbd_tree_connect_put(struct ksmbd_tree_connect *tcon); int ksmbd_tree_conn_disconnect(struct ksmbd_session *sess, diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c index 592a2cdfd0670..646c874d151a8 100644 --- a/fs/smb/server/smb2pdu.c +++ b/fs/smb/server/smb2pdu.c @@ -1955,7 +1955,7 @@ int smb2_tree_connect(struct ksmbd_work *work) ksmbd_debug(SMB, "tree connect request for tree %s treename %s\n", name, treename); - status = ksmbd_tree_conn_connect(conn, sess, name); + status = ksmbd_tree_conn_connect(work, name); if (status.ret == KSMBD_TREE_CONN_STATUS_OK) rsp->hdr.Id.SyncId.TreeId = cpu_to_le32(status.tree_conn->id); else diff --git a/fs/smb/server/smb_common.c b/fs/smb/server/smb_common.c index 474dadf6b7b8b..13818ecb6e1b2 100644 --- a/fs/smb/server/smb_common.c +++ b/fs/smb/server/smb_common.c @@ -732,10 +732,10 @@ bool is_asterisk(char *p) return p && p[0] == '*'; } -int ksmbd_override_fsids(struct ksmbd_work *work) +int __ksmbd_override_fsids(struct ksmbd_work *work, + struct ksmbd_share_config *share) { struct ksmbd_session *sess = work->sess; - struct ksmbd_share_config *share = work->tcon->share_conf; struct cred *cred; struct group_info *gi; unsigned int uid; @@ -775,6 +775,11 @@ int ksmbd_override_fsids(struct ksmbd_work *work) return 0; } +int ksmbd_override_fsids(struct ksmbd_work *work) +{ + return __ksmbd_override_fsids(work, work->tcon->share_conf); +} + void ksmbd_revert_fsids(struct ksmbd_work *work) { const struct cred *cred; diff --git a/fs/smb/server/smb_common.h b/fs/smb/server/smb_common.h index f1092519c0c28..4a3148b0167f5 100644 --- a/fs/smb/server/smb_common.h +++ b/fs/smb/server/smb_common.h @@ -447,6 +447,8 @@ int ksmbd_extract_shortname(struct ksmbd_conn *conn, int ksmbd_smb_negotiate_common(struct ksmbd_work *work, unsigned int command); int ksmbd_smb_check_shared_mode(struct file *filp, struct ksmbd_file *curr_fp); +int __ksmbd_override_fsids(struct ksmbd_work *work, + struct ksmbd_share_config *share); int ksmbd_override_fsids(struct ksmbd_work *work); void ksmbd_revert_fsids(struct ksmbd_work *work); -- 2.43.0

1 year

1
19
0 0

[PATCH AUTOSEL 6.11 01/16] drm/vboxvideo: Replace fake VLA at end of vbva_mouse_pointer_shape with real VLA

by Sasha Levin

From: Hans de Goede <hdegoede(a)redhat.com> [ Upstream commit d92b90f9a54d9300a6e883258e79f36dab53bfae ] Replace the fake VLA at end of the vbva_mouse_pointer_shape shape with a real VLA to fix a "memcpy: detected field-spanning write error" warning: [ 13.319813] memcpy: detected field-spanning write (size 16896) of single field "p->data" at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 (size 4) [ 13.319841] WARNING: CPU: 0 PID: 1105 at drivers/gpu/drm/vboxvideo/hgsmi_base.c:154 hgsmi_update_pointer_shape+0x192/0x1c0 [vboxvideo] [ 13.320038] Call Trace: [ 13.320173] hgsmi_update_pointer_shape [vboxvideo] [ 13.320184] vbox_cursor_atomic_update [vboxvideo] Note as mentioned in the added comment it seems the original length calculation for the allocated and send hgsmi buffer is 4 bytes too large. Changing this is not the goal of this patch, so this behavior is kept. Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Reviewed-by: Jani Nikula <jani.nikula(a)intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20240827104523.17442-1-hdegoe… Signed-off-by: Sasha Levin <sashal(a)kernel.org> --- drivers/gpu/drm/vboxvideo/hgsmi_base.c | 10 +++++++++- drivers/gpu/drm/vboxvideo/vboxvideo.h | 4 +--- 2 files changed, 10 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/vboxvideo/hgsmi_base.c b/drivers/gpu/drm/vboxvideo/hgsmi_base.c index 8c041d7ce4f1b..87dccaecc3e57 100644 --- a/drivers/gpu/drm/vboxvideo/hgsmi_base.c +++ b/drivers/gpu/drm/vboxvideo/hgsmi_base.c @@ -139,7 +139,15 @@ int hgsmi_update_pointer_shape(struct gen_pool *ctx, u32 flags, flags |= VBOX_MOUSE_POINTER_VISIBLE; } - p = hgsmi_buffer_alloc(ctx, sizeof(*p) + pixel_len, HGSMI_CH_VBVA, + /* + * The 4 extra bytes come from switching struct vbva_mouse_pointer_shape + * from having a 4 bytes fixed array at the end to using a proper VLA + * at the end. These 4 extra bytes were not subtracted from sizeof(*p) + * before the switch to the VLA, so this way the behavior is unchanged. + * Chances are these 4 extra bytes are not necessary but they are kept + * to avoid regressions. + */ + p = hgsmi_buffer_alloc(ctx, sizeof(*p) + pixel_len + 4, HGSMI_CH_VBVA, VBVA_MOUSE_POINTER_SHAPE); if (!p) return -ENOMEM; diff --git a/drivers/gpu/drm/vboxvideo/vboxvideo.h b/drivers/gpu/drm/vboxvideo/vboxvideo.h index f60d82504da02..79ec8481de0e4 100644 --- a/drivers/gpu/drm/vboxvideo/vboxvideo.h +++ b/drivers/gpu/drm/vboxvideo/vboxvideo.h @@ -351,10 +351,8 @@ struct vbva_mouse_pointer_shape { * Bytes in the gap between the AND and the XOR mask are undefined. * XOR mask scanlines have no gap between them and size of XOR mask is: * xor_len = width * 4 * height. - * - * Preallocate 4 bytes for accessing actual data as p->data. */ - u8 data[4]; + u8 data[]; } __packed; /* pointer is visible */ -- 2.43.0

1 year

1
15
0 0

[PATCH] ASoC: qcom: sc7280: Fix missing Soundwire runtime stream alloc

by Krzysztof Kozlowski

Commit 15c7fab0e047 ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards") moved the allocation of Soundwire stream runtime from the Qualcomm Soundwire driver to each individual machine sound card driver, except that it forgot to update SC7280 card. Just like for other Qualcomm sound cards using Soundwire, the card driver should allocate and release the runtime. Otherwise sound playback will result in a NULL pointer dereference or other effect of uninitialized memory accesses (which was confirmed on SDM845 having similar issue). Cc: stable(a)vger.kernel.org Cc: Alexey Klimov <alexey.klimov(a)linaro.org> Cc: Steev Klimaszewski <steev(a)kali.org> Fixes: 15c7fab0e047 ("ASoC: qcom: Move Soundwire runtime stream alloc to soundcards") Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski(a)linaro.org> --- Not tested on hardware. The sc7280 sound card differs a bit from the ones I am working on, thus please kindly test and confirm. Without the patch KASAN should show something similar to: https://lore.kernel.org/linux-sound/20241009213922.999355-1-alexey.klimov@l… The patch should fix it. --- sound/soc/qcom/sc7280.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/sound/soc/qcom/sc7280.c b/sound/soc/qcom/sc7280.c index 207ac5da4dd4..230af8d7b205 100644 --- a/sound/soc/qcom/sc7280.c +++ b/sound/soc/qcom/sc7280.c @@ -23,6 +23,7 @@ #include "common.h" #include "lpass.h" #include "qdsp6/q6afe.h" +#include "sdw.h" #define DEFAULT_MCLK_RATE 19200000 #define RT5682_PLL_FREQ (48000 * 512) @@ -316,6 +317,7 @@ static void sc7280_snd_shutdown(struct snd_pcm_substream *substream) struct snd_soc_card *card = rtd->card; struct sc7280_snd_data *data = snd_soc_card_get_drvdata(card); struct snd_soc_dai *cpu_dai = snd_soc_rtd_to_cpu(rtd, 0); + struct sdw_stream_runtime *sruntime = data->sruntime[cpu_dai->id]; switch (cpu_dai->id) { case MI2S_PRIMARY: @@ -333,6 +335,9 @@ static void sc7280_snd_shutdown(struct snd_pcm_substream *substream) default: break; } + + data->sruntime[cpu_dai->id] = NULL; + sdw_release_stream(sruntime); } static int sc7280_snd_startup(struct snd_pcm_substream *substream) @@ -347,6 +352,8 @@ static int sc7280_snd_startup(struct snd_pcm_substream *substream) switch (cpu_dai->id) { case MI2S_PRIMARY: ret = sc7280_rt5682_init(rtd); + if (ret) + return ret; break; case SECONDARY_MI2S_RX: codec_dai_fmt |= SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_I2S; @@ -360,7 +367,8 @@ static int sc7280_snd_startup(struct snd_pcm_substream *substream) default: break; } - return ret; + + return qcom_snd_sdw_startup(substream); } static const struct snd_soc_ops sc7280_ops = { -- 2.43.0

1 year

3
2
0 0

[PATCH] drm/xe/xe_sync: initialise ufence.signalled

by Matthew Auld

We can incorrectly think that the fence has signalled, if we get a non-zero value here from the kmalloc, which is quite plausible. Just use kzalloc to prevent stuff like this. Fixes: 977e5b82e090 ("drm/xe: Expose user fence from xe_sync_entry") Signed-off-by: Matthew Auld <matthew.auld(a)intel.com> Cc: Mika Kuoppala <mika.kuoppala(a)linux.intel.com> Cc: Matthew Brost <matthew.brost(a)intel.com> Cc: Nirmoy Das <nirmoy.das(a)intel.com> Cc: <stable(a)vger.kernel.org> # v6.10+ --- drivers/gpu/drm/xe/xe_sync.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/xe/xe_sync.c b/drivers/gpu/drm/xe/xe_sync.c index bb3c2a830362..c6cf227ead40 100644 --- a/drivers/gpu/drm/xe/xe_sync.c +++ b/drivers/gpu/drm/xe/xe_sync.c @@ -58,7 +58,7 @@ static struct xe_user_fence *user_fence_create(struct xe_device *xe, u64 addr, if (!access_ok(ptr, sizeof(*ptr))) return ERR_PTR(-EFAULT); - ufence = kmalloc(sizeof(*ufence), GFP_KERNEL); + ufence = kzalloc(sizeof(*ufence), GFP_KERNEL); if (!ufence) return ERR_PTR(-ENOMEM); -- 2.46.2

1 year

3
2
0 0

[PATCH 6.1.y] rust: macros: provide correct provenance when constructing THIS_MODULE

by Boqun Feng

commit a5a3c952e82c1ada12bf8c55b73af26f1a454bd2 upstream. Currently while defining `THIS_MODULE` symbol in `module!()`, the pointer used to construct `ThisModule` is derived from an immutable reference of `__this_module`, which means the pointer doesn't have the provenance for writing, and that means any write to that pointer is UB regardless of data races or not. However, the usage of `THIS_MODULE` includes passing this pointer to functions that may write to it (probably in unsafe code), and this will create soundness issues. One way to fix this is using `addr_of_mut!()` but that requires the unstable feature "const_mut_refs". So instead of `addr_of_mut()!`, an extern static `Opaque` is used here: since `Opaque<T>` is transparent to `T`, an extern static `Opaque` will just wrap the C symbol (defined in a C compile unit) in an `Opaque`, which provides a pointer with writable provenance via `Opaque::get()`. This fix the potential UBs because of pointer provenance unmatched. Reported-by: Alice Ryhl <aliceryhl(a)google.com> Signed-off-by: Boqun Feng <boqun.feng(a)gmail.com> Reviewed-by: Alice Ryhl <aliceryhl(a)google.com> Reviewed-by: Trevor Gross <tmgross(a)umich.edu> Reviewed-by: Benno Lossin <benno.lossin(a)proton.me> Reviewed-by: Gary Guo <gary(a)garyguo.net> Closes: https://rust-for-linux.zulipchat.com/#narrow/stream/x/topic/x/near/465412664 Fixes: 1fbde52bde73 ("rust: add `macros` crate") Cc: stable(a)vger.kernel.org # 6.6.x: be2ca1e03965: ("rust: types: Make Opaque::get const") Link: https://lore.kernel.org/r/20240828180129.4046355-1-boqun.feng@gmail.com [ Fixed two typos, reworded title. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda(a)kernel.org> [ Boqun: Use `UnsafeCell` since `Opaque` is not in v6.1, as suggested by Gary Guo, `UnsafeCell` also suffices for this particular case because `__this_module` is only used to create `THIS_MODULE`, no other Rust code will touch it. ] Signed-off-by: Boqun Feng <boqun.feng(a)gmail.com> --- Backports for 6.6+ are already done automatically, we have to do a special backport for 6.1 because of lacking an API. I've tested it on x86 with the rust_minimal module based on 6.1.112 rust/macros/module.rs | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/rust/macros/module.rs b/rust/macros/module.rs index 031028b3dc41..94a92ab82b6b 100644 --- a/rust/macros/module.rs +++ b/rust/macros/module.rs @@ -183,7 +183,11 @@ pub(crate) fn module(ts: TokenStream) -> TokenStream { // freed until the module is unloaded. #[cfg(MODULE)] static THIS_MODULE: kernel::ThisModule = unsafe {{ - kernel::ThisModule::from_ptr(&kernel::bindings::__this_module as *const _ as *mut _) + extern \"C\" {{ + static __this_module: core::cell::UnsafeCell<kernel::bindings::module>; + }} + + kernel::ThisModule::from_ptr(__this_module.get()) }}; #[cfg(not(MODULE))] static THIS_MODULE: kernel::ThisModule = unsafe {{ -- 2.45.2

1 year

1
0
0 0

[PATCH v4 net 0/4] net: enetc: fix some issues of XDP

by Wei Fang

We found some bugs when testing the XDP function of enetc driver, and these bugs are easy to reproduce. This is not only causes XDP to not work, but also the network cannot be restored after exiting the XDP program. So the patch set is mainly to fix these bugs. For details, please see the commit message of each patch. --- v1 link: https://lore.kernel.org/bpf/20240919084104.661180-1-wei.fang@nxp.com/T/ v2 link: https://lore.kernel.org/netdev/20241008224806.2onzkt3gbslw5jxb@skbuf/T/ v3 link: https://lore.kernel.org/imx/20241009090327.146461-1-wei.fang@nxp.com/T/ --- Wei Fang (4): net: enetc: remove xdp_drops statistic from enetc_xdp_drop() net: enetc: block concurrent XDP transmissions during ring reconfiguration net: enetc: disable Tx BD rings after they are empty net: enetc: disable NAPI after all rings are disabled drivers/net/ethernet/freescale/enetc/enetc.c | 56 +++++++++++++++----- drivers/net/ethernet/freescale/enetc/enetc.h | 1 + 2 files changed, 44 insertions(+), 13 deletions(-) -- 2.34.1

1 year

3
8
0 0

[PATCH 5.15.y 5.10.y 5.4.y] RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt

by Sherry Yang

From: Bob Pearson <rpearsonhpe(a)gmail.com> [ Upstream commit 2b23b6097303ed0ba5f4bc036a1c07b6027af5c6 ] In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the resp_pkts queue and then a decision is made whether to run the completer task inline or schedule it. Finally the skb is dereferenced to bump a 'hw' performance counter. This is wrong because if the completer task is already running in a separate thread it may have already processed the skb and freed it which can cause a seg fault. This has been observed infrequently in testing at high scale. This patch fixes this by changing the order of enqueuing the packet until after the counter is accessed. Link: https://lore.kernel.org/r/20240329145513.35381-4-rpearsonhpe@gmail.com Signed-off-by: Bob Pearson <rpearsonhpe(a)gmail.com> Fixes: 0b1e5b99a48b ("IB/rxe: Add port protocol stats") Signed-off-by: Jason Gunthorpe <jgg(a)nvidia.com> Signed-off-by: Sasha Levin <sashal(a)kernel.org> [Sherry: bp to fix CVE-2024-38544. Fix conflict due to missing commit: dccb23f6c312 ("RDMA/rxe: Split rxe_run_task() into two subroutines") which is not necessary to backport] Signed-off-by: Sherry Yang <sherry.yang(a)oracle.com> --- drivers/infiniband/sw/rxe/rxe_comp.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/infiniband/sw/rxe/rxe_comp.c b/drivers/infiniband/sw/rxe/rxe_comp.c index 48a3864ada29..250494306932 100644 --- a/drivers/infiniband/sw/rxe/rxe_comp.c +++ b/drivers/infiniband/sw/rxe/rxe_comp.c @@ -124,12 +124,12 @@ void rxe_comp_queue_pkt(struct rxe_qp *qp, struct sk_buff *skb) { int must_sched; - skb_queue_tail(&qp->resp_pkts, skb); - - must_sched = skb_queue_len(&qp->resp_pkts) > 1; + must_sched = skb_queue_len(&qp->resp_pkts) > 0; if (must_sched != 0) rxe_counter_inc(SKB_TO_PKT(skb)->rxe, RXE_CNT_COMPLETER_SCHED); + skb_queue_tail(&qp->resp_pkts, skb); + rxe_run_task(&qp->comp.task, must_sched); } -- 2.46.0

1 year

1
0
0 0

[PATCH 5.15.y] platform/x86: panasonic-laptop: Fix SINF array out of bounds accesses

by Sherry Yang

From: Hans de Goede <hdegoede(a)redhat.com> commit f52e98d16e9bd7dd2b3aef8e38db5cbc9899d6a4 upstream. The panasonic laptop code in various places uses the SINF array with index values of 0 - SINF_CUR_BRIGHT(0x0d) without checking that the SINF array is big enough. Not all panasonic laptops have this many SINF array entries, for example the Toughbook CF-18 model only has 10 SINF array entries. So it only supports the AC+DC brightness entries and mute. Check that the SINF array has a minimum size which covers all AC+DC brightness entries and refuse to load if the SINF array is smaller. For higher SINF indexes hide the sysfs attributes when the SINF array does not contain an entry for that attribute, avoiding show()/store() accessing the array out of bounds and add bounds checking to the probe() and resume() code accessing these. Fixes: e424fb8cc4e6 ("panasonic-laptop: avoid overflow in acpi_pcc_hotkey_add()") Cc: stable(a)vger.kernel.org Signed-off-by: Hans de Goede <hdegoede(a)redhat.com> Link: https://lore.kernel.org/r/20240909113227.254470-1-hdegoede@redhat.com Reviewed-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Ilpo Järvinen <ilpo.jarvinen(a)linux.intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> [Sherry: clean cherry-pick backport, fix CVE-2024-46859] Signed-off-by: Sherry Yang <sherry.yang(a)oracle.com> --- drivers/platform/x86/panasonic-laptop.c | 49 ++++++++++++++++++++----- 1 file changed, 39 insertions(+), 10 deletions(-) diff --git a/drivers/platform/x86/panasonic-laptop.c b/drivers/platform/x86/panasonic-laptop.c index 7ca49b3fc6c2..b06382dcecf7 100644 --- a/drivers/platform/x86/panasonic-laptop.c +++ b/drivers/platform/x86/panasonic-laptop.c @@ -773,6 +773,24 @@ static DEVICE_ATTR_RW(dc_brightness); static DEVICE_ATTR_RW(current_brightness); static DEVICE_ATTR_RW(cdpower); +static umode_t pcc_sysfs_is_visible(struct kobject *kobj, struct attribute *attr, int idx) +{ + struct device *dev = kobj_to_dev(kobj); + struct acpi_device *acpi = to_acpi_device(dev); + struct pcc_acpi *pcc = acpi_driver_data(acpi); + + if (attr == &dev_attr_mute.attr) + return (pcc->num_sifr > SINF_MUTE) ? attr->mode : 0; + + if (attr == &dev_attr_eco_mode.attr) + return (pcc->num_sifr > SINF_ECO_MODE) ? attr->mode : 0; + + if (attr == &dev_attr_current_brightness.attr) + return (pcc->num_sifr > SINF_CUR_BRIGHT) ? attr->mode : 0; + + return attr->mode; +} + static struct attribute *pcc_sysfs_entries[] = { &dev_attr_numbatt.attr, &dev_attr_lcdtype.attr, @@ -787,8 +805,9 @@ static struct attribute *pcc_sysfs_entries[] = { }; static const struct attribute_group pcc_attr_group = { - .name = NULL, /* put in device directory */ - .attrs = pcc_sysfs_entries, + .name = NULL, /* put in device directory */ + .attrs = pcc_sysfs_entries, + .is_visible = pcc_sysfs_is_visible, }; @@ -941,12 +960,15 @@ static int acpi_pcc_hotkey_resume(struct device *dev) if (!pcc) return -EINVAL; - acpi_pcc_write_sset(pcc, SINF_MUTE, pcc->mute); - acpi_pcc_write_sset(pcc, SINF_ECO_MODE, pcc->eco_mode); + if (pcc->num_sifr > SINF_MUTE) + acpi_pcc_write_sset(pcc, SINF_MUTE, pcc->mute); + if (pcc->num_sifr > SINF_ECO_MODE) + acpi_pcc_write_sset(pcc, SINF_ECO_MODE, pcc->eco_mode); acpi_pcc_write_sset(pcc, SINF_STICKY_KEY, pcc->sticky_key); acpi_pcc_write_sset(pcc, SINF_AC_CUR_BRIGHT, pcc->ac_brightness); acpi_pcc_write_sset(pcc, SINF_DC_CUR_BRIGHT, pcc->dc_brightness); - acpi_pcc_write_sset(pcc, SINF_CUR_BRIGHT, pcc->current_brightness); + if (pcc->num_sifr > SINF_CUR_BRIGHT) + acpi_pcc_write_sset(pcc, SINF_CUR_BRIGHT, pcc->current_brightness); return 0; } @@ -963,8 +985,12 @@ static int acpi_pcc_hotkey_add(struct acpi_device *device) num_sifr = acpi_pcc_get_sqty(device); - if (num_sifr < 0 || num_sifr > 255) { - pr_err("num_sifr out of range"); + /* + * pcc->sinf is expected to at least have the AC+DC brightness entries. + * Accesses to higher SINF entries are checked against num_sifr. + */ + if (num_sifr <= SINF_DC_CUR_BRIGHT || num_sifr > 255) { + pr_err("num_sifr %d out of range %d - 255\n", num_sifr, SINF_DC_CUR_BRIGHT + 1); return -ENODEV; } @@ -1016,11 +1042,14 @@ static int acpi_pcc_hotkey_add(struct acpi_device *device) acpi_pcc_write_sset(pcc, SINF_STICKY_KEY, 0); pcc->sticky_key = 0; - pcc->eco_mode = pcc->sinf[SINF_ECO_MODE]; - pcc->mute = pcc->sinf[SINF_MUTE]; pcc->ac_brightness = pcc->sinf[SINF_AC_CUR_BRIGHT]; pcc->dc_brightness = pcc->sinf[SINF_DC_CUR_BRIGHT]; - pcc->current_brightness = pcc->sinf[SINF_CUR_BRIGHT]; + if (pcc->num_sifr > SINF_MUTE) + pcc->mute = pcc->sinf[SINF_MUTE]; + if (pcc->num_sifr > SINF_ECO_MODE) + pcc->eco_mode = pcc->sinf[SINF_ECO_MODE]; + if (pcc->num_sifr > SINF_CUR_BRIGHT) + pcc->current_brightness = pcc->sinf[SINF_CUR_BRIGHT]; /* add sysfs attributes */ result = sysfs_create_group(&device->dev.kobj, &pcc_attr_group); -- 2.46.0

1 year

2
2
0 0

[PATCH 1/1] nfsd: fix race between laundromat and free_stateid

by Olga Kornievskaia

There is a race between laundromat handling of revoked delegations and a client sending free_stateid operation. Laundromat thread finds that delegation has expired and needs to be revoked so it marks the delegation stid revoked and it puts it on a reaper list but then it unlock the state lock and the actual delegation revocation happens without the lock. Once the stid is marked revoked a racing free_stateid processing thread does the following (1) it calls list_del_init() which removes it from the reaper list and (2) frees the delegation stid structure. The laundromat thread ends up not calling the revoke_delegation() function for this particular delegation but that means it will no release the lock lease that exists on the file. Now, a new open for this file comes in and ends up finding that lease list isn't empty and calls nfsd_breaker_owns_lease() which ends up trying to derefence a freed delegation stateid. Leading to the followint use-after-free KASAN warning: kernel: ================================================================== kernel: BUG: KASAN: slab-use-after-free in nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: Read of size 8 at addr ffff0000e73cd0c8 by task nfsd/6205 kernel: kernel: CPU: 2 UID: 0 PID: 6205 Comm: nfsd Kdump: loaded Not tainted 6.11.0-rc7+ #9 kernel: Hardware name: Apple Inc. Apple Virtualization Generic Platform, BIOS 2069.0.0.0.0 08/03/2024 kernel: Call trace: kernel: dump_backtrace+0x98/0x120 kernel: show_stack+0x1c/0x30 kernel: dump_stack_lvl+0x80/0xe8 kernel: print_address_description.constprop.0+0x84/0x390 kernel: print_report+0xa4/0x268 kernel: kasan_report+0xb4/0xf8 kernel: __asan_report_load8_noabort+0x1c/0x28 kernel: nfsd_breaker_owns_lease+0x140/0x160 [nfsd] kernel: leases_conflict+0x68/0x370 kernel: __break_lease+0x204/0xc38 kernel: nfsd_open_break_lease+0x8c/0xf0 [nfsd] kernel: nfsd_file_do_acquire+0xb3c/0x11d0 [nfsd] kernel: nfsd_file_acquire_opened+0x84/0x110 [nfsd] kernel: nfs4_get_vfs_file+0x634/0x958 [nfsd] kernel: nfsd4_process_open2+0xa40/0x1a40 [nfsd] kernel: nfsd4_open+0xa08/0xe80 [nfsd] kernel: nfsd4_proc_compound+0xb8c/0x2130 [nfsd] kernel: nfsd_dispatch+0x22c/0x718 [nfsd] kernel: svc_process_common+0x8e8/0x1960 [sunrpc] kernel: svc_process+0x3d4/0x7e0 [sunrpc] kernel: svc_handle_xprt+0x828/0xe10 [sunrpc] kernel: svc_recv+0x2cc/0x6a8 [sunrpc] kernel: nfsd+0x270/0x400 [nfsd] kernel: kthread+0x288/0x310 kernel: ret_from_fork+0x10/0x20 Proposing to have laundromat thread hold the state_lock over both marking thru revoking the delegation as well as making free_stateid acquire state_lock before accessing the list. Making sure that revoke_delegation() (ie kernel_setlease(unlock)) is called for every delegation that was revoked and added to the reaper list. CC: stable(a)vger.kernel.org Signed-off-by: Olga Kornievskaia <okorniev(a)redhat.com> --- I can't figure out the Fixes: tag. Laundromat's behaviour has been like that forever. But the free_stateid bits wont apply before the 1e3577a4521e ("SUNRPC: discard sv_refcnt, and svc_get/svc_put"). But we used that fixes tag already with a previous fix for a different problem. --- fs/nfsd/nfs4state.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/fs/nfsd/nfs4state.c b/fs/nfsd/nfs4state.c index 9c2b1d251ab3..c97907d7fb38 100644 --- a/fs/nfsd/nfs4state.c +++ b/fs/nfsd/nfs4state.c @@ -6605,13 +6605,13 @@ nfs4_laundromat(struct nfsd_net *nn) unhash_delegation_locked(dp, SC_STATUS_REVOKED); list_add(&dp->dl_recall_lru, &reaplist); } - spin_unlock(&state_lock); while (!list_empty(&reaplist)) { dp = list_first_entry(&reaplist, struct nfs4_delegation, dl_recall_lru); list_del_init(&dp->dl_recall_lru); revoke_delegation(dp); } + spin_unlock(&state_lock); spin_lock(&nn->client_lock); while (!list_empty(&nn->close_lru)) { @@ -7213,7 +7213,9 @@ nfsd4_free_stateid(struct svc_rqst *rqstp, struct nfsd4_compound_state *cstate, if (s->sc_status & SC_STATUS_REVOKED) { spin_unlock(&s->sc_lock); dp = delegstateid(s); + spin_lock(&state_lock); list_del_init(&dp->dl_recall_lru); + spin_unlock(&state_lock); spin_unlock(&cl->cl_lock); nfs4_put_stid(s); ret = nfs_ok; -- 2.43.5

1 year

5
10
0 0

[PATCH RFC v2] mm: Enforce the stack gap when changing inaccessible VMAs

by Jann Horn

As explained in the comment block this change adds, we can't tell what userspace's intent is when the stack grows towards an inaccessible VMA. We should ensure that, as long as code is compiled with something like -fstack-check, a stack overflow in this code can never cause the main stack to overflow into adjacent heap memory - so the bottom of a stack should never be directly adjacent to an accessible VMA. As suggested by Lorenzo, enforce this by blocking attempts to: - make an inaccessible VMA accessible with mprotect() when it is too close to a stack - replace an inaccessible VMA with another VMA using MAP_FIXED when it is too close to a stack I have a (highly contrived) C testcase for 32-bit x86 userspace with glibc that mixes malloc(), pthread creation, and recursion in just the right way such that the main stack overflows into malloc() arena memory, see the linked list post. I don't know of any specific scenario where this is actually exploitable, but it seems like it could be a security problem for sufficiently unlucky userspace. Link: https://lore.kernel.org/r/CAG48ez2v=r9-37JADA5DgnZdMLCjcbVxAjLt5eH5uoBohRdq… Suggested-by: Lorenzo Stoakes <lorenzo.stoakes(a)oracle.com> Fixes: 561b5e0709e4 ("mm/mmap.c: do not blow on PROT_NONE MAP_FIXED holes in the stack") Cc: stable(a)vger.kernel.org Signed-off-by: Jann Horn <jannh(a)google.com> --- This is an attempt at the alternate fix approach suggested by Lorenzo. This turned into more code than I would prefer to have for a scenario like this... Also, the way the gap is enforced in my patch for MAP_FIXED_NOREPLACE is a bit ugly. In the existing code, __get_unmapped_area() normally already enforces the stack gap even when it is called with a hint; but when MAP_FIXED_NOREPLACE is used, we kinda lie to __get_unmapped_area() and tell it we'll do a MAP_FIXED mapping (introduced in commit a4ff8e8620d3f when MAP_FIXED_NOREPLACE was created), then afterwards manually reject overlapping mappings. So I ended up also doing the gap check separately for MAP_FIXED_NOREPLACE. The following test program exercises scenarios that could lead to the stack becoming directly adjacent to another accessible VMA, and passes with this patch applied: <<< int main(void) { setbuf(stdout, NULL); char *ptr = (char*)( (unsigned long)(STACK_POINTER() - (1024*1024*4)/*4MiB*/) & ~0xfffUL ); if (mmap(ptr, 0x1000, PROT_NONE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0) != ptr) err(1, "mmap distant-from-stack"); *(volatile char *)(ptr + 0x1000); /* expand stack */ system("echo;cat /proc/$PPID/maps;echo"); /* test transforming PROT_NONE mapping adjacent to stack */ if (mprotect(ptr, 0x1000, PROT_READ|PROT_WRITE|PROT_EXEC) == 0) errx(1, "mprotect adjacent to stack allowed"); if (mmap(ptr, 0x1000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED, -1, 0) != MAP_FAILED) errx(1, "MAP_FIXED adjacent to stack allowed"); if (munmap(ptr, 0x1000)) err(1, "munmap failed???"); /* test creating new mapping adjacent to stack */ if (mmap(ptr, 0x1000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE|MAP_FIXED_NOREPLACE, -1, 0) != MAP_FAILED) errx(1, "MAP_FIXED_NOREPLACE adjacent to stack allowed"); if (mmap(ptr, 0x1000, PROT_READ|PROT_WRITE, MAP_ANONYMOUS|MAP_PRIVATE, -1, 0) == ptr) errx(1, "mmap hint adjacent to stack accepted"); printf("all tests passed\n"); } >>> --- Changes in v2: - Entirely new approach (suggested by Lorenzo) - Link to v1: https://lore.kernel.org/r/20241008-stack-gap-inaccessible-v1-1-848d4d891f21… --- include/linux/mm.h | 1 + mm/mmap.c | 65 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ mm/mprotect.c | 6 +++++ 3 files changed, 72 insertions(+) diff --git a/include/linux/mm.h b/include/linux/mm.h index ecf63d2b0582..ecd4afc304ca 100644 --- a/include/linux/mm.h +++ b/include/linux/mm.h @@ -3520,6 +3520,7 @@ unsigned long change_prot_numa(struct vm_area_struct *vma, struct vm_area_struct *find_extend_vma_locked(struct mm_struct *, unsigned long addr); +bool overlaps_stack_gap(struct mm_struct *mm, unsigned long addr, unsigned long len); int remap_pfn_range(struct vm_area_struct *, unsigned long addr, unsigned long pfn, unsigned long size, pgprot_t); int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr, diff --git a/mm/mmap.c b/mm/mmap.c index dd4b35a25aeb..937361be3c48 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -359,6 +359,20 @@ unsigned long do_mmap(struct file *file, unsigned long addr, return -EEXIST; } + /* + * This does two things: + * + * 1. Disallow MAP_FIXED replacing a PROT_NONE VMA adjacent to a stack + * with an accessible VMA. + * 2. Disallow MAP_FIXED_NOREPLACE creating a new accessible VMA + * adjacent to a stack. + */ + if ((flags & (MAP_FIXED_NOREPLACE | MAP_FIXED)) && + (prot & (PROT_READ | PROT_WRITE | PROT_EXEC)) && + !(vm_flags & (VM_GROWSUP|VM_GROWSDOWN)) && + overlaps_stack_gap(mm, addr, len)) + return (flags & MAP_FIXED) ? -ENOMEM : -EEXIST; + if (flags & MAP_LOCKED) if (!can_do_mlock()) return -EPERM; @@ -1341,6 +1355,57 @@ struct vm_area_struct *expand_stack(struct mm_struct *mm, unsigned long addr) return vma; } +/* + * Does the specified VA range overlap the stack gap of a preceding or following + * stack VMA? + * Overlapping stack VMAs are ignored - so if someone deliberately creates a + * MAP_FIXED mapping in the middle of a stack or such, we let that go through. + * + * This is needed partly because userspace's intent when making PROT_NONE + * mappings is unclear; there are two different reasons for creating PROT_NONE + * mappings: + * + * A) Userspace wants to create its own guard mapping, for example for stacks. + * According to + * <https://lore.kernel.org/all/1499126133.2707.20.camel@decadent.org.uk/T/>, + * some Rust/Java programs do this with the main stack. + * Enforcing the kernel's stack gap between these userspace guard mappings and + * the main stack breaks stuff. + * + * B) Userspace wants to reserve some virtual address space for later mappings. + * This is done by memory allocators. + * In this case, we want to enforce a stack gap between the mapping and the + * stack. + * + * Because we can't tell these cases apart when a PROT_NONE mapping is created, + * we instead enforce the stack gap when a PROT_NONE mapping is made accessible + * (using mprotect()) or replaced with an accessible one (using MAP_FIXED). + */ +bool overlaps_stack_gap(struct mm_struct *mm, unsigned long addr, unsigned long len) +{ + + struct vm_area_struct *vma, *prev_vma; + + /* step 1: search for a non-overlapping following stack VMA */ + vma = find_vma(mm, addr+len); + if (vma && vma->vm_start >= addr+len) { + /* is it too close? */ + if (vma->vm_start - (addr+len) < stack_guard_start_gap(vma)) + return true; + } + + /* step 2: search for a non-overlapping preceding stack VMA */ + if (!IS_ENABLED(CONFIG_STACK_GROWSUP)) + return false; + vma = find_vma_prev(mm, addr, &prev_vma); + /* don't handle cases where the VA start overlaps a VMA */ + if (vma && vma->vm_start < addr) + return false; + if (!prev_vma || !(prev_vma->vm_flags & VM_GROWSUP)) + return false; + return addr - prev_vma->vm_end < stack_guard_gap; +} + /* do_munmap() - Wrapper function for non-maple tree aware do_munmap() calls. * @mm: The mm_struct * @start: The start address to munmap diff --git a/mm/mprotect.c b/mm/mprotect.c index 0c5d6d06107d..2300e2eff956 100644 --- a/mm/mprotect.c +++ b/mm/mprotect.c @@ -772,6 +772,12 @@ static int do_mprotect_pkey(unsigned long start, size_t len, } } + error = -ENOMEM; + if ((prot & (PROT_READ | PROT_WRITE | PROT_EXEC)) && + !(vma->vm_flags & (VM_GROWSUP|VM_GROWSDOWN)) && + overlaps_stack_gap(current->mm, start, end - start)) + goto out; + prev = vma_prev(&vmi); if (start > vma->vm_start) prev = vma; --- base-commit: 8cf0b93919e13d1e8d4466eb4080a4c4d9d66d7b change-id: 20241008-stack-gap-inaccessible-c7319f7d4b1b -- Jann Horn <jannh(a)google.com>

1 year

2
3
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror October 2024