deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2024-49912
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Handle null 'stream_status' in 'planes_changed_for_existing_stream'

This commit adds a null check for 'stream_status' in the function
'planes_changed_for_existing_stream'. Previously, the code assumed
'stream_status' could be null, but did not handle the case where it was
actually null. This could lead to a null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_resource.c:3784 planes_changed_for_existing_stream() error: we previously assumed 'stream_status' could be null (see line 3774)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0ffd9fb03bbc99ed1eb5dc989d5c7da2faac0659; https://git.kernel.org/stable/c/4778982c73d6c9f3fdbdbc6b6c8aa18df98251af; https://git.kernel.org/stable/c/8141f21b941710ecebe49220b69822cab3abd23d
CVE: CVE-2024-49913
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream

This commit addresses a null pointer dereference issue in the
`commit_planes_for_stream` function at line 4140. The issue could occur
when `top_pipe_to_program` is null.

The fix adds a check to ensure `top_pipe_to_program` is not null before
accessing its stream_res. This prevents a null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed 'top_pipe_to_program' could be null (see line 3906)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1ebfa6663807c144be8c8b[PII_REDACTED]409d2356; https://git.kernel.org/stable/c/3929e382e4758aff42da0102a60d13337c99d3b8; https://git.kernel.org/stable/c/40193ff73630adf76bc0d82398f7d90fb576dba4
CVE: CVE-2024-49914
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for pipe_ctx->plane_state in dcn20_program_pipe

This commit addresses a null pointer dereference issue in the
`dcn20_program_pipe` function. The issue could occur when
`pipe_ctx->plane_state` is null.

The fix adds a check to ensure `pipe_ctx->plane_state` is not null
before accessing. This prevents a null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn20/dcn20_hwseq.c:1925 dcn20_program_pipe() error: we previously assumed 'pipe_ctx->plane_state' could be null (see line 1877)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/65a6fee22d5cfa645cb05489892dc9cd3d142fc2; https://git.kernel.org/stable/c/68f75e6f08aad66069a629db8d[PII_REDACTED]c761; https://git.kernel.org/stable/c/8e4ed3cf1642df0c4456443d865cff61a9598aa8
CVE: CVE-2024-49915
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL check for clk_mgr in dcn32_init_hw

This commit addresses a potential null pointer dereference issue in the
`dcn32_init_hw` function. The issue could occur when `dc->clk_mgr` is
null.

The fix adds a check to ensure `dc->clk_mgr` is not null before
accessing its functions. This prevents a potential null pointer
dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn32/dcn32_hwseq.c:961 dcn32_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 782)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/0d94d9cbd9fec7344d230c4f7b781826f7799c60; https://git.kernel.org/stable/c/7d1854c86d02cea8f8a0c0ca05f4ab14292baf3d; https://git.kernel.org/stable/c/c395fd47d1565bd67671f45cca281b3acc2c31ef
CVE: CVE-2024-49916
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn401_init_hw

This commit addresses a potential null pointer dereference issue in the
`dcn401_init_hw` function. The issue could occur when `dc->clk_mgr` or
`dc->clk_mgr->funcs` is null.

The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is
not null before accessing its functions. This prevents a potential null
pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn401/dcn401_hwseq.c:416 dcn401_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 225)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4b6377f0e96085cbec96eb7f0b282430ccdd3d75; https://git.kernel.org/stable/c/ac1c41e318074d8a9ea925787e366be15d7645e8
CVE: CVE-2024-49917
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add NULL check for clk_mgr and clk_mgr->funcs in dcn30_init_hw

This commit addresses a potential null pointer dereference issue in the
`dcn30_init_hw` function. The issue could occur when `dc->clk_mgr` or
`dc->clk_mgr->funcs` is null.

