deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50718
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: fix pci device refcount leak

As comment of pci_get_domain_bus_and_slot() says, it returns
a pci device with refcount increment, when finish using it,
the caller must decrement the reference count by calling
pci_dev_put().

So before returning from amdgpu_device_resume|suspend_display_audio(),
pci_dev_put() is called to avoid refcount leak.
References: https://git.kernel.org/stable/c/02105f0b3021ee5853b2fa50853c42f35fc01cfd; https://git.kernel.org/stable/c/3725a8f26bdbc38dfdf545836117f1e069277c91; https://git.kernel.org/stable/c/b85e285e3d6352b02947fc1b72303673dfacb0aa
CVE: CVE-2022-50719
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ALSA: line6: fix stack overflow in line6_midi_transmit

Correctly calculate available space including the size of the chunk
buffer. This fixes a buffer overflow when multiple MIDI sysex
messages are sent to a PODxt device.
References: https://git.kernel.org/stable/c/0c76087449ee4ed45a88b10017d02c6694caedb1; https://git.kernel.org/stable/c/0c9118e381ff538874e00fd4e66a768273c150fb; https://git.kernel.org/stable/c/25e8c6ecb46843a955f254b8f0d77894e4a53dc4
CVE: CVE-2022-50720
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

x86/apic: Don't disable x2APIC if locked

The APIC supports two modes, legacy APIC (or xAPIC), and Extended APIC
(or x2APIC).  X2APIC mode is mostly compatible with legacy APIC, but
it disables the memory-mapped APIC interface in favor of one that uses
MSRs.  The APIC mode is controlled by the EXT bit in the APIC MSR.

The MMIO/xAPIC interface has some problems, most notably the APIC LEAK
[1].  This bug allows an attacker to use the APIC MMIO interface to
extract data from the SGX enclave.

Introduce support for a new feature that will allow the BIOS to lock
the APIC in x2APIC mode.  If the APIC is locked in x2APIC mode and the
kernel tries to disable the APIC or revert to legacy APIC mode a GP
fault will occur.

Introduce support for a new MSR (IA32_XAPIC_DISABLE_STATUS) and handle
the new locked mode when the LEGACY_XAPIC_DISABLED bit is set by
preventing the kernel from trying to disable the x2APIC.

On platforms with the IA32_XAPIC_DISABLE_STATUS MSR, if SGX or TDX are
enabled the LEGACY_XAPIC_DISABLED will be set by the BIOS.  If
legacy APIC is required, then it SGX and TDX need to be disabled in the
BIOS.

[1]: https://aepicleak.com/aepicleak.pdf
References: https://git.kernel.org/stable/c/05785ba834f23272f9d23427ae4a80ac505a5296; https://git.kernel.org/stable/c/b8d1d163604bd1e600b062fb00de5dc42baa355f; https://git.kernel.org/stable/c/dd1241e00addbf0b95f6cd6ce[PII_REDACTED]0657e
CVE: CVE-2022-50721
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: qcom-adm: fix wrong calling convention for prep_slave_sg

The calling convention for pre_slave_sg is to return NULL on error and
provide an error log to the system. Qcom-adm instead provide error
pointer when an error occur. This indirectly cause kernel panic for
example for the nandc driver that checks only if the pointer returned by
device_prep_slave_sg is not NULL. Returning an error pointer makes nandc
think the device_prep_slave_sg function correctly completed and makes
the kernel panics later in the code.

While nandc is the one that makes the kernel crash, it was pointed out
that the real problem is qcom-adm not following calling convention for
that function.

To fix this, drop returning error pointer and return NULL with an error
log.
References: https://git.kernel.org/stable/c/5653bd0200944e5803fa8e32dc36aa49931312f9; https://git.kernel.org/stable/c/9a041174c58a226e713f6cebd41eccec7a5cfa72; https://git.kernel.org/stable/c/b9d2140c3badf4107973ad77c5a0ec3075705c85
CVE: CVE-2022-50722
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

