[LU-4088] echo_copyout_lsm wrong copy size Created: 11/Oct/13  Updated: 03/Jun/14  Resolved: 02/Dec/13

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.6.0

Type: Bug Priority: Minor
Reporter: Oleg Drokin Assignee: WC Triage
Resolution: Fixed Votes: 0
Labels: None

Severity: 3
Rank (Obsolete): 10991

 Description   

Found by Thomas Meyer <thomas@m3y3r.de> and submitted to mainline kernel:

Author: Thomas Meyer <thomas@m3y3r.de>
Date:   Thu Sep 19 23:45:46 2013 +0200

    staging: lustre: Cocci spatch "noderef"
    
    sizeof when applied to a pointer typed expression gives the size of the
    pointer.
    Found by coccinelle spatch "misc/noderef.cocci"
    
    Signed-off-by: Thomas Meyer <thomas@m3y3r.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

diff --git a/drivers/staging/lustre/lustre/obdecho/echo_client.c b/drivers/stagi
index 2644edf..c8b4344 100644
--- a/drivers/staging/lustre/lustre/obdecho/echo_client.c
+++ b/drivers/staging/lustre/lustre/obdecho/echo_client.c
@@ -1387,7 +1387,7 @@ echo_copyout_lsm (struct lov_stripe_md *lsm, void *_ulsm, 
        if (nob > ulsm_nob)
                return (-EINVAL);
 
-       if (copy_to_user (ulsm, lsm, sizeof(ulsm)))
+       if (copy_to_user (ulsm, lsm, sizeof(*ulsm)))
                return (-EFAULT);


 Comments   
Comment by Oleg Drokin [ 11/Oct/13 ]

patch in http://review.whamcloud.com/7922

Comment by John Hammond [ 11/Oct/13 ]

There's probably another in the gss userspace code:

diff -u -p lustre/utils/gss/write_bytes.h /tmp/nothing/utils/gss/write_bytes.h
--- lustre/utils/gss/write_bytes.h
+++ /tmp/nothing/utils/gss/write_bytes.h
@@ -111,7 +111,6 @@ get_buffer(char **ptr, const char *end,
 static inline int
 xdr_get_u32(u_int32_t **ptr, const u_int32_t *end, u_int32_t *res)
 {
-       if (get_bytes((char **)ptr, (char *)end, res, sizeof(res)))
           return -1;
           *res = ntohl(*res);
           return 0;
Comment by Oleg Drokin [ 02/Dec/13 ]

patch landed

Generated at Sat Feb 10 01:39:33 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.