deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-50529
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

test_firmware: fix memory leak in test_firmware_init()

When misc_register() failed in test_firmware_init(), the memory pointed
by test_fw_config->name is not released. The memory leak information is
as follows:
unreferenced object 0xffff88810a34cb00 (size 32):
  comm "insmod", pid 7952, jiffies[PII_REDACTED] (age 49.060s)
  hex dump (first 32 bytes):
    74 65 73 74 2d 66 69 72 6d 77 61 72 65 2e 62 69  test-firmware.bi
    6e 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  n...............
  backtrace:
    [<ffffffff81b21fcb>] __kmalloc_node_track_caller+0x4b/0xc0
    [<ffffffff81affb96>] kstrndup+0x46/0xc0
    [<ffffffffa0403a49>] __test_firmware_config_init+0x29/0x380 [test_firmware]
    [<ffffffffa040f068>] 0xffffffffa040f068
    [<ffffffff81002c41>] do_one_initcall+0x141/0x780
    [<ffffffff816a72c3>] do_init_module+0x1c3/0x630
    [<ffffffff816adb9e>] load_module+0x623e/0x76a0
    [<ffffffff816af471>] __do_sys_finit_module+0x181/0x240
    [<ffffffff89978f99>] do_syscall_64+0x39/0xb0
    [<ffffffff89a0008b>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/04dd47a2e169f2d4489636afa07ff0469aab49ab; https://git.kernel.org/stable/c/0b5a89e8bce1ea43687742b4de8e216189ff94ac; https://git.kernel.org/stable/c/357379d504c0c8b0834e206ad8c49e4b3c98ed4d
CVE: CVE-2022-50530
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

blk-mq: fix null pointer dereference in blk_mq_clear_rq_mapping()

Our syzkaller report a null pointer dereference, root cause is
following:

__blk_mq_alloc_map_and_rqs
 set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs
  blk_mq_alloc_map_and_rqs
   blk_mq_alloc_rqs
    // failed due to oom
    alloc_pages_node
    // set->tags[hctx_idx] is still NULL
    blk_mq_free_rqs
     drv_tags = set->tags[hctx_idx];
     // null pointer dereference is triggered
     blk_mq_clear_rq_mapping(drv_tags, ...)

This is because commit 63064be150e4 ("blk-mq:
Add blk_mq_alloc_map_and_rqs()") merged the two steps:

1) set->tags[hctx_idx] = blk_mq_alloc_rq_map()
2) blk_mq_alloc_rqs(..., set->tags[hctx_idx])

into one step:

set->tags[hctx_idx] = blk_mq_alloc_map_and_rqs()

Since tags is not initialized yet in this case, fix the problem by
checking if tags is NULL pointer in blk_mq_clear_rq_mapping().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/6a440e6d04431e774dc084abe88c106e2a474c1a; https://git.kernel.org/stable/c/76dd298094f484c6250ebd076fa53287477b2328
CVE: CVE-2022-50531
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

tipc: fix an information leak in tipc_topsrv_kern_subscr