media: ipu3-imgu: Fix NULL pointer dereference in active selection access

What the IMGU driver did was that it first acquired the pointers to active
and try V4L2 subdev state, and only then figured out which one to use.

The problem with that approach and a later patch (see Fixes: tag) is that
as sd_state argument to v4l2_subdev_get_try_crop() et al is NULL, there is
now an attempt to dereference that.

Fix this.

Also rewrap lines a little.
References: https://git.kernel.org/stable/c/5265cc1202a31f7097691c3483a0d60d624424a5; https://git.kernel.org/stable/c/740717b756c17190dc2d2ad4c6de1e63f214e0c9; https://git.kernel.org/stable/c/b9eb3ab6f30bf32f7326909f17949ccb11bab514
CVE: CVE-2022-50723
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

bnxt_en: fix memory leak in bnxt_nvm_test()

Free the kzalloc'ed buffer before returning in the success path.
References: https://git.kernel.org/stable/c/ba077d683d45190afc993c1ce45bcdbfda741a40; https://git.kernel.org/stable/c/be083d97031712a2e16fd915ddb8fe1a6cb1fbc5
CVE: CVE-2022-50724
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

regulator: core: fix resource leak in regulator_register()

I got some resource leak reports while doing fault injection test:

  OF: ERROR: memory leak, expected refcount 1 instead of 100,
  of_node_get()/of_node_put() unbalanced - destroy cset entry:
  attach overlay node /i2c/pmic@64/regulators/buck1

unreferenced object 0xffff88810deea000 (size 512):
  comm "490-i2c-rt5190a", pid 253, jiffies[PII_REDACTED] (age 5061.046s)
  hex dump (first 32 bytes):
    00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00  .....N..........
    ff ff ff ff ff ff ff ff a0 1e 00 a1 ff ff ff ff  ................
  backtrace:
    [<00000000d78541e2>] kmalloc_trace+0x21/0x110
    [<00000000b343d153>] device_private_init+0x32/0xd0
    [<00000000be1f0c70>] device_add+0xb2d/0x1030
    [<00000000e3e6344d>] regulator_register+0xaf2/0x12a0
    [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0
    [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]

unreferenced object 0xffff88810b617b80 (size 32):
  comm "490-i2c-rt5190a", pid 253, jiffies[PII_REDACTED] (age 5060.983s)
  hex dump (first 32 bytes):
    72 65 67 75 6c 61 74 6f 72 2e 32 38 36 38 2d 53  regulator.2868-S
    55 50 50 4c 59 00 ff ff 29 00 00 00 2b 00 00 00  UPPLY...)...+...
  backtrace:
    [<000000009da9280d>] __kmalloc_node_track_caller+0x44/0x1b0
    [<[PII_REDACTED]c6a4e5>] kstrdup+0x3a/0x70
    [<[PII_REDACTED]0efb69>] create_regulator+0xc0/0x4e0
    [<[PII_REDACTED]ed203a>] regulator_resolve_supply+0x2d4/0x440
    [<[PII_REDACTED]>] regulator_register+0x10b3/0x12a0
    [<00000000e2f5e754>] devm_regulator_register+0x57/0xb0
    [<000000008b898197>] rt5190a_probe+0x52a/0x861 [rt5190a_regulator]

After calling regulator_resolve_supply(), the 'rdev->supply' is set
by set_supply(), after this set, in the error path, the resources
need be released, so call regulator_put() to avoid the leaks.
References: https://git.kernel.org/stable/c/35593d60b[PII_REDACTED]c43add7646d4069671aa9; https://git.kernel.org/stable/c/6a03c31d08f95dca9633a552de167b9e625833a8; https://git.kernel.org/stable/c/90b713aadc1240bf2dd03d610d6c1d016a9123a2
CVE: CVE-2022-50725
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

media: vidtv: Fix use-after-free in vidtv_bridge_dvb_init()

