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

exploitDog

Количество 10

Количество 10

ubuntu логотип

CVE-2026-23465

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, ...

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

CVE-2026-23465

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, ...

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

CVE-2026-23465

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted direc

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

CVE-2026-23465

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

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

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

GHSA-wm46-26gp-9px3

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted di...

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

BDU:2026-12348

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

Уязвимость функции log_conflicting_inodes() модуля fs/btrfs/tree-log.c файловой системы Btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

CVSS3: 5.5
EPSS: Низкий
suse-cvrf логотип

SUSE-SU-2026:2217-1

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

Security update for the Linux Kernel

EPSS: Низкий
suse-cvrf логотип

SUSE-SU-2026:2238-1

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

Security update for the Linux Kernel

EPSS: Низкий
suse-cvrf логотип

openSUSE-SU-2026:20826-1

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

Security update for the Linux Kernel

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

ELSA-2026-50372

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

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

EPSS: Низкий

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

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, ...

CVSS3: 5.5
0%
Низкий
5 месяцев назад
redhat логотип
CVE-2026-23465

In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted directory) does not exists anymore, ...

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

In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted direc

CVSS3: 5.5
0%
Низкий
5 месяцев назад
debian логотип
CVE-2026-23465

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

CVSS3: 5.5
0%
Низкий
5 месяцев назад
github логотип
GHSA-wm46-26gp-9px3

In the Linux kernel, the following vulnerability has been resolved: btrfs: log new dentries when logging parent dir of a conflicting inode If we log the parent directory of a conflicting inode, we are not logging the new dentries of the directory, so when we finish we have the parent directory's inode marked as logged but we did not log its new dentries. As a consequence if the parent directory is explicitly fsynced later and it does not have any new changes since we logged it, the fsync is a no-op and after a power failure the new dentries are missing. Example scenario: $ mkdir foo $ sync $rmdir foo $ mkdir dir1 $ mkdir dir2 # A file with the same name and parent as the directory we just deleted # and was persisted in a past transaction. So the deleted directory's # inode is a conflicting inode of this new file's inode. $ touch foo $ ln foo dir2/link # The fsync on dir2 will log the parent directory (".") because the # conflicting inode (deleted di...

CVSS3: 5.5
0%
Низкий
5 месяцев назад
fstec логотип
BDU:2026-12348

Уязвимость функции log_conflicting_inodes() модуля fs/btrfs/tree-log.c файловой системы Btrfs ядра операционной системы Linux, позволяющая нарушителю вызвать отказ в обслуживании

CVSS3: 5.5
0%
Низкий
6 месяцев назад
suse-cvrf логотип
SUSE-SU-2026:2217-1

Security update for the Linux Kernel

3 месяца назад
suse-cvrf логотип
SUSE-SU-2026:2238-1

Security update for the Linux Kernel

2 месяца назад
suse-cvrf логотип
openSUSE-SU-2026:20826-1

Security update for the Linux Kernel

4 месяца назад
oracle-oval логотип
ELSA-2026-50372

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

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

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

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