huzaifas-sidhpurwala/security-commit huggingface dataset:
CVE-2022-49504: kernel: scsi: lpfc: Inhibit aborts if external loopback plug is inserted
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

scsi: lpfc: Inhibit aborts if external loopback plug is inserted

After running a short external loopback test, when the external loopback is
removed and a normal cable inserted that is directly connected to a target
device, the system oops in the llpfc_set_rrq_active() routine.

When the loopback was inserted an FLOGI was transmit. As we're looped back,
we receive the FLOGI request. The FLOGI is ABTS'd as we recognize the same
wppn thus understand it's a loopback. However, as the ABTS sends address
information the port is not set to (fffffe), the ABTS is dropped on the
wire. A short 1 frame loopback test is run and completes before the ABTS
times out. The looback is unplugged and the new cable plugged in, and the
an FLOGI to the new device occurs and completes. Due to a mixup in ref
counting the completion of the new FLOGI releases the fabric ndlp. Then the
original ABTS completes and references the released ndlp generating the
oops.

Correct by no-op'ing the ABTS when in loopback mode (it will be dropped
anyway). Added a flag to track the mode to recognize when it should be
no-op'd.


Affected upstream versions: 3.3
Fixed upstream versions: 0, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a1516930cb605caee3bc7b4f3b7994b88c0b8505
CVE-2022-49511: kernel: fbdev: defio: fix the pagelist corruption
Component: kernel
Severity: Low
CWE: CWE-99 (Improper Control of Resource Identifiers ('Resource Injection'))
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

fbdev: defio: fix the pagelist corruption

Easily hit the below list corruption:
==
list_add corruption. prev->next should be next (ffffffffc0ceb090), but
was ffffec604507edc8. (prev=ffffec604507edc8).
WARNING: CPU: 65 PID: 3959 at lib/list_debug.c:26
__list_add_valid+0x53/0x80
CPU: 65 PID: 3959 Comm: fbdev Tainted: G     U
RIP: 0010:__list_add_valid+0x53/0x80
Call Trace:
 <TASK>
 fb_deferred_io_mkwrite+0xea/0x150
 do_page_mkwrite+0x57/0xc0
 do_wp_page+0x278/0x2f0
 __handle_mm_fault+0xdc2/0x1590
 handle_mm_fault+0xdd/0x2c0
 do_user_addr_fault+0x1d3/0x650
 exc_page_fault+0x77/0x180
 ? asm_exc_page_fault+0x8/0x30
 asm_exc_page_fault+0x1e/0x30
RIP: 0033:0x7fd98fc8fad1
==

Figure out the race happens when one process is adding &page->lru into
the pagelist tail in fb_deferred_io_mkwrite(), another process is
re-initializing the same &page->lru in fb_deferred_io_fault(), which is
not protected by the lock.

This fix is to init all the page lists one time during initialization,
it not only fixes the list corruption, but also avoids INIT_LIST_HEAD()
redundantly.

V2: change "int i" to "unsigned int i" (Geert Uytterhoeven)


Affected upstream versions: 5.18
Fixed upstream versions: 0, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: e79b2b2aadeffe1db54a6b569b9b621575c3eb07
CVE-2022-49513: kernel: cpufreq: governor: Use kobject release() method to free dbs_data
Component: kernel
Severity: Moderate
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-02-26T00:00:00+00:00

A vulnerability was found in the Linux kernel's cpufreq subsystem. The `dbs_data` struct, which embeds a `kobject`, improperly attempts to free the struct using `kfree()` rather than through the proper `release()` method. This issue can lead to a use-after-free scenario, resulting in system instability, memory corruption, or potential arbitrary code execution.


Affected upstream versions: 4.6
Fixed upstream versions: 0, 5.15.91, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a1964688582d26af1328e19b658933659fb54337
CVE-2022-49515: kernel: ASoC: cs35l41: Fix an out-of-bounds access in otp_packed_element_t
Component: kernel
Severity: Moderate
CVSS v3: 7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-02-26T00:00:00+00:00

