Логотип exploitDog
bind:CVE-2024-40974
Консоль
Логотип exploitDog

exploitDog

bind:CVE-2024-40974

Количество 13

Количество 13

ubuntu логотип

CVE-2024-40974

11 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error...

EPSS: Низкий
redhat логотип

CVE-2024-40974

11 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array...

CVSS3: 6.6
EPSS: Низкий
nvd логотип

CVE-2024-40974

11 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: erro

EPSS: Низкий
debian логотип

CVE-2024-40974

11 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: p ...

EPSS: Низкий
github логотип

GHSA-gv48-p56m-p3qj

11 месяцев назад

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: e...

EPSS: Низкий
fstec логотип

BDU:2025-01048

около 1 года назад

Уязвимость компонентов powerpc/pseries ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

CVSS3: 6.6
EPSS: Низкий
redos логотип

ROS-20250117-06

5 месяцев назад

Множественные уязвимости kernel-lt

CVSS3: 7.8
EPSS: Низкий
oracle-oval логотип

ELSA-2024-12779

8 месяцев назад

ELSA-2024-12779: Unbreakable Enterprise kernel security update (IMPORTANT)

EPSS: Низкий
oracle-oval логотип

ELSA-2024-12612

9 месяцев назад

ELSA-2024-12612: Unbreakable Enterprise kernel-container security update (IMPORTANT)

EPSS: Низкий
oracle-oval логотип

ELSA-2024-12610

9 месяцев назад

ELSA-2024-12610: Unbreakable Enterprise kernel security update (IMPORTANT)

EPSS: Низкий
oracle-oval логотип

ELSA-2024-12618

9 месяцев назад

ELSA-2024-12618: Unbreakable Enterprise kernel security update (IMPORTANT)

EPSS: Низкий
rocky логотип

RLSA-2024:5101

10 месяцев назад

Important: kernel security update

EPSS: Низкий
oracle-oval логотип

ELSA-2024-5101

11 месяцев назад

ELSA-2024-5101: kernel security update (IMPORTANT)

EPSS: Низкий

Уязвимостей на страницу

Уязвимость
CVSS
EPSS
Опубликовано
ubuntu логотип
CVE-2024-40974

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error...

0%
Низкий
11 месяцев назад
redhat логотип
CVE-2024-40974

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: error: array...

CVSS3: 6.6
0%
Низкий
11 месяцев назад
nvd логотип
CVE-2024-40974

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: erro

0%
Низкий
11 месяцев назад
debian логотип
CVE-2024-40974

In the Linux kernel, the following vulnerability has been resolved: p ...

0%
Низкий
11 месяцев назад
github логотип
GHSA-gv48-p56m-p3qj

In the Linux kernel, the following vulnerability has been resolved: powerpc/pseries: Enforce hcall result buffer validity and size plpar_hcall(), plpar_hcall9(), and related functions expect callers to provide valid result buffers of certain minimum size. Currently this is communicated only through comments in the code and the compiler has no idea. For example, if I write a bug like this: long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...); This compiles with no diagnostics emitted, but likely results in stack corruption at runtime when plpar_hcall9() stores results past the end of the array. (To be clear this is a contrived example and I have not found a real instance yet.) To make this class of error less likely, we can use explicitly-sized array parameters instead of pointers in the declarations for the hcall APIs. When compiled with -Warray-bounds[1], the code above now provokes a diagnostic like this: e...

0%
Низкий
11 месяцев назад
fstec логотип
BDU:2025-01048

Уязвимость компонентов powerpc/pseries ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

CVSS3: 6.6
0%
Низкий
около 1 года назад
redos логотип
ROS-20250117-06

Множественные уязвимости kernel-lt

CVSS3: 7.8
5 месяцев назад
oracle-oval логотип
ELSA-2024-12779

ELSA-2024-12779: Unbreakable Enterprise kernel security update (IMPORTANT)

8 месяцев назад
oracle-oval логотип
ELSA-2024-12612

ELSA-2024-12612: Unbreakable Enterprise kernel-container security update (IMPORTANT)

9 месяцев назад
oracle-oval логотип
ELSA-2024-12610

ELSA-2024-12610: Unbreakable Enterprise kernel security update (IMPORTANT)

9 месяцев назад
oracle-oval логотип
ELSA-2024-12618

ELSA-2024-12618: Unbreakable Enterprise kernel security update (IMPORTANT)

9 месяцев назад
rocky логотип
RLSA-2024:5101

Important: kernel security update

10 месяцев назад
oracle-oval логотип
ELSA-2024-5101

ELSA-2024-5101: kernel security update (IMPORTANT)

11 месяцев назад

Уязвимостей на страницу