diff options
| author | Danila Chernetsov <listdansp@mail.ru> | 2026-09-01 13:47:12 -0400 |
|---|---|---|
| committer | David Teigland <teigland@redhat.com> | 2026-09-02 09:01:52 -0500 |
| commit | 7bf1aca6d626944091a5cb218b4e487547edff0a (patch) | |
| tree | dbc1f3e2bc9603d480bc265e94cd8817f0c646b3 /tools/perf/scripts/python/flamegraph.py | |
| parent | d785f7d92f197b72d496bbcf54a160cd54f00263 (diff) | |
| download | linux-7bf1aca6d626944091a5cb218b4e487547edff0a.tar.gz linux-7bf1aca6d626944091a5cb218b4e487547edff0a.zip | |
dlm: validate lock modes in recovery messages
The DLM recovery path restores lock state from rcom_lock messages
received from remote nodes. The lock modes in these messages are
copied directly into the local lkb state without validating that they
are within the valid DLM lock mode range.
The rest of the DLM code assumes that lkb_rqmode and lkb_grmode
contain valid lock modes. In particular, LVB callback handling in
dlm_may_skip_callback() uses lock modes as indexes into the
dlm_lvb_operations array:
dlm_lvb_operations[prev_mode + 1][mode + 1]
An invalid lock mode received during recovery could therefore result in
an out-of-bounds read during subsequent LVB callback processing.
Validate rl_rqmode and rl_grmode before storing them into the local LKB
state. This preserves the lock mode invariant required by the rest of
the DLM code.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixes: e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM")
Acked-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: Danila Chernetsov <listdansp@mail.ru>
Signed-off-by: Alexander Aring <aahringo@redhat.com>
Signed-off-by: David Teigland <teigland@redhat.com>
Diffstat (limited to 'tools/perf/scripts/python/flamegraph.py')
0 files changed, 0 insertions, 0 deletions