The fix adds a check to ensure `dc->clk_mgr` and `dc->clk_mgr->funcs` is
not null before accessing its functions. This prevents a potential null
pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed 'dc->clk_mgr' could be null (see line 628)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/205e3b96cc9aa9211fd2c849a16245cf236b2d36; https://git.kernel.org/stable/c/23cb[PII_REDACTED]dc36743586ca86fbb3f7ab2c9d; https://git.kernel.org/stable/c/5443c83eb8fd2f88c71ced38848fbf744d6206a2
CVE: CVE-2024-49918
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for head_pipe in dcn32_acquire_idle_pipe_for_head_pipe_in_layer

This commit addresses a potential null pointer dereference issue in the
`dcn32_acquire_idle_pipe_for_head_pipe_in_layer` function. The issue
could occur when `head_pipe` is null.

The fix adds a check to ensure `head_pipe` is not null before asserting
it. If `head_pipe` is null, the function returns NULL to prevent a
potential null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn32/dcn32_resource.c:2690 dcn32_acquire_idle_pipe_for_head_pipe_in_layer() error: we previously assumed 'head_pipe' could be null (see line 2681)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4f47292f488fa7041284dca1f1244116c18721f1; https://git.kernel.org/stable/c/96d4c2ee18d732a248d053aae8c4a27cb1d68d1c; https://git.kernel.org/stable/c/ac[PII_REDACTED]a26eac99585b7f69814bd3ba8f2d
CVE: CVE-2024-49919
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Add null check for head_pipe in dcn201_acquire_free_pipe_for_layer

This commit addresses a potential null pointer dereference issue in the
`dcn201_acquire_free_pipe_for_layer` function. The issue could occur
when `head_pipe` is null.

The fix adds a check to ensure `head_pipe` is not null before asserting
it. If `head_pipe` is null, the function returns NULL to prevent a
potential null pointer dereference.

Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/resource/dcn201/dcn201_resource.c:1016 dcn201_acquire_free_pipe_for_layer() error: we previously assumed 'head_pipe' could be null (see line 1010)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/16ce8fd94da8599bb6f0496895d392a69aead1c0; https://git.kernel.org/stable/c/390d757621f5f35d11a63ed7d9d3262ead240064; https://git.kernel.org/stable/c/8a1b1655a490a492a5a6987254c935ecce4eb9de
CVE: CVE-2024-49920
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before multiple uses

[WHAT & HOW]
Poniters, such as stream_enc and dc->bw_vbios, are null checked previously
in the same function, so Coverity warns "implies that stream_enc and
dc->bw_vbios might be null". They are used multiple times in the
subsequent code and need to be checked.

This fixes 10 FORWARD_NULL issues reported by Coverity.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/26787fb6c2b2ee0d1a7e1574b36f4711ae40fe27; https://git.kernel.org/stable/c/fdd5ecbbff751c3b9061d8ebb08e5c96119915b4
CVE: CVE-2024-49921
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before used

[WHAT & HOW]
Poniters, such as dc->clk_mgr, are null checked previously in the same
function, so Coverity warns "implies that "dc->clk_mgr" might be null".
As a result, these pointers need to be checked when used again.

This fixes 10 FORWARD_NULL issues reported by Coverity.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/5b35bf1a82eb29841b67ff5643ba83762250fc24; https://git.kernel.org/stable/c/be1fb44389ca3038ad2430dac4234669bc177ee3
CVE: CVE-2024-49922
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Check null pointers before using them

[WHAT & HOW]
These pointers are null checked previously in the same function,
indicating they might be null as reported by Coverity. As a result,
they need to be checked when used again.

This fixes 3 FORWARD_NULL issue reported by Coverity.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/1ff12bcd7deaeed25efb5120433c6a45dd5504a8; https://git.kernel.org/stable/c/5e9386baa3033c369564d55de4bab62423e8a1d3; https://git.kernel.org/stable/c/65e1d2c291553ef3f433a0b7109cc3002a5f40ae
CVE: CVE-2024-49923
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Pass non-null to dcn20_validate_apply_pipe_split_flags

