deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2022-49948
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

vt: Clear selection before changing the font

When changing the console font with ioctl(KDFONTOP) the new font size
can be bigger than the previous font. A previous selection may thus now
be outside of the new screen size and thus trigger out-of-bounds
accesses to graphics memory if the selection is removed in
vc_do_resize().

Prevent such out-of-memory accesses by dropping the selection before the
various con_font_set() console handlers are called.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/1cf1930369c9dc428d827b60260c53271bff3285; https://git.kernel.org/stable/c/2535431ae967ad[PII_REDACTED]625fea7db28d4db; https://git.kernel.org/stable/c/566f9c9f[PII_REDACTED]0b5a6062dff448b3e7977f
CVE: CVE-2022-49949
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware_loader: Fix memory leak in firmware upload

In the case of firmware-upload, an instance of struct fw_upload is
allocated in firmware_upload_register(). This data needs to be freed
in fw_dev_release(). Create a new fw_upload_free() function in
sysfs_upload.c to handle the firmware-upload specific memory frees
and incorporate the missing kfree call for the fw_upload structure.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/789bba82f63c3e81dce426ba457fc7905b30ac6e; https://git.kernel.org/stable/c/baf92485d111be828e1ab84a995515b604b938e5
CVE: CVE-2022-49950
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

misc: fastrpc: fix memory corruption on open

The probe session-duplication overflow check incremented the session
count also when there were no more available sessions so that memory
beyond the fixed-size slab-allocated session array could be corrupted in
fastrpc_session_alloc() on open().
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/5cf2a57c7a01a0d7bdecf875a63682f542891b1b; https://git.kernel.org/stable/c/cf20c3533efc89578ace94fa20a9e63446223c72; https://git.kernel.org/stable/c/d245f43aab2b61195d8ebb64cef7b5a08c590ab4
CVE: CVE-2022-49951
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

firmware_loader: Fix use-after-free during unregister

In the following code within firmware_upload_unregister(), the call to
device_unregister() could result in the dev_release function freeing the
fw_upload_priv structure before it is dereferenced for the call to
module_put(). This bug was found by the kernel test robot using
CONFIG_KASAN while running the firmware selftests.

  device_unregister(&fw_sysfs->dev);
  module_put(fw_upload_priv->module);

The problem is fixed by copying fw_upload_priv->module to a local variable
for use when calling device_unregister().
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/8b40c38e37492b5bdf8e95b46b5cca9517a9957a; https://git.kernel.org/stable/c/d380d40930a674c520a5b55f3be1eb17dc634ebc
CVE: CVE-2022-49952
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

misc: fastrpc: fix memory corruption on probe

Add the missing sanity check on the probed-session count to avoid
corrupting memory beyond the fixed-size slab-allocated session array
when there are more than FASTRPC_MAX_SESSIONS sessions defined in the
devicetree.
CVSS Score: 7.8 (HIGH)
CWE: CWE-787
References: https://git.kernel.org/stable/c/0e33b0f322fecd7a92d9dc186535cdf97940a856; https://git.kernel.org/stable/c/9baa1415d9abdd1e08362ea2dcfadfacee8690b5; https://git.kernel.org/stable/c/c0425c2facd9166fa083f90c9f3187ace0c7837a
CVE: CVE-2022-49953
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: light: cm3605: Fix an error handling path in cm3605_probe()

The commit in Fixes also introduced a new error handling path which should
goto the existing error handling path.
Otherwise some resources leak.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/160905549e663019e26395ed9d66c24ee2cf5187; https://git.kernel.org/stable/c/3f7f49d8135cfe137c81316af64678f4dca1b82b
CVE: CVE-2022-49954
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

Input: iforce - wake up after clearing IFORCE_XMIT_RUNNING flag

syzbot is reporting hung task at __input_unregister_device() [1], for
iforce_close() waiting at wait_event_interruptible() with dev->mutex held
is blocking input_disconnect_device() from __input_unregister_device().

