audit: Replace zero-length array with flexible-array
PATCH 1/1 audit: Replace zero-length array with flexible-array
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99:
struct foo {
int stuff;
struct boo array[];
};By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this change:
"Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit 76497732932f ("cxgb3/l2t: Fix undefined behaviour")
--- include/linux/audit.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
include/linux/audit.h +1 -1
@@ -19,7 +19,7 @@struct audit_sig_info {uid_t uid;pid_t pid; -char ctx[0 ]; +char ctx[]; };struct audit_buffer ;
Quoted 29 lines · Gustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99:
struct foo { int stuff; struct boo array[]; };By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this change:
"Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues.
Quoted 7 lines
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit76497732932f("cxgb3/l2t: Fix undefined behaviour")Signed-off-by Gustavo A. R. Silva <[email protected]>
Sounds reasonable to me. There's another in include/uapi/linux/audit.h in struct audit_rule_data buf[0]. This alert also helped me fix another one in a patchset I'm about to post (and will probably cause a merge conflict but we can figure that out).
Quoted 20 lines
--- include/linux/audit.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)include/linux/audit.h +1
-2@@ -19,7 +19,7 @@struct audit_sig_info {uid_t uid;pid_t pid; -char ctx[0 ]; +char ctx[]; };struct audit_buffer ; --
Quoted 3 lines
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit
- RGB
--
Richard Guy Briggs <[email protected]>
Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
Quoted 32 lines · Richard Guy Briggs
Quoted 31 lines · Gustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99:
struct foo { int stuff; struct boo array[]; };By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this change:
"Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
Quoted 7 lines
Quoted 5 lines
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit76497732932f("cxgb3/l2t: Fix undefined behaviour")Signed-off-by Gustavo A. R. Silva <[email protected]>Sounds reasonable to me. There's another in
include/uapi/linux/audit.h
Hi,
I wouldn't advise to make any of these conversions in include/uapi/ [1][2].
Quoted 3 lines
in struct
audit_rule_databuf[0]. This alert also helped me fix another one in a patchset I'm about to post (and will probably cause a merge conflict but we can figure that out).
Awesome. :)
Quoted 3 lines
Reviewed-by Richard Guy Briggs <[email protected]>
Thanks
--
Gustavo
[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e6e9d0f4859ec698d55381ea26f4136eff3afe1
Quoted 33 lines
Quoted 20 lines
--- include/linux/audit.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)include/linux/audit.h +1
-2@@ -19,7 +19,7 @@struct audit_sig_info {uid_t uid;pid_t pid; -char ctx[0 ]; +char ctx[]; };struct audit_buffer ; --Quoted 3 lines
Linux-audit mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/linux-audit- RGB
--
Richard Guy Briggs <[email protected]>
Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
Paul Moore
maintainerQuoted 1 line · Gustavo A. R. Silva
I wouldn't advise to make any of these conversions in
include/uapi/...
Yes, let's not make changes like this to anything under include/uapi; the potential reward doesn't outweigh the risks.
Signature · 2 lines
paul moore www.paul-moore.com
Quoted 31 lines · Gustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99:
struct foo { int stuff; struct boo array[]; };By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this change:
"Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
Quoted 8 lines
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit76497732932f("cxgb3/l2t: Fix undefined behaviour")Signed-off-by Gustavo A. R. Silva <[email protected]>--- include/linux/audit.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Merged into audit/next, thanks!
Quoted 13 lines
include/linux/audit.h +1
-1@@ -19,7 +19,7 @@struct audit_sig_info {uid_t uid;pid_t pid; -char ctx[0 ]; +char ctx[]; };struct audit_buffer ;
Signature · 2 lines
paul moore www.paul-moore.com
Quoted 37 lines · Gustavo A. R. Silva
Quoted 36 lines · Richard Guy Briggs
Quoted 35 lines · Gustavo A. R. Silva
The current codebase makes use of the zero-length array language extension to the C90 standard, but the preferred mechanism to declare variable-length types such as these ones is a flexible array member[1][2], introduced in C99:
struct foo { int stuff; struct boo array[]; };By making use of the mechanism above, we will get a compiler warning in case the flexible array does not occur last in the structure, which will help us prevent some kind of undefined behavior bugs from being inadvertently introduced[3] to the codebase from now on.
Also, notice that, dynamic memory allocations won't be affected by this change:
"Flexible array members have incomplete type, and so the sizeof operator may not be applied. As a quirk of the original implementation of zero-length arrays, sizeof evaluates to zero."[1]
sizeof(flexible-array-member) triggers a warning because flexible array members have incomplete type[1]. There are some instances of code in which the sizeof operator is being incorrectly/erroneously applied to zero-length arrays and the result is zero. Such instances may be hiding some bugs. So, this work (flexible-array member conversions) will also help to get completely rid of those sorts of issues.
This issue was found with the help of Coccinelle.
[1] https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html
[2] https://github.com/KSPP/linux/issues/21
[3] commit76497732932f("cxgb3/l2t: Fix undefined behaviour")
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Gustavo A. R. Silva <[email protected]>Sounds reasonable to me. There's another in
include/uapi/linux/audit.hHi,
Hello Gustavo,
Quoted 2 lines
I wouldn't advise to make any of these conversions in
include/uapi/[1][2].
Ah-hah. Thanks for the contra-indicating supporting references.
Quoted 6 lines
Quoted 3 lines
in struct
audit_rule_databuf[0]. This alert also helped me fix another one in a patchset I'm about to post (and will probably cause a merge conflict but we can figure that out).Awesome. :)
Quoted 28 lines
Quoted 1 line
Reviewed-by Richard Guy Briggs <[email protected]>Thanks
--
Gustavo[1] https://lore.kernel.org/lkml/[email protected]/
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1e6e9d0f4859ec698d55381ea26f4136eff3afe1Quoted 19 lines
Quoted 9 lines
--- include/linux/audit.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)include/linux/audit.h +0
-0include/linux/audit.h line 25
Quoted 8 lines
include/linux/audit.h +1
-1@@ -19,7 +19,7 @@struct audit_sig_info {uid_t uid;pid_t pid; -char ctx[0 ]; +char ctx[]; };struct audit_buffer ;- RGB
- RGB
--
Richard Guy Briggs <[email protected]>
Sr. S/W Engineer, Kernel Security, Base Operating Systems Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
Quoted 8 lines · Paul Moore
Quoted 5 lines
Signed-off-by Gustavo A. R. Silva <[email protected]>--- include/linux/audit.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)Merged into audit/next, thanks!
Thanks, Paul.
--
Gustavo