A vulnerability was found in the Linux kernel's CS35L41 driver. The constant `CS35L41_NUM_OTP_ELEM` is defined as 100 but is used by the arrays `otp_map_1` and `otp_map_2`, which are both expected to contain only 99 elements. This mismatch causes the code to access memory past the array boundaries when accessing an element at the 99th index, resulting in out-of-bounds access, which can lead to system instability, memory corruption, or potential code execution.


Affected upstream versions: 5.16
Fixed upstream versions: 0, 5.17.14, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: dbc35268e14d5d89c7a9db72009ad4dcd9ede646
CVE-2022-49519: kernel: Linux kernel (ath10k): Double free vulnerability during suspend/resume
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

A flaw was found in the Linux kernel (ath10k). This vulnerability allows a denial of service via a double free during suspend/resume operations.


Affected upstream versions: 3.11
Fixed upstream versions: 0, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 8aa3750986ffcf73e0692db3b40dd3a8e8c0c575
CVE-2022-49520: kernel: arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

arm64: compat: Do not treat syscall number as ESR_ELx for a bad syscall

If a compat process tries to execute an unknown system call above the
__ARM_NR_COMPAT_END number, the kernel sends a SIGILL signal to the
offending process. Information about the error is printed to dmesg in
compat_arm_syscall() -> arm64_notify_die() -> arm64_force_sig_fault() ->
arm64_show_signal().

arm64_show_signal() interprets a non-zero value for
current->thread.fault_code as an exception syndrome and displays the
message associated with the ESR_ELx.EC field (bits 31:26).
current->thread.fault_code is set in compat_arm_syscall() ->
arm64_notify_die() with the bad syscall number instead of a valid ESR_ELx
value. This means that the ESR_ELx.EC field has the value that the user set
for the syscall number and the kernel can end up printing bogus exception
messages*. For example, for the syscall number 0x68000000, which evaluates
to ESR_ELx.EC value of 0x1A (ESR_ELx_EC_FPAC) the kernel prints this error:

[   18.349161] syscall[300]: unhandled exception: ERET/ERETAA/ERETAB, ESR 0x68000000, Oops - bad compat syscall(2) in syscall[10000+50000]
[   18.350639] CPU: 2 PID: 300 Comm: syscall Not tainted 5.18.0-rc1 #79
[   18.351249] Hardware name: Pine64 RockPro64 v2.0 (DT)
[..]

which is misleading, as the bad compat syscall has nothing to do with
pointer authentication.

Stop arm64_show_signal() from printing exception syndrome information by
having compat_arm_syscall() set the ESR_ELx value to 0, as it has no
meaning for an invalid system call number. The example above now becomes:

[   19.935275] syscall[301]: unhandled exception: Oops - bad compat syscall(2) in syscall[10000+50000]
[   19.936124] CPU: 1 PID: 301 Comm: syscall Not tainted 5.18.0-rc1-00005-g7e08006d4102 #80
[   19.936894] Hardware name: Pine64 RockPro64 v2.0 (DT)
[..]

which although shows less information because the syscall number,
wrongfully advertised as the ESR value, is missing, it is better than
showing plainly wrong information. The syscall number can be easily
obtained with strace.

*A 32-bit value above or equal to 0x8000_0000 is interpreted as a negative
integer in compat_arm_syscal() and the condition scno < __ARM_NR_COMPAT_END
evaluates to true; the syscall will exit to userspace in this case with the
ENOSYS error code instead of arm64_notify_die() being called.


Affected upstream versions: 3.7
Fixed upstream versions: 0, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: efd183d988b416fcdf6f7c298a17ced4859ca77d
CVE-2022-49531: kernel: loop: implement ->free_disk
Component: kernel
Severity: Low
CWE: CWE-667 (Improper Locking)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

loop: implement ->free_disk