KASAN reports a use-after-free:
BUG: KASAN: use-after-free in dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]
Call Trace:
 ...
 dvb_dmxdev_release+0x4d5/0x5d0 [dvb_core]
 vidtv_bridge_probe+0x7bf/0xa40 [dvb_vidtv_bridge]
 platform_probe+0xb6/0x170
 ...
Allocated by task 1238:
 ...
 dvb_register_device+0x1a7/0xa70 [dvb_core]
 dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]
 vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]
 ...
Freed by task 1238:
 dvb_register_device+0x6d2/0xa70 [dvb_core]
 dvb_dmxdev_init+0x2af/0x4a0 [dvb_core]
 vidtv_bridge_probe+0x766/0xa40 [dvb_vidtv_bridge]
 ...

It is because the error handling in vidtv_bridge_dvb_init() is wrong.

First, vidtv_bridge_dmx(dev)_init() will clean themselves when fail, but
goto fail_dmx(_dev): calls release functions again, which causes
use-after-free.

Also, in fail_fe, fail_tuner_probe and fail_demod_probe, j = i will cause
out-of-bound when i finished its loop (i == NUM_FE). And the loop
releasing is wrong, although now NUM_FE is 1 so it won't cause problem.

Fix this by correctly releasing everything.
References: https://git.kernel.org/stable/c/0369af6fe33d4053899b121b32e91f870b2cf0ae; https://git.kernel.org/stable/c/06398ce69571a43a8a0dd0f1bfe35d221f726a6a; https://git.kernel.org/stable/c/8a204a0b4a0d[PII_REDACTED]2c515759ea2b126c1
CVE: CVE-2022-50727
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: efct: Fix possible memleak in efct_device_init()

In efct_device_init(), when efct_scsi_reg_fc_transport() fails,
efct_scsi_tgt_driver_exit() is not called to release memory for
efct_scsi_tgt_driver_init() and causes memleak:

unreferenced object 0xffff8881020ce000 (size 2048):
  comm "modprobe", pid 465, jiffies[PII_REDACTED] (age 55.872s)
  backtrace:
    [<[PII_REDACTED]a1ef1b>] kmalloc_trace+0x27/0x110
    [<000000004c3ed51c>] target_register_template+0x4fd/0x7b0 [target_core_mod]
    [<00000000f3393296>] efct_scsi_tgt_driver_init+0x18/0x50 [efct]
    [<[PII_REDACTED]5de533>] 0xffffffffc0d90011
    [<00000000d608f646>] do_one_initcall+0xd0/0x4e0
    [<[PII_REDACTED]828cf1>] do_init_module+0x1cc/0x6a0
    ...
References: https://git.kernel.org/stable/c/038359eeccffaf0de4c1c9c51ee19cc5649619a1; https://git.kernel.org/stable/c/0c6e6bb30229b1297ac0fd7ede2941d2322fc736; https://git.kernel.org/stable/c/bb0cd225dd37df1f4a22e36dad59ff33178ecdfc
CVE: CVE-2022-50728
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

s390/lcs: Fix return type of lcs_start_xmit()

With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:

  drivers/s390/net/lcs.c:2090:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
          .ndo_start_xmit         = lcs_start_xmit,
                                    ^~~~~~~~~~~~~~
  drivers/s390/net/lcs.c:2097:21: error: incompatible function pointer types initializing 'netdev_tx_t (*)(struct sk_buff *, struct net_device *)' (aka 'enum netdev_tx (*)(struct sk_buff *, struct net_device *)') with an expression of type 'int (struct sk_buff *, struct net_device *)' [-Werror,-Wincompatible-function-pointer-types-strict]
          .ndo_start_xmit         = lcs_start_xmit,
                                    ^~~~~~~~~~~~~~