Use a 8-byte write to initialize sub.usr_handle in
tipc_topsrv_kern_subscr(), otherwise four bytes remain uninitialized
when issuing setsockopt(..., SOL_TIPC, ...).
This resulted in an infoleak reported by KMSAN when the packet was
received:

  =====================================================
  BUG: KMSAN: kernel-infoleak in copyout+0xbc/0x100 lib/iov_iter.c:169
   instrument_copy_to_user ./include/linux/instrumented.h:121
   copyout+0xbc/0x100 lib/iov_iter.c:169
   _copy_to_iter+0x5c0/0x20a0 lib/iov_iter.c:527
   copy_to_iter ./include/linux/uio.h:176
   simple_copy_to_iter+0x64/0xa0 net/core/datagram.c:513
   __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:419
   skb_copy_datagram_iter+0x58/0x200 net/core/datagram.c:527
   skb_copy_datagram_msg ./include/linux/skbuff.h:3903
   packet_recvmsg+0x521/0x1e70 net/packet/af_packet.c:3469
   ____sys_recvmsg+0x2c4/0x810 net/socket.c:?
   ___sys_recvmsg+0x217/0x840 net/socket.c:2743
   __sys_recvmsg net/socket.c:2773
   __do_sys_recvmsg net/socket.c:2783
   __se_sys_recvmsg net/socket.c:2780
   __x64_sys_recvmsg+0x364/0x540 net/socket.c:2780
   do_syscall_x64 arch/x86/entry/common.c:50
   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
   entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120

  ...

  Uninit was stored to memory at:
   tipc_sub_subscribe+0x42d/0xb50 net/tipc/subscr.c:156
   tipc_conn_rcv_sub+0x246/0x620 net/tipc/topsrv.c:375
   tipc_topsrv_kern_subscr+0x2e8/0x400 net/tipc/topsrv.c:579
   tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190
   tipc_sk_join+0x2a8/0x770 net/tipc/socket.c:3084
   tipc_setsockopt+0xae5/0xe40 net/tipc/socket.c:3201
   __sys_setsockopt+0x87f/0xdc0 net/socket.c:2252
   __do_sys_setsockopt net/socket.c:2263
   __se_sys_setsockopt net/socket.c:2260
   __x64_sys_setsockopt+0xe0/0x160 net/socket.c:2260
   do_syscall_x64 arch/x86/entry/common.c:50
   do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
   entry_SYSCALL_64_after_hwframe+0x63/0xcd arch/x86/entry/entry_64.S:120

  Local variable sub created at:
   tipc_topsrv_kern_subscr+0x57/0x400 net/tipc/topsrv.c:562
   tipc_group_create+0x4e7/0x7d0 net/tipc/group.c:190

  Bytes 84-87 of 88 are uninitialized
  Memory access of size 88 starts at ffff88801ed57cd0
  Data copied to user address [PII_REDACTED]
  ...
  =====================================================
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/3d1b83ff7b6575a4e41283203e6b2e25ea700cd7; https://git.kernel.org/stable/c/567f8de358b61015dcfb8878a1f06c5369a45f54; https://git.kernel.org/stable/c/777ecaabd614d47c482a5c9031579e66da13989a
CVE: CVE-2022-50532
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

scsi: mpt3sas: Fix possible resource leaks in mpt3sas_transport_port_add()

In mpt3sas_transport_port_add(), if sas_rphy_add() returns error,
sas_rphy_free() needs be called to free the resource allocated in
sas_end_device_alloc(). Otherwise a kernel crash will happen:

Unable to handle kernel NULL pointer dereference at virtual address [PII_REDACTED]
CPU: 45 PID: 37020 Comm: bash Kdump: loaded Tainted: G        W          6.1.0-rc1+ #189
pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : device_del+0x54/0x3d0
lr : device_del+0x37c/0x3d0
Call trace:
 device_del+0x54/0x3d0
 attribute_container_class_device_del+0x28/0x38
 transport_remove_classdev+0x6c/0x80
 attribute_container_device_trigger+0x108/0x110
 transport_remove_device+0x28/0x38
 sas_rphy_remove+0x50/0x78 [scsi_transport_sas]
 sas_port_delete+0x30/0x148 [scsi_transport_sas]
 do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
 device_for_each_child+0x68/0xb0
 sas_remove_children+0x30/0x50 [scsi_transport_sas]
 sas_rphy_remove+0x38/0x78 [scsi_transport_sas]
 sas_port_delete+0x30/0x148 [scsi_transport_sas]
 do_sas_phy_delete+0x78/0x80 [scsi_transport_sas]
 device_for_each_child+0x68/0xb0
 sas_remove_children+0x30/0x50 [scsi_transport_sas]
 sas_remove_host+0x20/0x38 [scsi_transport_sas]
 scsih_remove+0xd8/0x420 [mpt3sas]

Because transport_add_device() is not called when sas_rphy_add() fails, the
device is not added. When sas_rphy_remove() is subsequently called to
remove the device in the remove() path, a NULL pointer dereference happens.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/6a92129c8f999ff5b122c100ce7f625eb3e98c4b; https://git.kernel.org/stable/c/6f6768e2fc8638fabdd8802c2ef693d7aef01db1; https://git.kernel.org/stable/c/78316e9dfc24906dd474630928ed1d3c562b568e
CVE: CVE-2022-50533
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

wifi: mac80211: mlme: fix null-ptr deref on failed assoc