It seems that the cause is simply that commit c2b27ef672992a20 ("Input:
iforce - wait for command completion when closing the device") forgot to
call wake_up() after clear_bit().

Fix this problem by introducing a helper that calls clear_bit() followed
by wake_up_all().
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/98e01215708b6d416345465c09dce2bd4868c67a; https://git.kernel.org/stable/c/b271090eea3899399e2adcf79c9c95367d472b03; https://git.kernel.org/stable/c/b533b9d3a0d1327cbb31c201dc8dbbf98c8bfe3c
CVE: CVE-2022-49955
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

powerpc/rtas: Fix RTAS MSR[HV] handling for Cell

The semi-recent changes to MSR handling when entering RTAS (firmware)
cause crashes on IBM Cell machines. An example trace:

  kernel tried to execute user page (2fff01a8) - exploit attempt? (uid: 0)
  BUG: Unable to handle kernel instruction fetch
  Faulting instruction address: 0x2fff01a8
  Oops: Kernel access of bad area, sig: 11 [#1]
  BE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=4 NUMA Cell
  Modules linked in:
  CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W          6.0.0-rc2-00433-gede0a8d3307a #207
  NIP:  000000002fff01a8 LR: [PII_REDACTED] CTR: [PII_REDACTED]
  REGS: c[PII_REDACTED]236b0 TRAP: 0400   Tainted: G        W           (6.0.0-rc2-00433-gede0a8d3307a)
  MSR:  [PII_REDACTED] <ME,RI>  CR: 00000000  XER: 20000000
  ...
  NIP 0x2fff01a8
  LR  0x32608
  Call Trace:
    0xc[PII_REDACTED]3c5f8 (unreliable)
    .rtas_call+0x224/0x320
    .rtas_get_boot_time+0x70/0x150
    .read_persistent_clock64+0x114/0x140
    .read_persistent_wall_and_boot_offset+0x24/0x80
    .timekeeping_init+0x40/0x29c
    .start_kernel+0x674/0x8f0
    start_here_common+0x1c/0x50

Unlike PAPR platforms where RTAS is only used in guests, on the IBM Cell
machines Linux runs with MSR[HV] set but also uses RTAS, provided by
SLOF.

Fix it by copying the MSR[HV] bit from the MSR value we've just read
using mfmsr into the value used for RTAS.

It seems like we could also fix it using an #ifdef CELL to set MSR[HV],
but that doesn't work because it's possible to build a single kernel
image that runs on both Cell native and pseries.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/8b08d4f97233d8e58fff2fd9d5f86397a49733c5; https://git.kernel.org/stable/c/91926d8b7e71aaf5f84f0cf208fc5a8b7a761050
CVE: CVE-2022-49956
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

staging: rtl8712: fix use after free bugs

_Read/Write_MACREG callbacks are NULL so the read/write_macreg_hdl()
functions don't do anything except free the "pcmd" pointer.  It
results in a use after free.  Delete them.
CVSS Score: 7.8 (HIGH)
CWE: CWE-416
References: https://git.kernel.org/stable/c/19e3f69d19801940abc2ac37c169882769ed9770; https://git.kernel.org/stable/c/376e15487fec837301d888068a3fcc82efb6171a; https://git.kernel.org/stable/c/7dce6b0ee7d78667d6c831ced957a[PII_REDACTED]3
CVE: CVE-2022-49957
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

kcm: fix strp_init() order and cleanup

strp_init() is called just a few lines above this csk->sk_user_data
check, it also initializes strp->work etc., therefore, it is
unnecessary to call strp_done() to cancel the freshly initialized
work.

And if sk_user_data is already used by KCM, psock->strp should not be
touched, particularly strp->work state, so we need to move strp_init()
after the csk->sk_user_data check.

This also makes a lockdep warning reported by syzbot go away.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-908
References: https://git.kernel.org/stable/c/0946ff31d1a8778787bf6708beb20f38715267cc; https://git.kernel.org/stable/c/1b6666964ca1de93a7bf06e122bcf3616dbd33a9; https://git.kernel.org/stable/c/473f[PII_REDACTED]14087f4179e55cdf0cf616a13b
CVE: CVE-2022-49958
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

net/sched: fix netdevice reference leaks in attach_default_qdiscs()

In attach_default_qdiscs(), if a dev has multiple queues and queue 0 fails
to attach qdisc because there is no memory in attach_one_default_qdisc().
Then dev->qdisc will be noop_qdisc by default. But the other queues may be
able to successfully attach to default qdisc.

In this case, the fallback to noqueue process will be triggered. If the
original attached qdisc is not released and a new one is directly
attached, this will cause netdevice reference leaks.

The following is the bug log:

veth0: default qdisc (fq_codel) fail, fallback to noqueue
unregister_netdevice: waiting for veth0 to become free. Usage count = 32
leaked reference.
 qdisc_alloc+0x12e/0x210
 qdisc_create_dflt+0x62/0x140
 attach_one_default_qdisc.constprop.41+0x44/0x70
 dev_activate+0x128/0x290
 __dev_open+0x12a/0x190
 __dev_change_flags+0x1a2/0x1f0
 dev_change_flags+0x23/0x60
 do_setlink+0x332/0x1150
 __rtnl_newlink+0x52f/0x8e0
 rtnl_newlink+0x43/0x70
 rtnetlink_rcv_msg+0x140/0x3b0
 netlink_rcv_skb+0x50/0x100
 netlink_unicast+0x1bb/0x290
 netlink_sendmsg+0x37c/0x4e0
 sock_sendmsg+0x5f/0x70
 ____sys_sendmsg+0x208/0x280

Fix this bug by clearing any non-noop qdiscs that may have been assigned
before trying to re-attach.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/0c6c522857151ac00150fd01baeebf231fb7d142; https://git.kernel.org/stable/c/44dfa645895a56f65461249deb5b81cd16560e2a; https://git.kernel.org/stable/c/a420d[PII_REDACTED]07eda9c5766cfa9bdd5c39a56
CVE: CVE-2022-49959
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

openvswitch: fix memory leak at failed datapath creation

ovs_dp_cmd_new()->ovs_dp_change()->ovs_dp_set_upcall_portids()
allocates array via kmalloc.
If for some reason new_vport() fails during ovs_dp_cmd_new()
dp->upcall_portids must be freed.
Add missing kfree.

Kmemleak example:
unreferenced object 0xffff88800c382500 (size 64):
  comm "dump_state", pid 323, jiffies[PII_REDACTED] (age 104.347s)
  hex dump (first 32 bytes):
    5e c2 79 e4 1f 7a 38 c7 09 21 38 0c 80 88 ff ff  ^.y..z8..!8.....
    03 00 00 00 0a 00 00 00 14 00 00 00 28 00 00 00  ............(...
  backtrace:
    [<[PII_REDACTED]bebc9f>] ovs_dp_set_upcall_portids+0x38/0xa0
    [<[PII_REDACTED]87d8bd>] ovs_dp_change+0x63/0xe0
    [<[PII_REDACTED]97e446>] ovs_dp_cmd_new+0x1f0/0x380
    [<00000000aa06f36e>] genl_family_rcv_msg_doit+0xea/0x150
    [<000000008f583bc4>] genl_rcv_msg+0xdc/0x1e0
    [<00000000fa10e377>] netlink_rcv_skb+0x50/0x100
    [<[PII_REDACTED]59cece>] genl_rcv+0x24/0x40
    [<[PII_REDACTED]99ac7f>] netlink_unicast+0x23e/0x360
    [<00000000c153573e>] netlink_sendmsg+0x24e/0x4b0
    [<000000006f4aa380>] sock_sendmsg+0x62/0x70
    [<00000000d0068654>] ____sys_sendmsg+0x230/0x270
    [<[PII_REDACTED]dacf7d>] ___sys_sendmsg+0x88/0xd0
    [<[PII_REDACTED]>] __sys_sendmsg+0x59/0xa0
    [<000000002e8f2dc1>] do_syscall_64+0x3b/0x90
    [<[PII_REDACTED]43e7cb>] entry_SYSCALL_64_after_hwframe+0x63/0xcd
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/a87406f4adee9c53b311d8a1ba2849c69e29a6d0; https://git.kernel.org/stable/c/c0c1c[PII_REDACTED]644326a1a3102207c871ae159; https://git.kernel.org/stable/c/ca54b2bfaab385778e55a9fd33f6c31e7f743b48
CVE: CVE-2022-49960
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915: fix null pointer dereference

Asus chromebook CX550 crashes during boot on v5.17-rc1 kernel.
The root cause is null pointer defeference of bi_next
in tgl_get_bw_info() in drivers/gpu/drm/i915/display/intel_bw.c.

BUG: kernel NULL pointer dereference, address:[PII_REDACTED]00002e
PGD 0 P4D 0
Oops: 0002 [#1] PREEMPT SMP NOPTI
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G     U            5.17.0-rc1
Hardware name: Google Delbin/Delbin, BIOS Google_Delbin.13672.156.3 05/14/2021
RIP: 0010:tgl_get_bw_info+0x2de/0x510
...
[    2.554467] Call Trace:
[    2.554467]  <TASK>
[    2.554467]  intel_bw_init_hw+0x14a/0x434
[    2.554467]  ? _printk+0x59/0x73
[    2.554467]  ? _dev_err+0x77/0x91
[    2.554467]  i915_driver_hw_probe+0x329/0x33e
[    2.554467]  i915_driver_probe+0x4c8/0x638
[    2.554467]  i915_pci_probe+0xf8/0x14e
[    2.554467]  ? _raw_spin_unlock_irqrestore+0x12/0x2c
[    2.554467]  pci_device_probe+0xaa/0x142
[    2.554467]  really_probe+0x13f/0x2f4
[    2.554467]  __driver_probe_device+0x9e/0xd3
[    2.554467]  driver_probe_device+0x24/0x7c
[    2.554467]  __driver_attach+0xba/0xcf
[    2.554467]  ? driver_attach+0x1f/0x1f
[    2.554467]  bus_for_each_dev+0x8c/0xc0
[    2.554467]  bus_add_driver+0x11b/0x1f7
[    2.554467]  driver_register+0x60/0xea
[    2.554467]  ? mipi_dsi_bus_init+0x16/0x16
[    2.554467]  i915_init+0x2c/0xb9
[    2.554467]  ? mipi_dsi_bus_init+0x16/0x16
[    2.554467]  do_one_initcall+0x12e/0x2b3
[    2.554467]  do_initcall_level+0xd6/0xf3
[    2.554467]  do_initcalls+0x4e/0x79
[    2.554467]  kernel_init_freeable+0xed/0x14d
[    2.554467]  ? rest_init+0xc1/0xc1
[    2.554467]  kernel_init+0x1a/0x120
[    2.554467]  ret_from_fork+0x1f/0x30
[    2.554467]  </TASK>
...
Kernel panic - not syncing: Fatal exception

(cherry picked from commit c247cd03898c4c43c3bce6d[PII_REDACTED]bc13032)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/458ec0c8f35963626ccd51c3d50b752de5f1b9d4; https://git.kernel.org/stable/c/c[PII_REDACTED]f4729bab0b917bf4c17a159abf9f8
CVE: CVE-2022-49961
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Do mark_chain_precision for ARG_CONST_ALLOC_SIZE_OR_ZERO

Precision markers need to be propagated whenever we have an ARG_CONST_*
style argument, as the verifier cannot consider imprecise scalars to be
equivalent for the purposes of states_equal check when such arguments
refine the return value (in this case, set mem_size for PTR_TO_MEM). The
resultant mem_size for the R0 is derived from the constant value, and if
the verifier incorrectly prunes states considering them equivalent where
such arguments exist (by seeing that both registers have reg->precise as
false in regsafe), we can end up with invalid programs passing the
verifier which can do access beyond what should have been the correct
mem_size in that explored state.

To show a concrete example of the problem:

[PII_REDACTED] <prog>:
       0:       r2 = *(u32 *)(r1 + 80)
       1:       r1 = *(u32 *)(r1 + 76)
       2:       r3 = r1
       3:       r3 += 4
       4:       if r3 > r2 goto +18 <LBB5_5>
       5:       w2 = 0
       6:       *(u32 *)(r1 + 0) = r2
       7:       r1 = *(u32 *)(r1 + 0)
       8:       r2 = 1
       9:       if w1 == 0 goto +1 <LBB5_3>
      10:       r2 = -1

[PII_REDACTED] <LBB5_3>:
      11:       r1 = 0 ll
      13:       r3 = 0
      14:       call bpf_ringbuf_reserve
      15:       if r0 == 0 goto +7 <LBB5_5>
      16:       r1 = r0
      17:       r1 += 16777215
      18:       w2 = 0
      19:       *(u8 *)(r1 + 0) = r2
      20:       r1 = r0
      21:       r2 = 0
      22:       call bpf_ringbuf_submit
[PII_REDACTED]0000b8 <LBB5_5>:
      23:       w0 = 0
      24:       exit

For the first case, the single line execution's exploration will prune
the search at insn 14 for the branch insn 9's second leg as it will be
verified first using r2 = -1 (UINT_MAX), while as w1 at insn 9 will
always be 0 so at runtime we don't get error for being greater than
UINT_MAX/4 from bpf_ringbuf_reserve. The verifier during regsafe just
sees reg->precise as false for both r2 registers in both states, hence
considers them equal for purposes of states_equal.

If we propagated precise markers using the backtracking support, we
would use the precise marking to then ensure that old r2 (UINT_MAX) was
within the new r2 (1) and this would never be true, so the verification
would rightfully fail.

The end result is that the out of bounds access at instruction 19 would
be permitted without this fix.

Note that reg->precise is always set to true when user does not have
CAP_BPF (or when subprog count is greater than 1 (i.e. use of any static
or global functions)), hence this is only a problem when precision marks
need to be explicitly propagated (i.e. privileged users with CAP_BPF).

A simplified test case has been included in the next patch to prevent
future regressions.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/2459615a8d7f44ac81f0965bc094e55ccb254717; https://git.kernel.org/stable/c/2fc31465c5373b5ca4edf2e5238558cb62902311
CVE: CVE-2022-49962
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

xhci: Fix null pointer dereference in remove if xHC has only one roothub

The remove path in xhci platform driver tries to remove and put both main
and shared hcds even if only a main hcd exists (one roothub)

This causes a null pointer dereference in reboot for those controllers.

Check that the shared_hcd exists before trying to remove it.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-476
References: https://git.kernel.org/stable/c/4a593a62a9e3a25ab4bc37f612e4edec144f7f43; https://git.kernel.org/stable/c/7081b2f34ff291ada012bd6abacaf7d51c4cf73f
CVE: CVE-2022-49963
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/i915/ttm: fix CCS handling

Crucible + recent Mesa seems to sometimes hit:

GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER)

And it looks like we can also trigger this with gem_lmem_swapping, if we
modify the test to use slightly larger object sizes.

Looking closer it looks like we have the following issues in
migrate_copy():

  - We are using plain integer in various places, which we can easily
    overflow with a large object.

  - We pass the entire object size (when the src is lmem) into
    emit_pte() and then try to copy it, which doesn't work, since we
    only have a few fixed sized windows in which to map the pages and
    perform the copy. With an object > 8M we therefore aren't properly
    copying the pages. And then with an object > 64M we trigger the
    GEM_BUG_ON(num_ccs_blks > NUM_CCS_BLKS_PER_XFER).

So it looks like our copy handling for any object > 8M (which is our
CHUNK_SZ) is currently broken on DG2.

Testcase: igt@gem_lmem_swapping
(cherry picked from commit 8676145eb2f53a9940ff70910caf0125bd8a4bc2)
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/8d[PII_REDACTED]65c8e6be697d82c7dbf5d08f574d; https://git.kernel.org/stable/c/97434cb55bd884bd268626ec41489f79b261b2d4
CVE: CVE-2022-49964
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

arm64: cacheinfo: Fix incorrect assignment of signed error value to unsigned fw_level

Though acpi_find_last_cache_level() always returned signed value and the
document states it will return any errors caused by lack of a PPTT table,
it never returned negative values before.

Commit 0c80f9e165f8 ("ACPI: PPTT: Leave the table mapped for the runtime usage")
however changed it by returning -ENOENT if no PPTT was found. The value
returned from acpi_find_last_cache_level() is then assigned to unsigned
fw_level.

It will result in the number of cache leaves calculated incorrectly as
a huge value which will then cause the following warning from __alloc_pages
as the order would be great than MAX_ORDER because of incorrect and huge
cache leaves value.

  |  WARNING: CPU: 0 PID: 1 at mm/page_alloc.c:5407 __alloc_pages+0x74/0x314
  |  Modules linked in:
  |  CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.19.0-10393-g7c2a8d3ac4c0 #73
  |  pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
  |  pc : __alloc_pages+0x74/0x314
  |  lr : alloc_pages+0xe8/0x318
  |  Call trace:
  |   __alloc_pages+0x74/0x314
  |   alloc_pages+0xe8/0x318
  |   kmalloc_order_trace+0x68/0x1dc
  |   __kmalloc+0x240/0x338
  |   detect_cache_attributes+0xe0/0x56c
  |   update_siblings_masks+0x38/0x284
  |   store_cpu_topology+0x78/0x84
  |   smp_prepare_cpus+0x48/0x134
  |   kernel_init_freeable+0xc4/0x14c
  |   kernel_init+0x2c/0x1b4
  |   ret_from_fork+0x10/0x20

Fix the same by changing fw_level to be signed integer and return the
error from init_cache_level() early in case of error.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/a754ee1c66bd0a23e613f0bf865053b29cb90e16; https://git.kernel.org/stable/c/e75d18cecbb3805895d8ed64da4f78575ec96043
CVE: CVE-2022-49965
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: add missing ->fini_xxxx interfaces for some SMU13 asics

Without these, potential memory leak may be induced.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/22a75c616f1971c23838506b14971a4ef4a66bd7; https://git.kernel.org/stable/c/4bac1c846eff8042dd59ddecd0a43f3b9de5fd23
CVE: CVE-2022-49966
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amd/pm: add missing ->fini_microcode interface for Sienna Cichlid

To avoid any potential memory leak.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-401
References: https://git.kernel.org/stable/c/0a2d922a5618377cdf8fa[PII_REDACTED]33ef55342; https://git.kernel.org/stable/c/4d21584ac6392aa66171b7efd647ecd1a447556b; https://git.kernel.org/stable/c/60d522f317078381ff8a3599fe808f96fc256cd5
CVE: CVE-2022-49967
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

bpf: Fix a data-race around bpf_jit_limit.

While reading bpf_jit_limit, it can be changed concurrently via sysctl,
WRITE_ONCE() in __do_proc_doulongvec_minmax(). The size of bpf_jit_limit
is long, so we need to add a paired READ_ONCE() to avoid load-tearing.
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/0947ae1121083d363d522ff7518ee72b55bd8d29; https://git.kernel.org/stable/c/ba632ad0bacb13197a8f38e[PII_REDACTED]e87f292
CVE: CVE-2022-49968
Published: 2025-06-18
Description: In the Linux kernel, the following vulnerability has been resolved:

ieee802154/adf7242: defer destroy_workqueue call

There is a possible race condition (use-after-free) like below

  (FREE)                     |  (USE)
  adf7242_remove             |  adf7242_channel
   cancel_delayed_work_sync  |
    destroy_workqueue (1)    |   adf7242_cmd_rx
                             |    mod_delayed_work (2)
                             |

The root cause for this race is that the upper layer (ieee802154) is
unaware of this detaching event and the function adf7242_channel can
be called without any checks.

To fix this, we can add a flag write at the beginning of adf7242_remove
and add flag check in adf7242_channel. Or we can just defer the
destructive operation like other commit 3e0588c291d6 ("hamradio: defer
ax25 kfree after unregister_netdev") which let the
ieee802154_unregister_hw() to handle the synchronization. This patch
takes the second option.

runs")
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-416
References: https://git.kernel.org/stable/c/15f3b89bd521d5770d36a61fc04a77c293138ba6; https://git.kernel.org/stable/c/23a29932715ca43bceb2eae1bdb770995afe7271; https://git.kernel.org/stable/c/9f8558c5c642c62c450c98c99b7d18a709fff485