->ndo_start_xmit() in 'struct net_device_ops' expects a return type of
'netdev_tx_t', not 'int'. Adjust the return type of lcs_start_xmit() to
match the prototype's to resolve the warning and potential CFI failure,
should s390 select ARCH_SUPPORTS_CFI_CLANG in the future.
References: https://git.kernel.org/stable/c/20022d551f2064a194d8e0acb6cd7a85094a17b2; https://git.kernel.org/stable/c/5ad774fb823c24bbeb21a15a67103ea7a6f5b928; https://git.kernel.org/stable/c/[PII_REDACTED]4f81a77b6db24b86581320ae4d17af
CVE: CVE-2022-50729
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ksmbd: Fix resource leak in ksmbd_session_rpc_open()

When ksmbd_rpc_open() fails then it must call ksmbd_rpc_id_free() to
undo the result of ksmbd_ipc_id_alloc().
References: https://git.kernel.org/stable/c/31c1b5d3000cdff70b98d5af045271e09079bec1; https://git.kernel.org/stable/c/9cb49b95c05df09b369d1ec1f378b5c92109433c; https://git.kernel.org/stable/c/bc044414fa0326a4e5c3c509c00b1fcaf621b5f4
CVE: CVE-2022-50730
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

ext4: silence the warning when evicting inode with dioread_nolock

When evicting an inode with default dioread_nolock, it could be raced by
the unwritten extents converting kworker after writeback some new
allocated dirty blocks. It convert unwritten extents to written, the
extents could be merged to upper level and free extent blocks, so it
could mark the inode dirty again even this inode has been marked
I_FREEING. But the inode->i_io_list check and warning in
ext4_evict_inode() missing this corner case. Fortunately,
ext4_evict_inode() will wait all extents converting finished before this
check, so it will not lead to inode use-after-free problem, every thing
is OK besides this warning. The WARN_ON_ONCE was originally designed
for finding inode use-after-free issues in advance, but if we add
current dioread_nolock case in, it will become not quite useful, so fix
this warning by just remove this check.

 ======
 WARNING: CPU: 7 PID: 1092 at fs/ext4/inode.c:227
 ext4_evict_inode+0x875/0xc60
 ...
 RIP: 0010:ext4_evict_inode+0x875/0xc60
 ...
 Call Trace:
  <TASK>
  evict+0x11c/0x2b0
  iput+0x236/0x3a0
  do_unlinkat+0x1b4/0x490
  __x64_sys_unlinkat+0x4c/0xb0
  do_syscall_64+0x3b/0x90
  entry_SYSCALL_64_after_hwframe+0x46/0xb0
 RIP: 0033:0x7fa933c1115b
 ======

rm                          kworker
                            ext4_end_io_end()
vfs_unlink()
 ext4_unlink()
                             ext4_convert_unwritten_io_end_vec()
                              ext4_convert_unwritten_extents()
                               ext4_map_blocks()
                                ext4_ext_map_blocks()
                                 ext4_ext_try_to_merge_up()
                                  __mark_inode_dirty()
                                   check !I_FREEING
                                   locked_inode_to_wb_and_lock_list()
 iput()
  iput_final()
   evict()
    ext4_evict_inode()
     truncate_inode_pages_final() //wait release io_end
                                    inode_io_list_move_locked()
                             ext4_release_io_end()
     trigger WARN_ON_ONCE()
References: https://git.kernel.org/stable/c/0d041b7251c13679a0f6c7926751ce1d8a7237c1; https://git.kernel.org/stable/c/3b893cc9a8d8b4e486a6639f5e107b56b7197d2e; https://git.kernel.org/stable/c/b085fb43feede48ebf80ab7e2dd150c8d9902932
CVE: CVE-2022-50731
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

crypto: akcipher - default implementation for setting a private key

Changes from v1:
  * removed the default implementation from set_pub_key: it is assumed that
    an implementation must always have this callback defined as there are
    no use case for an algorithm, which doesn't need a public key

Many akcipher implementations (like ECDSA) support only signature
verifications, so they don't have all callbacks defined.