If association to an AP without a link 0 fails, then we crash in
tracing because it assumes that either ap_mld_addr or link 0 BSS
is valid, since we clear sdata->vif.valid_links and then don't
add the ap_mld_addr to the struct.

Since we clear also sdata->vif.cfg.ap_addr, keep a local copy of
it and assign it earlier, before clearing valid_links, to fix
this.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/78a6a43aaf87180ec7425a2a90468e1b4d09a1ec; https://git.kernel.org/stable/c/bb7743955a929e44b308cc3f63f8cc03873c1bee; https://git.kernel.org/stable/c/c695dfba8dfb82dc7ace4f22be088916cbf621ca
CVE: CVE-2022-50534
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

dm thin: Use last transaction's pmd->root when commit failed

Recently we found a softlock up problem in dm thin pool btree lookup
code due to corrupted metadata:

 Kernel panic - not syncing: softlockup: hung tasks
 CPU: 7 PID: 2669225 Comm: kworker/u16:3
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
 Workqueue: dm-thin do_worker [dm_thin_pool]
 Call Trace:
   <IRQ>
   dump_stack+0x9c/0xd3
   panic+0x35d/0x6b9
   watchdog_timer_fn.cold+0x16/0x25
   __run_hrtimer+0xa2/0x2d0
   </IRQ>
   RIP: 0010:__relink_lru+0x102/0x220 [dm_bufio]
   __bufio_new+0x11f/0x4f0 [dm_bufio]
   new_read+0xa3/0x1e0 [dm_bufio]
   dm_bm_read_lock+0x33/0xd0 [dm_persistent_data]
   ro_step+0x63/0x100 [dm_persistent_data]
   btree_lookup_raw.constprop.0+0x44/0x220 [dm_persistent_data]
   dm_btree_lookup+0x16f/0x210 [dm_persistent_data]
   dm_thin_find_block+0x12c/0x210 [dm_thin_pool]
   __process_bio_read_only+0xc5/0x400 [dm_thin_pool]
   process_thin_deferred_bios+0x1a4/0x4a0 [dm_thin_pool]
   process_one_work+0x3c5/0x730

Following process may generate a broken btree mixed with fresh and
stale btree nodes, which could get dm thin trapped in an infinite loop
while looking up data block:
 Transaction 1: pmd->root = A, A->B->C   // One path in btree
                pmd->root = X, X->Y->Z   // Copy-up
 Transaction 2: X,Z is updated on disk, Y write failed.
                // Commit failed, dm thin becomes read-only.
                process_bio_read_only
		 dm_thin_find_block
		  __find_block
		   dm_btree_lookup(pmd->root)
The pmd->root points to a broken btree, Y may contain stale node
pointing to any block, for example X, which gets dm thin trapped into
a dead loop while looking up Z.

Fix this by setting pmd->root in __open_metadata(), so that dm thin
will use the last transaction's pmd->root if commit failed.

Fetch a reproducer in [Link].

Linke: https://bugzilla.kernel.org/show_bug.cgi?id=216790
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/3db757ffdd87ed8d7118b2250236a496502a660f; https://git.kernel.org/stable/c/4b710e8481ade7c9200e94d3018e99dc42a0a0e8; https://git.kernel.org/stable/c/7991dbff6849f67e823b7cc0c15e5a90b0549b9f
CVE: CVE-2022-50535
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/display: Fix potential null-deref in dm_resume

[Why]
Fixing smatch error:
dm_resume() error: we previously assumed 'aconnector->dc_link' could be null

[How]
Check if dc_link null at the beginning of the loop,
so further checks can be dropped.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/00b655fa96b4e941351cc4bf5ca755a65ae94a8e; https://git.kernel.org/stable/c/7a7175a2cd84b7874bebbf8e59f134557a34161b; https://git.kernel.org/stable/c/8e365f1bd672cc9320a936f6ae6f8087aa40e9bc
CVE: CVE-2022-50536
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf, sockmap: Fix repeated calls to sock_put() when msg has more_data

In tcp_bpf_send_verdict() redirection, the eval variable is assigned to
__SK_REDIRECT after the apply_bytes data is sent, if msg has more_data,
sock_put() will be called multiple times.

We should reset the eval variable to __SK_NONE every time more_data
starts.

This causes:

