|
Revision tags: release/12.2.0, release/11.4.0 |
|
| #
b6c023d0 |
| 28-Jan-2020 |
Gordon Tetlow <[email protected]> |
Fix imprecise ordering of SSP canary initialization
Submitted by: Kyle Evans
Approved by: so
Security: FreeBSD-EN-20:01.ssp
|
|
Revision tags: release/12.1.0, release/11.3.0, release/12.0.0, release/11.2.0 |
|
| #
989b861f |
| 24-Apr-2018 |
Konstantin Belousov <[email protected]> |
Carefully update stack guard bytes inside __guard_setup().
This is necessary to make sure that functions that can have stack
protection are not used to update the stack guard. If not, the stack
guar
Carefully update stack guard bytes inside __guard_setup().
This is necessary to make sure that functions that can have stack
protection are not used to update the stack guard. If not, the stack
guard check would fail when it shouldn't.
guard_setup() calls elf_aux_info(), which, in turn, calls memcpy() to
update stack_chk_guard. If either elf_aux_info() or memcpy() have
stack protection enabled, __stack_chk_guard will be modified before
returning from them, causing the stack protection check to fail.
This change uses a temporary buffer to delay changing
__stack_chk_guard until elf_aux_info() returns.
Submitted by: Luis Pires
MFC after: 1 week
Differential revision: https://reviews.freebsd.org/D15173
show more ...
|
|
Revision tags: release/10.4.0, release/11.1.0, release/11.0.1, release/11.0.0 |
|
| #
2cf5e936 |
| 18-Apr-2016 |
Andriy Voskoboinyk <[email protected]> |
libc: do not include <sys/types.h> where <sys/param.h> was already included
According to style(9):
> normally, include <sys/types.h> OR <sys/param.h>, but not both.
(<sys/param.h> already includes <
libc: do not include <sys/types.h> where <sys/param.h> was already included
According to style(9):
> normally, include <sys/types.h> OR <sys/param.h>, but not both.
(<sys/param.h> already includes <sys/types.h> when LOCORE is not defined).
show more ...
|
|
Revision tags: release/10.3.0 |
|
| #
fe0d386c |
| 14-Aug-2015 |
Pedro F. Giffuni <[email protected]> |
Move the stack protector to a new "secure" directory
As part of the code refactoring to support FORTIFY_SOURCE we want
a new subdirectory "secure" to keep the files related to security.
Move the sta
Move the stack protector to a new "secure" directory
As part of the code refactoring to support FORTIFY_SOURCE we want
a new subdirectory "secure" to keep the files related to security.
Move the stack protector functions to this new directory.
No functional change.
Differential Review: https://reviews.freebsd.org/D3333
show more ...
|