Логотип exploitDog
Консоль
Логотип exploitDog

exploitDog

Количество 10

Количество 10

ubuntu логотип

CVE-2026-74351

2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: l...

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

CVE-2026-74351

2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: l...

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

CVE-2026-74351

2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader:

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

CVE-2026-74351

2 месяца назад

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

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

ROS-20260917-80-0033

около 1 месяца назад

Уязвимость kernel-lt

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

ROS-20260917-73-0028

около 1 месяца назад

Уязвимость kernel-lt

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

GHSA-277m-9mg9-wh9q

2 месяца назад

In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: ...

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

BDU:2026-16670

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

Уязвимость функций ocfs2_dlm_seq_next() и ocfs2_dlm_seq_show() компонента fs/ocfs2/dlmglue.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

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

ELSA-2026-500249

около 2 месяцев назад

ELSA-2026-500249: Unbreakable Enterprise kernel security update (IMPORTANT)

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

ELSA-2026-500248

около 2 месяцев назад

ELSA-2026-500248: Unbreakable Enterprise kernel security update (IMPORTANT)

EPSS: Низкий

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

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

In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: l...

0%
Низкий
2 месяца назад
redhat логотип
CVE-2026-74351

In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: l...

CVSS3: 5.5
0%
Низкий
2 месяца назад
nvd логотип
CVE-2026-74351

In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader:

0%
Низкий
2 месяца назад
debian логотип
CVE-2026-74351

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

0%
Низкий
2 месяца назад
redos логотип
ROS-20260917-80-0033

Уязвимость kernel-lt

CVSS3: 7.8
0%
Низкий
около 1 месяца назад
redos логотип
ROS-20260917-73-0028

Уязвимость kernel-lt

CVSS3: 7.8
0%
Низкий
около 1 месяца назад
github логотип
GHSA-277m-9mg9-wh9q

In the Linux kernel, the following vulnerability has been resolved: ocfs2: rebase copied fsdlm LVB pointers in locking_state The locking_state debugfs iterator snapshots struct ocfs2_lock_res by value under ocfs2_dlm_tracking_lock and later formats that copy in ocfs2_dlm_seq_show(). That is fine for the inline fields, but the userspace fsdlm stack stores the LVB through lksb_fsdlm.sb_lvbptr. Once the iterator drops the tracking lock, a copied non-NULL sb_lvbptr still points into the original lockres owner, so teardown can free that container before the debugfs dump walks the raw LVB bytes. Rebase the copied sb_lvbptr to the copied l_lksb before dumping the raw LVB. The seq snapshot already carries the inline LVB storage reserved in struct ocfs2_dlm_lksb, so the debugfs reader can dump the copied bytes without borrowing the original lockres lifetime. The buggy scenario involves two paths, with each column showing the order within that path: locking_state reader: ...

0%
Низкий
2 месяца назад
fstec логотип
BDU:2026-16670

Уязвимость функций ocfs2_dlm_seq_next() и ocfs2_dlm_seq_show() компонента fs/ocfs2/dlmglue.c ядра операционной системы Linux, позволяющая нарушителю оказать воздействие на конфиденциальность, целостность и доступность защищаемой информации

CVSS3: 7.8
0%
Низкий
5 месяцев назад
oracle-oval логотип
ELSA-2026-500249

ELSA-2026-500249: Unbreakable Enterprise kernel security update (IMPORTANT)

около 2 месяцев назад
oracle-oval логотип
ELSA-2026-500248

ELSA-2026-500248: Unbreakable Enterprise kernel security update (IMPORTANT)

около 2 месяцев назад

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

exploitDog - Комплексное решение для обнаружения, оценки и устранения уязвимостей.