IPv4: Attempt to release TCP socket in state 1 00000000b4c925d7
------------[ cut here ]------------
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 4482 at lib/refcount.c:25 refcount_warn_saturate+0x7d/0x110
Modules linked in:
CPU: 5 PID: 4482 Comm: sockhash_bypass Kdump: loaded Not tainted 6.0.0 #1
Hardware name: Red Hat KVM, BIOS 1.11.0-2.el7 04/01/2014
Call Trace:
 <TASK>
 __tcp_transmit_skb+0xa1b/0xb90
 ? __alloc_skb+0x8c/0x1a0
 ? __kmalloc_node_track_caller+0x184/0x320
 tcp_write_xmit+0x22a/0x1110
 __tcp_push_pending_frames+0x32/0xf0
 do_tcp_sendpages+0x62d/0x640
 tcp_bpf_push+0xae/0x2c0
 tcp_bpf_sendmsg_redir+0x260/0x410
 ? preempt_count_add+0x70/0xa0
 tcp_bpf_send_verdict+0x386/0x4b0
 tcp_bpf_sendmsg+0x21b/0x3b0
 sock_sendmsg+0x58/0x70
 __sys_sendto+0xfa/0x170
 ? xfd_validate_state+0x1d/0x80
 ? switch_fpu_return+0x59/0xe0
 __x64_sys_sendto+0x24/0x30
 do_syscall_64+0x37/0x90
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/113236e8f49f262f318c00ebb14b15f4834e87c1; https://git.kernel.org/stable/c/28e4a763cd4a2b1a78852216ef4bd7df3a05cec6; https://git.kernel.org/stable/c/578a7628b838a3ac8ad61deaab5a816ff032ac13
CVE: CVE-2022-50537
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware: raspberrypi: fix possible memory leak in rpi_firmware_probe()

In rpi_firmware_probe(), if mbox_request_channel() fails, the 'fw' will
not be freed through rpi_firmware_delete(), fix this leak by calling
kfree() in the error path.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/62ac943eb2a9d655e431b9bc98ff6d7bd51a0e49; https://git.kernel.org/stable/c/6757dd2193fe18c5c5fe3050e7f2ff9dcbd1ff34; https://git.kernel.org/stable/c/71d2abab374f707ab8ac8dcef191fd2b3b67b8bd
CVE: CVE-2022-50538
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

vme: Fix error not catched in fake_init()

In fake_init(), __root_device_register() is possible to fail but it's
ignored, which can cause unregistering vme_root fail when exit.

 general protection fault,
 probably for non-canonical address 0xdffffc000000008c
 KASAN: null-ptr-deref in range [0x[PII_REDACTED]000460-0x[PII_REDACTED]000467]
 RIP: 0010:root_device_unregister+0x26/0x60
 Call Trace:
  <TASK>
  __x64_sys_delete_module+0x34f/0x540
  do_syscall_64+0x38/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd

Return error when __root_device_register() fails.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/09be0e7ac5f9374b6f8de72c89ed67129af71f65; https://git.kernel.org/stable/c/37d3de40c1ffb6a5e626bf46ff5ef5766c824e2c; https://git.kernel.org/stable/c/4bc217b25ea81034fad8e33fd33e4659f086421d
CVE: CVE-2022-50539
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

ARM: OMAP2+: omap4-common: Fix refcount leak bug

In omap4_sram_init(), of_find_compatible_node() will return a node
pointer with refcount incremented. We should use of_node_put() when
it is not used anymore.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/049875b76660bbdc4873a915afb294f954eb7320; https://git.kernel.org/stable/c/1d9452ae3bdb830f9309cf10a2f65977999cb14e; https://git.kernel.org/stable/c/7c32919a378782c95c72bc028b5c30dfe8c11f82
CVE: CVE-2022-50540
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: qcom-adm: fix wrong sizeof config in slave_config

Fix broken slave_config function that uncorrectly compare the
peripheral_size with the size of the config pointer instead of the size
of the config struct. This cause the crci value to be ignored and cause
a kernel panic on any slave that use adm driver.

To fix this, compare to the size of the struct and NOT the size of the
pointer.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7490274b41a432824f7df5071ace3df2ab59caa7; https://git.kernel.org/stable/c/7c[PII_REDACTED]be30f50c1b5b97618b731514b207; https://git.kernel.org/stable/c/f1dd45a6585a1689e1e8906b3f9e302b9d40c715
CVE: CVE-2022-50541
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