Ensure that the lo_device which is stored in the gendisk private
data is valid until the gendisk is freed.  Currently the loop driver
uses a lot of effort to make sure a device is not freed when it is
still in use, but to to fix a potential deadlock this will be relaxed
a bit soon.


Affected upstream versions: 2.6.22
Fixed upstream versions: 0, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: aadd1443aae7fe8956e3b11157827067f034406a
CVE-2022-49534: kernel: scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

scsi: lpfc: Protect memory leak for NPIV ports sending PLOGI_RJT

There is a potential memory leak in lpfc_ignore_els_cmpl() and
lpfc_els_rsp_reject() that was allocated from NPIV PLOGI_RJT
(lpfc_rcv_plogi()'s login_mbox).

Check if cmdiocb->context_un.mbox was allocated in lpfc_ignore_els_cmpl(),
and then free it back to phba->mbox_mem_pool along with mbox->ctx_buf for
service parameters.

For lpfc_els_rsp_reject() failure, free both the ctx_buf for service
parameters and the login_mbox.


Affected upstream versions: 2.6.23
Fixed upstream versions: 0, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: c00df0f34a6d5e14da379f96ea67e501ce67b002
CVE-2022-49536: kernel: scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock
Component: kernel
Severity: Moderate
CWE: CWE-667 (Improper Locking)
CVSS v3: 4.7 (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

scsi: lpfc: Fix SCSI I/O completion and abort handler deadlock

During stress I/O tests with 500+ vports, hard LOCKUP call traces are
observed.

CPU A:
 native_queued_spin_lock_slowpath+0x192
 _raw_spin_lock_irqsave+0x32
 lpfc_handle_fcp_err+0x4c6
 lpfc_fcp_io_cmd_wqe_cmpl+0x964
 lpfc_sli4_fp_handle_cqe+0x266
 __lpfc_sli4_process_cq+0x105
 __lpfc_sli4_hba_process_cq+0x3c
 lpfc_cq_poll_hdler+0x16
 irq_poll_softirq+0x76
 __softirqentry_text_start+0xe4
 irq_exit+0xf7
 do_IRQ+0x7f

CPU B:
 native_queued_spin_lock_slowpath+0x5b
 _raw_spin_lock+0x1c
 lpfc_abort_handler+0x13e
 scmd_eh_abort_handler+0x85
 process_one_work+0x1a7
 worker_thread+0x30
 kthread+0x112
 ret_from_fork+0x1f

Diagram of lockup:

CPUA                            CPUB
----                            ----
lpfc_cmd->buf_lock
                            phba->hbalock
                            lpfc_cmd->buf_lock
phba->hbalock

Fix by reordering the taking of the lpfc_cmd->buf_lock and phba->hbalock in
lpfc_abort_handler routine so that it tries to take the lpfc_cmd->buf_lock
first before phba->hbalock.


Affected upstream versions: 5.1
Fixed upstream versions: 0, 5.15.46, 5.17.14, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7625e81de2164a082810e1f27547d388406da610
CVE-2022-49537: kernel: scsi: lpfc: Fix call trace observed during I/O with CMF enabled
Component: kernel
Severity: Moderate
CWE: CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition'))
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

A vulnerability has been identified in the lpfc module within the Linux kernel. This flaw occurs because the driver attempts to access per-CPU data from a preemptible context using an incorrect function. This improper handling of critical data can lead to system instability and result in a denial-of-service condition.

Statement: This issue has been fixed in Red Hat Enterprise Linux 8.7 and 9.1 via RHSA-2022:7683 [1] and RHSA-2022:8267 [2], respectively.

[1]. https://access.redhat.com/errata/RHSA-2022:7683

[2]. https://access.redhat.com/errata/RHSA-2022:8267

Affected upstream versions: 5.15
Fixed upstream versions: 0, 5.15.46, 5.17.14, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ae373d66c427812754db5292eb1481b181daf9ce
CVE-2022-49538: kernel: ALSA: jack: Access input_dev under mutex
Component: kernel
Severity: Low
CWE: CWE-476 (NULL Pointer Dereference)
CVSS v3: 4.4 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

ALSA: jack: Access input_dev under mutex

It is possible when using ASoC that input_dev is unregistered while
calling snd_jack_report, which causes NULL pointer dereference.
In order to prevent this serialize access to input_dev using mutex lock.


Affected upstream versions: 3.13
Fixed upstream versions: 0, 4.14.283, 4.19.247, 4.9.318, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19, 5.4.198
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 74bab3bcf422593c582e47130aa8eb41ebb2dc09
CVE-2022-49539: kernel: rtw89: ser: fix CAM leaks occurring in L2 reset
Component: kernel
Severity: Moderate
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

rtw89: ser: fix CAM leaks occurring in L2 reset

The CAM, meaning address CAM and bssid CAM here, will get leaks during
SER (system error recover) L2 reset process and ieee80211_restart_hw()
which is called by L2 reset process eventually.

The normal flow would be like
-> add interface (acquire 1)
-> enter ips (release 1)
-> leave ips (acquire 1)
-> connection (occupy 1) <(A) 1 leak after L2 reset if non-sec connection>

The ieee80211_restart_hw() flow (under connection)
-> ieee80211 reconfig
-> add interface (acquire 1)
-> leave ips (acquire 1)
-> connection (occupy (A) + 2) <(B) 1 more leak>

Originally, CAM is released before HW restart only if connection is under
security. Now, release CAM whatever connection it is to fix leak in (A).
OTOH, check if CAM is already valid to avoid acquiring multiple times to
fix (B).

Besides, if AP mode, release address CAM of all stations before HW restart.


Affected upstream versions: 5.16
Fixed upstream versions: 0, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: f6aff772c9978844529618d86aafb53e5d3ae161
CVE-2022-49541: kernel: cifs: fix potential double free during failed mount
Component: kernel
Severity: Important
CWE: CWE-415 (Double Free)
CVSS v3: 7.8 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-02-26T00:00:00+00:00

A flaw was found in the Linux kernel's CIFS code in which a failed mount might lead to a double-free. An attacker with permissions to attempt to mount CIFS volumes could exploit this vulnerability to alter kernel memory, leading to a denial of service, altered system memory, or an escalation of privileges.

Statement: This flaw results from a missing check in the kernel's CIFS mounting code which can lead to the same pointer being freed twice when there is an error mounting the volume. An attacker could exploit this vulnerability to corrupt or alter system memory or execute arbitrary code with elevated privileges.
Note that this vulnerability was fixed in previous errata:
RHSA-2022:5819 for Red Hat Enterprise Linux 8.6 EUS
RHSA-2022:7683 for Red Hat Enterprise Linux 8.7-8.10
RHSA-2023:2458 for Red Hat Enterprise Linux 9.2 and later.

Affected upstream versions: 5.11
Fixed upstream versions: 0, 5.15.46, 5.17.14, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: ce0008a0e410cdd95f0d8cd81b2902ec10a660c4
CVE-2022-49545: kernel: ALSA: usb-audio: Cancel pending work at closing a MIDI substream
Component: kernel
Severity: Moderate
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

ALSA: usb-audio: Cancel pending work at closing a MIDI substream

At closing a USB MIDI output substream, there might be still a pending
work, which would eventually access the rawmidi runtime object that is
being released.  For fixing the race, make sure to cancel the pending
work at closing.


Affected upstream versions: 2.6.12
Fixed upstream versions: 0, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 40bdb5ec957aca5c5c1924602bef6b0ab18e22d3
CVE-2022-49548: kernel: bpf: Fix potential array overflow in bpf_trampoline_get_progs()
Component: kernel
Severity: Moderate
CWE: CWE-129 (Improper Validation of Array Index)
CVSS v3: 6.7 (CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

bpf: Fix potential array overflow in bpf_trampoline_get_progs()

The cnt value in the 'cnt >= BPF_MAX_TRAMP_PROGS' check does not
include BPF_TRAMP_MODIFY_RETURN bpf programs, so the number of
the attached BPF_TRAMP_MODIFY_RETURN bpf programs in a trampoline
can exceed BPF_MAX_TRAMP_PROGS.

When this happens, the assignment '*progs++ = aux->prog' in
bpf_trampoline_get_progs() will cause progs array overflow as the
progs field in the bpf_tramp_progs struct can only hold at most
BPF_MAX_TRAMP_PROGS bpf programs.

Statement: The default Red Hat Enterprise Linux kernel prevents unprivileged users from being able to use eBPF by the kernel.unprivileged_bpf_disabled sysctl. This would require a privileged user with CAP_SYS_ADMIN or root to be able to abuse this flaw reducing its attack space.

For the Red Hat Enterprise Linux 9 to confirm the current state, inspect the sysctl with the command:

    cat /proc/sys/kernel/unprivileged_bpf_disabled

The setting of 1 would mean that unprivileged users can not use eBPF, mitigating the flaw.

Affected upstream versions: 5.7
Fixed upstream versions: 0, 5.10.120, 5.15.45, 5.17.13, 5.18.2, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: 7f845de2863334bed4f362e95853f5e7bc323737
CVE-2022-49549: kernel: x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails
Component: kernel
Severity: Low
CWE: CWE-401 (Missing Release of Memory after Effective Lifetime)
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

x86/MCE/AMD: Fix memory leak when threshold_create_bank() fails

In mce_threshold_create_device(), if threshold_create_bank() fails, the
previously allocated threshold banks array @bp will be leaked because
the call to mce_threshold_remove_device() will not free it.

This happens because mce_threshold_remove_device() fetches the pointer
through the threshold_banks per-CPU variable but bp is written there
only after the bank creation is successful, and not before, when
threshold_create_bank() fails.

Add a helper which unwinds all the bank creation work previously done
and pass into it the previously allocated threshold banks array for
freeing.

  [ bp: Massage. ]


Affected upstream versions: 5.8
Fixed upstream versions: 0, 5.10.121, 5.15.46, 5.17.14, 5.18.3, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: b4acb8e7f1594607bc9017ef0aacb40b24a003d6
CVE-2022-49552: kernel: bpf: Fix combination of jit blinding and pointers to bpf subprogs.
Component: kernel
Severity: Low
CVSS v3: 5.5 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H)
Public date: 2025-02-26T00:00:00+00:00

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

bpf: Fix combination of jit blinding and pointers to bpf subprogs.

The combination of jit blinding and pointers to bpf subprogs causes:
[   36.989548] BUG: unable to handle page fault for address: 0000000100000001
[   36.990342] #PF: supervisor instruction fetch in kernel mode
[   36.990968] #PF: error_code(0x0010) - not-present page
[   36.994859] RIP: 0010:0x100000001
[   36.995209] Code: Unable to access opcode bytes at RIP 0xffffffd7.
[   37.004091] Call Trace:
[   37.004351]  <TASK>
[   37.004576]  ? bpf_loop+0x4d/0x70
[   37.004932]  ? bpf_prog_3899083f75e4c5de_F+0xe3/0x13b

The jit blinding logic didn't recognize that ld_imm64 with an address
of bpf subprogram is a special instruction and proceeded to randomize it.
By itself it wouldn't have been an issue, but jit_subprogs() logic
relies on two step process to JIT all subprogs and then JIT them
again when addresses of all subprogs are known.
Blinding process in the first JIT phase caused second JIT to miss
adjustment of special ld_imm64.

Fix this issue by ignoring special ld_imm64 instructions that don't have
user controlled constants and shouldn't be blinded.


Affected upstream versions: 5.13
Fixed upstream versions: 0, 5.17.13, 5.18.2, 5.19
Upstream repository: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
Upstream fix commit: a029b02b47dd5bb87a21550d9d9a80cb4dd3f714