[WHAT & HOW]
"dcn20_validate_apply_pipe_split_flags" dereferences merge, and thus it
cannot be a null pointer. Let's pass a valid pointer to avoid null
dereference.

This fixes 2 FORWARD_NULL issues reported by Coverity.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/39a580cd15397e102aaec25986ae5acf492f8930; https://git.kernel.org/stable/c/[PII_REDACTED]fb4538e4c51c48ef70563c49c2af23; https://git.kernel.org/stable/c/85aa996ecfaa95d1e[PII_REDACTED]02d23ce21b905
CVE: CVE-2024-49924
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: pxafb: Fix possible use after free in pxafb_task()

In the pxafb_probe function, it calls the pxafb_init_fbinfo function,
after which &fbi->task is associated with pxafb_task. Moreover,
within this pxafb_init_fbinfo function, the pxafb_blank function
within the &pxafb_ops struct is capable of scheduling work.

If we remove the module which will call pxafb_remove to make cleanup,
it will call unregister_framebuffer function which can call
do_unregister_framebuffer to free fbi->fb through
put_fb_info(fb_info), while the work mentioned above will be used.
The sequence of operations that may lead to a UAF bug is as follows:

CPU0                                                CPU1

                                   | pxafb_task
pxafb_remove                       |
unregister_framebuffer(info)       |
do_unregister_framebuffer(fb_info) |
put_fb_info(fb_info)               |
// free fbi->fb                    | set_ctrlr_state(fbi, state)
                                   | __pxafb_lcd_power(fbi, 0)
                                   | fbi->lcd_power(on, &fbi->fb.var)
                                   | //use fbi->fb

Fix it by ensuring that the work is canceled before proceeding
with the cleanup in pxafb_remove.

Note that only root user can remove the driver at runtime.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/3c0d416eb4bef705f699213cee94bf54b6acdacd; https://git.kernel.org/stable/c/4a6921095eb04a900e0000da83d9475eb958e61e; https://git.kernel.org/stable/c/4cda484e584be34d55ee17436ebf7ad11922b97a
CVE: CVE-2024-49925
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

fbdev: efifb: Register sysfs groups through driver core

The driver core can register and cleanup sysfs groups already.
Make use of that functionality to simplify the error handling and
cleanup.

Also avoid a UAF race during unregistering where the sysctl attributes
were usable after the info struct was freed.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-416
References: https://git.kernel.org/stable/c/2a9c40c72097b583b23aeb2a26d429ccfc81fbc1; https://git.kernel.org/stable/c/36bfefb6baaa8e46de44f4fd919ce[PII_REDACTED]f; https://git.kernel.org/stable/c/4684d69b9670a83992189f6271dc0fcdec4ed0d7
CVE: CVE-2024-49926
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

rcu-tasks: Fix access non-existent percpu rtpcp variable in rcu_tasks_need_gpcb()

For kernels built with CONFIG_FORCE_NR_CPUS=y, the nr_cpu_ids is
defined as NR_CPUS instead of the number of possible cpus, this
will cause the following system panic:

smpboot: Allowing 4 CPUs, 0 hotplug CPUs
...
setup_percpu: NR_CPUS:512 nr_cpumask_bits:512 nr_cpu_ids:512 nr_node_ids:1
...
BUG: unable to handle page fault for address: ffffffff9911c8c8
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 0 PID: 15 Comm: rcu_tasks_trace Tainted: G W
6.6.21 #1 5dc7acf91a5e8e9ac9dcfc35bee[PII_REDACTED]ea6
RIP: 0010:rcu_tasks_need_gpcb+0x25d/0x2c0
RSP: 0018:ffffa371c00a3e60 EFLAGS: 00010082
CR2: ffffffff9911c8c8 CR3: 000000040fa20005 CR4:[PII_REDACTED]1706f0
Call Trace:
<TASK>
? __die+0x23/0x80
? page_fault_oops+0xa4/0x180
? exc_page_fault+0x152/0x180
? asm_exc_page_fault+0x26/0x40
? rcu_tasks_need_gpcb+0x25d/0x2c0
? __pfx_rcu_tasks_kthread+0x40/0x40
rcu_tasks_one_gp+0x69/0x180
rcu_tasks_kthread+0x94/0xc0
kthread+0xe8/0x140
? __pfx_kthread+0x40/0x40
ret_from_fork+0x34/0x80
? __pfx_kthread+0x40/0x40
ret_from_fork_asm+0x1b/0x80
</TASK>