dmaengine: ti: k3-udma: Reset UDMA_CHAN_RT byte counters to prevent overflow

UDMA_CHAN_RT_*BCNT_REG stores the real-time channel bytecount statistics.
These registers are 32-bit hardware counters and the driver uses these
counters to monitor the operational progress status for a channel, when
transferring more than 4GB of data it was observed that these counters
overflow and completion calculation of a operation gets affected and the
transfer hangs indefinitely.

This commit adds changes to decrease the byte count for every complete
transaction so that these registers never overflow and the proper byte
count statistics is maintained for ongoing transaction by the RT counters.

Earlier uc->bcnt used to maintain a count of the completed bytes at driver
side, since the RT counters maintain the statistics of current transaction
now, the maintenance of uc->bcnt is not necessary.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/7c94dcfa8fcff2dba53915f1dabfee49a3df8b88; https://git.kernel.org/stable/c/a065657643a62a24b4435ddcaea45f1e9378749e; https://git.kernel.org/stable/c/d68da10b0cceb4177b653833e794b2923a4ffbd7
CVE: CVE-2022-50542
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

media: si470x: Fix use-after-free in si470x_int_in_callback()

syzbot reported use-after-free in si470x_int_in_callback() [1].  This
indicates that urb->context, which contains struct si470x_device
object, is freed when si470x_int_in_callback() is called.

The cause of this issue is that si470x_int_in_callback() is called for
freed urb.

si470x_usb_driver_probe() calls si470x_start_usb(), which then calls
usb_submit_urb() and si470x_start().  If si470x_start_usb() fails,
si470x_usb_driver_probe() doesn't kill urb, but it just frees struct
si470x_device object, as depicted below:

si470x_usb_driver_probe()
  ...
  si470x_start_usb()
    ...
    usb_submit_urb()
    retval = si470x_start()
    return retval
  if (retval < 0)
    free struct si470x_device object, but don't kill urb

This patch fixes this issue by killing urb when si470x_start_usb()
fails and urb is submitted.  If si470x_start_usb() fails and urb is
not submitted, i.e. submitting usb fails, it just frees struct
si470x_device object.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/0ca298d548461d29615f9a2b1309e8dcf4a352c6; https://git.kernel.org/stable/c/146bd005ebb01ae190c22af050cb98623958c373; https://git.kernel.org/stable/c/1c6447d0fc68650e51586dde79b5090d9d77f13a
CVE: CVE-2022-50543
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

RDMA/rxe: Fix mr->map double free

rxe_mr_cleanup() which tries to free mr->map again will be called when
rxe_mr_init_user() fails:

   CPU: 0 PID: 4917 Comm: rdma_flush_serv Kdump: loaded Not tainted 6.1.0-rc1-roce-flush+ #25
   Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
   Call Trace:
    <TASK>
    dump_stack_lvl+0x45/0x5d
    panic+0x19e/0x349
    end_report.part.0+0x54/0x7c
    kasan_report.cold+0xa/0xf
    rxe_mr_cleanup+0x9d/0xf0 [rdma_rxe]
    __rxe_cleanup+0x10a/0x1e0 [rdma_rxe]
    rxe_reg_user_mr+0xb7/0xd0 [rdma_rxe]
    ib_uverbs_reg_mr+0x26a/0x480 [ib_uverbs]
    ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0x1a2/0x250 [ib_uverbs]
    ib_uverbs_cmd_verbs+0x1397/0x15a0 [ib_uverbs]