Commit 78a0324f4a53 ("crypto: akcipher - default implementations for
request callbacks") introduced default callbacks for sign/verify
operations, which just return an error code.

However, these are not enough, because before calling sign the caller would
likely call set_priv_key first on the instantiated transform (as the
in-kernel testmgr does). This function does not have a default stub, so the
kernel crashes, when trying to set a private key on an akcipher, which
doesn't support signature generation.

I've noticed this, when trying to add a KAT vector for ECDSA signature to
the testmgr.

With this patch the testmgr returns an error in dmesg (as it should)
instead of crashing the kernel NULL ptr dereference.
References: https://git.kernel.org/stable/c/779a9930f3e152c82699feb389a0e6d6644e747e; https://git.kernel.org/stable/c/85bc736a18b872f54912e8bb70682d11770aece0; https://git.kernel.org/stable/c/95c4e20adc3ea00d1594a2a05d9b187ed12ffa8e
CVE: CVE-2022-50732
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: rtl8192u: Fix use after free in ieee80211_rx()

We cannot dereference the "skb" pointer after calling
ieee80211_monitor_rx(), because it is a use after free.
References: https://git.kernel.org/stable/c/288ada16a93aab5aa2ebea8190aafdb35b716854; https://git.kernel.org/stable/c/73df1172bbcc8d45cd28e3b1a9ca2edb2f9f7ce6; https://git.kernel.org/stable/c/9c03db0ec84b7964a11b20706665c99a5fead332
CVE: CVE-2022-50733
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: idmouse: fix an uninit-value in idmouse_open

In idmouse_create_image, if any ftip_command fails, it will
go to the reset label. However, this leads to the data in
bulk_in_buffer[HEADER..IMGSIZE] uninitialized. And the check
for valid image incurs an uninitialized dereference.

Fix this by moving the check before reset label since this
check only be valid if the data after bulk_in_buffer[HEADER]
has concrete data.

Note that this is found by KMSAN, so only kernel compilation
is tested.
References: https://git.kernel.org/stable/c/1eae30c0113dde[PII_REDACTED]584d62415011a035; https://git.kernel.org/stable/c/20b8c456df584ebb2387dc23d40ebe4ff334417c; https://git.kernel.org/stable/c/6163a5ae097bc78fa26c243fb384537e25610fd7
CVE: CVE-2022-50734
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

nvmem: core: Fix memleak in nvmem_register()

dev_set_name will alloc memory for nvmem->dev.kobj.name in
nvmem_register, when nvmem_validate_keepouts failed, nvmem's
memory will be freed and return, but nobody will free memory
for nvmem->dev.kobj.name, there will be memleak, so moving
nvmem_validate_keepouts() after device_register() and let
the device core deal with cleaning name in error cases.
References: https://git.kernel.org/stable/c/2bd2774df0ce37920b23819a860a66fdbdd90823; https://git.kernel.org/stable/c/9391cc3a787a58aa224a6440d7f244d780ba2896; https://git.kernel.org/stable/c/b6054b9b239a493672f853b034570cca93ba7a88
CVE: CVE-2022-50735
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mt76: do not run mt76u_status_worker if the device is not running

Fix the following NULL pointer dereference avoiding to run
mt76u_status_worker thread if the device is not running yet.

KASAN: null-ptr-deref in range
[0x[PII_REDACTED]000000-0x[PII_REDACTED]000007]
CPU: 0 PID: 98 Comm: kworker/u2:2 Not tainted 5.14.0+ #78 Hardware
name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.12.1-0-ga5cab58e9a3f-prebuilt.qemu.org 04/01/2014
Workqueue: mt76 mt76u_tx_status_data
RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0
Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f>
b6
04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7
RSP: 0018:ffffc900005af988 EFLAGS: 00010246
RAX: dffffc[PII_REDACTED] RBX: ffffc900005afae8 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: ffffffff832fc661 RDI: ffffc900005afc2a
RBP: ffffc900005afae0 R08: [PII_REDACTED] R09: fffff520000b5f3c
R10: [PII_REDACTED] R11: fffff520000b5f3b R12: ffff88810b6132d8
R13:[PII_REDACTED]00ffff R14: [PII_REDACTED] R15: ffffc900005afc28
FS:  [PII_REDACTED](0000) GS:ffff88811aa00000(0000)
knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007fa0eda6a000 CR3:[PII_REDACTED]f17000 CR4:[PII_REDACTED]750ef0
PKRU: 55555554
Call Trace:
 mt76x02_send_tx_status+0x1d2/0xeb0
 mt76x02_tx_status_data+0x8e/0xd0
 mt76u_tx_status_data+0xe1/0x240
 process_one_work+0x92b/0x1460
 worker_thread+0x95/0xe00
 kthread+0x3a1/0x480
 ret_from_fork+0x1f/0x30
Modules linked in:
--[ end trace 8df5d20fc5040f65 ]--
RIP: 0010:mt76x02_mac_fill_tx_status.isra.0+0x82c/0x9e0
Code: c5 48 b8 00 00 00 00 00 fc ff df 80 3c 02 00 0f 85 94 01 00 00
48 b8 00 00 00 00 00 fc ff df 4d 8b 34 24 4c 89 f2 48 c1 ea 03 <0f>
b6
04 02 84 c0 74 08 3c 03 0f 8e 89 01 00 00 41 8b 16 41 0f b7
RSP: 0018:ffffc900005af988 EFLAGS: 00010246
RAX: dffffc[PII_REDACTED] RBX: ffffc900005afae8 RCX: [PII_REDACTED]
RDX: [PII_REDACTED] RSI: ffffffff832fc661 RDI: ffffc900005afc2a
RBP: ffffc900005afae0 R08: [PII_REDACTED] R09: fffff520000b5f3c
R10: [PII_REDACTED] R11: fffff520000b5f3b R12: ffff88810b6132d8
R13:[PII_REDACTED]00ffff R14: [PII_REDACTED] R15: ffffc900005afc28
FS:  [PII_REDACTED](0000) GS:ffff88811aa00000(0000)
knlGS:[PII_REDACTED]
CS:  0010 DS: 0000 ES: 0000 CR0: [PII_REDACTED]
CR2: 00007fa0eda6a000 CR3:[PII_REDACTED]f17000 CR4:[PII_REDACTED]750ef0
PKRU: 55555554

Moreover move stat_work schedule out of the for loop.
References: https://git.kernel.org/stable/c/58fdd84a89b121b761dbfb8a196356e007376ca4; https://git.kernel.org/stable/c/69346de0eb956fb92949b9473de4647d9c34a54f; https://git.kernel.org/stable/c/bd5dac7ced5a7c9faa4dc468ac9560c3256df845
CVE: CVE-2022-50736
Published: 2025-12-24
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/siw: Fix immediate work request flush to completion queue

Correctly set send queue element opcode during immediate work request
flushing in post sendqueue operation, if the QP is in ERROR state.
An undefined ocode value results in out-of-bounds access to an array
for mapping the opcode between siw internal and RDMA core representation
in work completion generation. It resulted in a KASAN BUG report
of type 'global-out-of-bounds' during NFSoRDMA testing.

This patch further fixes a potential case of a malicious user which may
write undefined values for completion queue elements status or opcode,
if the CQ is memory mapped to user land. It avoids the same out-of-bounds
access to arrays for status and opcode mapping as described above.
References: https://git.kernel.org/stable/c/355d2eca68c10d713a42f68e62044b3d1c300471; https://git.kernel.org/stable/c/6af043089d3f1210776d19b6fdabea610d4c7699; https://git.kernel.org/stable/c/75af03fdf35acf15a3977f7115f6b8d10dff4bc7