Considering that there may be holes in the CPU numbers, use the
maximum possible cpu number, instead of nr_cpu_ids, for configuring
enqueue and dequeue limits.

[ neeraj.upadhyay: Fix htmldocs build error reported by Stephen Rothwell ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/05095271a4fb0f6497121a057f9a2edf386d5d96; https://git.kernel.org/stable/c/3104bddc666ff64b90491868bbc4c7ebdd90aedf; https://git.kernel.org/stable/c/b3b2431ed27f4ebc28e26cdf005c1de42dc60bdf
CVE: CVE-2024-49927
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/ioapic: Handle allocation failures gracefully

Breno observed panics when using failslab under certain conditions during
runtime:

   can not alloc irq_pin_list (-1,0,20)
   Kernel panic - not syncing: IO-APIC: failed to add irq-pin. Can not proceed

   panic+0x4e9/0x590
   mp_irqdomain_alloc+0x9ab/0xa80
   irq_domain_alloc_irqs_locked+0x25d/0x8d0
   __irq_domain_alloc_irqs+0x80/0x110
   mp_map_pin_to_irq+0x645/0x890
   acpi_register_gsi_ioapic+0xe6/0x150
   hpet_open+0x313/0x480

That's a pointless panic which is a leftover of the historic IO/APIC code
which panic'ed during early boot when the interrupt allocation failed.

The only place which might justify panic is the PIT/HPET timer_check() code
which tries to figure out whether the timer interrupt is delivered through
the IO/APIC. But that code does not require to handle interrupt allocation
failures. If the interrupt cannot be allocated then timer delivery fails
and it either panics due to that or falls back to legacy mode.

Cure this by removing the panic wrapper around __add_pin_to_irq_node() and
making mp_irqdomain_alloc() aware of the failure condition and handle it as
any other failure in this function gracefully.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/077e1b7cd521163ded545987bbbd389519aeed71; https://git.kernel.org/stable/c/649a5c2ffae797ce792023a70e84c7fe4b6fb8e0; https://git.kernel.org/stable/c/830802a0fea8fb39d3dc9fb7d6b5581e1343eb1f
CVE: CVE-2024-49928
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: rtw89: avoid reading out of bounds when loading TX power FW elements

Because the loop-expression will do one more time before getting false from
cond-expression, the original code copied one more entry size beyond valid
region.

Fix it by moving the entry copy to loop-body.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/4007c3d2da31d0c755ea3fcf55e395118e5d5621; https://git.kernel.org/stable/c/83c84cdb75572048b67d6a3916283aeac865996e; https://git.kernel.org/stable/c/ed2e4bb17a4884cf29c3347353d8aabb7265b46c
CVE: CVE-2024-49929
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: iwlwifi: mvm: avoid NULL pointer dereference

iwl_mvm_tx_skb_sta() and iwl_mvm_tx_mpdu() verify that the mvmvsta
pointer is not NULL.
It retrieves this pointer using iwl_mvm_sta_from_mac80211, which is
dereferencing the ieee80211_sta pointer.
If sta is NULL, iwl_mvm_sta_from_mac80211 will dereference a NULL
pointer.
Fix this by checking the sta pointer before retrieving the mvmsta
from it. If sta is not NULL, then mvmsta isn't either.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/557a6cd847645e667f3b362560bd7e7c09aac284; https://git.kernel.org/stable/c/6dcadb2ed3b76623ab96e3e7fbeda1a374d01c28; https://git.kernel.org/stable/c/c0b4f5d94934c[PII_REDACTED]68a32c15ba36a6d9e
CVE: CVE-2024-49930
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath11k: fix array out-of-bound access in SoC stats

Currently, the ath11k_soc_dp_stats::hal_reo_error array is defined with a
maximum size of DP_REO_DST_RING_MAX. However, the ath11k_dp_process_rx()
function access ath11k_soc_dp_stats::hal_reo_error using the REO
destination SRNG ring ID, which is incorrect. SRNG ring ID differ from
normal ring ID, and this usage leads to out-of-bounds array access. To fix
this issue, modify ath11k_dp_process_rx() to use the normal ring ID
directly instead of the SRNG ring ID to avoid out-of-bounds array access.

Tested-on: QCN9074 hw1.0 PCI WLAN.HK.2.7.0.1-01744-QCAHKSWPL_SILICONZ-1
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/01b77f5ee11c89754fb836af8f76799d3b72ae2f; https://git.kernel.org/stable/c/0f26f26944035ec67546a944f182cbad6577a9c0; https://git.kernel.org/stable/c/4dd732893bd38cec51f887244314e2b47f0d658f
CVE: CVE-2024-49931
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: ath12k: fix array out-of-bound access in SoC stats

Currently, the ath12k_soc_dp_stats::hal_reo_error array is defined with a
maximum size of DP_REO_DST_RING_MAX. However, the ath12k_dp_rx_process()
function access ath12k_soc_dp_stats::hal_reo_error using the REO
destination SRNG ring ID, which is incorrect. SRNG ring ID differ from
normal ring ID, and this usage leads to out-of-bounds array access. To
fix this issue, modify ath12k_dp_rx_process() to use the normal ring ID
directly instead of the SRNG ring ID to avoid out-of-bounds array access.

Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
CVSS Score: 7.8 (HIGH)
CWE: CWE-129
References: https://git.kernel.org/stable/c/a4aef827a41cdaf6201bbaf773c1eae4e20e967b; https://git.kernel.org/stable/c/ad791e3ec60cb66c1e4dc121ffbf872df312427d; https://git.kernel.org/stable/c/d0e4274d9dc9f8409d56d622cd3ecf7b6fd49e2f
CVE: CVE-2024-49933
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

blk_iocost: fix more out of bound shifts

Recently running UBSAN caught few out of bound shifts in the
ioc_forgive_debts() function:

UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38
shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long
long')
...
UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30
shift exponent 80 is too large for 64-bit type 'u64' (aka 'unsigned long
long')
...
Call Trace:
<IRQ>
dump_stack_lvl+0xca/0x130
__ubsan_handle_shift_out_of_bounds+0x22c/0x280
? __lock_acquire+0x6441/0x7c10
ioc_timer_fn+0x6cec/0x7750
? blk_iocost_init+0x720/0x720
? call_timer_fn+0x5d/0x470
call_timer_fn+0xfa/0x470
? blk_iocost_init+0x720/0x720
__run_timer_base+0x519/0x700
...

Actual impact of this issue was not identified but I propose to fix the
undefined behaviour.
The proposed fix to prevent those out of bound shifts consist of
precalculating exponent before using it the shift operations by taking
min value from the actual exponent and maximum possible number of bits.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/1ab2cfe19700fb3dde4c7dfec392acff34db3120; https://git.kernel.org/stable/c/1b120f151871eb47ce9f283c007af3f8ae1d990e; https://git.kernel.org/stable/c/1f61d509257d6a05763d05bf37943b35306522b1
CVE: CVE-2024-49935
Published: 2024-10-21
Description: In the Linux kernel, the following vulnerability has been resolved:

ACPI: PAD: fix crash in exit_round_robin()

The kernel occasionally crashes in cpumask_clear_cpu(), which is called
within exit_round_robin(), because when executing clear_bit(nr, addr) with
nr set to 0xffffffff, the address calculation may cause misalignment within
the memory, leading to access to an invalid memory address.

----------
BUG: unable to handle kernel paging request at ffffffffe0740618
        ...
CPU: 3 PID: 2919323 Comm: acpi_pad/14 Kdump: loaded Tainted: G           OE  X --------- -  - 4.18.0-425.19.2.el8_7.x86_64 #1
        ...
RIP: 0010:power_saving_thread+0x313/0x411 [acpi_pad]
Code: 89 cd 48 89 d3 eb d1 48 c7 c7 55 70 72 c0 e8 64 86 b0 e4 c6 05 0d a1 02 00 01 e9 bc fd ff ff 45 89 e4 42 8b 04 a5 20 82 72 c0 <f0> 48 0f b3 05 f4 9c 01 00 42 c7 04 a5 20 82 72 c0 ff ff ff ff 31
RSP: 0018:ff72a5d51fa77ec8 EFLAGS: 00010202
RAX: 00000000ffffffff RBX: ff462981e5d8cb80 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: [PII_REDACTED] RDI: [PII_REDACTED]
RBP: ff[PII_REDACTED]9d80 R08: [PII_REDACTED] R09: ff46297c8d0f38d8
R10: [PII_REDACTED] R11: [PII_REDACTED] R12:[PII_REDACTED]00000e
R13: [PII_REDACTED] R14: ffffffffffffffff R15:[PII_REDACTED]00000e
FS:  [PII_REDACTED](0000) GS:ff46297a800c0000(0000) knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: ffffffffe0740618 CR3: 0000007e20410004 CR4:[PII_REDACTED]771ee0
DR0: [PII_REDACTED] DR1: [PII_REDACTED] DR2: [PII_REDACTED]
DR3: [PII_REDACTED] DR6: 00000000fffe0ff0 DR7: [PII_REDACTED]
PKRU: 55555554
Call Trace:
 ? acpi_pad_add+0x120/0x120 [acpi_pad]
 kthread+0x10b/0x130
 ? set_kthread_struct+0x50/0x50
 ret_from_fork+0x1f/0x40
        ...
CR2: ffffffffe0740618

crash> dis -lr ffffffffc0726923
        ...
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 114
0xffffffffc0726918 <power_saving_thread+776>:	mov    %r12d,%r12d
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./include/linux/cpumask.h: 325
0xffffffffc072691b <power_saving_thread+779>:	mov    -0x3f8d7de0(,%r12,4),%eax
/usr/src/debug/kernel-4.18.0-425.19.2.el8_7/linux-4.18.0-425.19.2.el8_7.x86_64/./arch/x86/include/asm/bitops.h: 80
0xffffffffc0726923 <power_saving_thread+787>:	lock btr %rax,0x19cf4(%rip)        # 0xffffffffc0740620 <pad_busy_cpus_bits>

crash> px tsk_in_cpu[14]
$66 = 0xffffffff

crash> px 0xffffffffc072692c+0x19cf4
$99 = 0xffffffffc0740620

crash> sym 0xffffffffc0740620
ffffffffc0740620 (b) pad_busy_cpus_bits [acpi_pad]

crash> px pad_busy_cpus_bits[0]
$42 = 0xfffc0
----------

To fix this, ensure that tsk_in_cpu[tsk_index] != -1 before calling
cpumask_clear_cpu() in exit_round_robin(), just as it is done in
round_robin_cpu().

[ rjw: Subject edit, avoid updates to the same value ]
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/03593dbb0b272ef7b0358b099841e65735422aca; https://git.kernel.org/stable/c/0a2ed70a549e61c5181bad5db418d223b68ae932; https://git.kernel.org/stable/c/27c045f868f0e5052c6b532868a65e0cd250c8fc