This issue was firstly exposed since commit b18c7da63fcb ("RDMA/rxe: Fix
memory leak in error path code") and then we fixed it in commit
8ff5f5d9d8cf ("RDMA/rxe: Prevent double freeing rxe_map_set()") but this
fix was reverted together at last by commit 1e75550648da (Revert
"RDMA/rxe: Create duplicate mapping tables for FMRs")

Simply let rxe_mr_cleanup() always handle freeing the mr->map once it is
successfully allocated.
CVSS Score: 7.8 (HIGH)
CWE: CWE-415
References: https://git.kernel.org/stable/c/06f73568f553b5be6ba7f6fe274d333ea29fc46d; https://git.kernel.org/stable/c/6ce577f09013206e36e674cd27da3707b2278268; https://git.kernel.org/stable/c/7d984dac8f6bf4ebd3398af82b357e1d181ecaac
CVE: CVE-2022-50544
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: host: xhci: Fix potential memory leak in xhci_alloc_stream_info()

xhci_alloc_stream_info() allocates stream context array for stream_info
->stream_ctx_array with xhci_alloc_stream_ctx(). When some error occurs,
stream_info->stream_ctx_array is not released, which will lead to a
memory leak.

We can fix it by releasing the stream_info->stream_ctx_array with
xhci_free_stream_ctx() on the error path to avoid the potential memory
leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/782c873f8e7686f5b3c47e8b099f7e08c3dd1fdc; https://git.kernel.org/stable/c/7e271f42a5cc3768cd2622b929ba66859ae21f97; https://git.kernel.org/stable/c/7fc6bab3413e6a42bb1264ff7c9149808c93a4c7
CVE: CVE-2022-50545
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

r6040: Fix kmemleak in probe and remove

There is a memory leaks reported by kmemleak:

  unreferenced object 0xffff[PII_REDACTED]00 (size 2048):
    comm "modprobe", pid 817, jiffies[PII_REDACTED] (age 76.502s)
    hex dump (first 32 bytes):
      00 c4 0a 04 81 88 ff ff 08 10 11 16 81 88 ff ff  ................
      08 10 11 16 81 88 ff ff 00 00 00 00 00 00 00 00  ................
    backtrace:
      [<ffffffff815bcd82>] kmalloc_trace+0x22/0x60
      [<ffffffff827e20ee>] phy_device_create+0x4e/0x90
      [<ffffffff827e6072>] get_phy_device+0xd2/0x220
      [<ffffffff827e7844>] mdiobus_scan+0xa4/0x2e0
      [<ffffffff827e8be2>] __mdiobus_register+0x482/0x8b0
      [<ffffffffa01f5d24>] r6040_init_one+0x714/0xd2c [r6040]
      ...

The problem occurs in probe process as follows:
  r6040_init_one:
    mdiobus_register
      mdiobus_scan    <- alloc and register phy_device,
                         the reference count of phy_device is 3
    r6040_mii_probe
      phy_connect     <- connect to the first phy_device,
                         so the reference count of the first
                         phy_device is 4, others are 3
    register_netdev   <- fault inject succeeded, goto error handling path

    // error handling path
    err_out_mdio_unregister:
      mdiobus_unregister(lp->mii_bus);
    err_out_mdio:
      mdiobus_free(lp->mii_bus);    <- the reference count of the first
                                       phy_device is 1, it is not released
                                       and other phy_devices are released
  // similarly, the remove process also has the same problem

The root cause is traced to the phy_device is not disconnected when
removes one r6040 device in r6040_remove_one() or on error handling path
after r6040_mii probed successfully. In r6040_mii_probe(), a net ethernet
device is connected to the first PHY device of mii_bus, in order to
notify the connected driver when the link status changes, which is the
default behavior of the PHY infrastructure to handle everything.
Therefore the phy_device should be disconnected when removes one r6040
device or on error handling path.

Fix it by adding phy_disconnect() when removes one r6040 device or on
error handling path after r6040_mii probed successfully.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/2ce242e1b9ad31c1f68496b3548e407a8cb2c07d; https://git.kernel.org/stable/c/3d5f83a62e8235d235534b3dc6f197d8a822c269; https://git.kernel.org/stable/c/5944c25c67de54e0aa53623e1e1af3bf8b16ed44
CVE: CVE-2022-50547
Published: 2025-10-07
Description: In the Linux kernel, the following vulnerability has been resolved:

media: solo6x10: fix possible memory leak in solo_sysfs_init()

If device_register() returns error in solo_sysfs_init(), the
name allocated by dev_set_name() need be freed. As comment of
device_register() says, it should use put_device() to give up
the reference in the error path. So fix this by calling
put_device(), then the name can be freed in kobject_cleanup().
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/49060c0da57a381563e482e331dc9d4c3725b41b; https://git.kernel.org/stable/c/7b02c50d[PII_REDACTED]808e13bc13137fb81286b5; https://git.kernel.org/stable/c/7cf71bbe5d2ee12613f6e278888f5fc9c5c0cc2b