deardaniel/secdata-raw huggingface dataset:
CVE: CVE-2025-21647
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

sched: sch_cake: add bounds checks to host bulk flow fairness counts

Even though we fixed a logic error in the commit cited below, syzbot
still managed to trigger an underflow of the per-host bulk flow
counters, leading to an out of bounds memory access.

To avoid any such logic errors causing out of bounds memory accesses,
this commit factors out all accesses to the per-host bulk flow counters
to a series of helpers that perform bounds-checking before any
increments and decrements. This also has the benefit of improving
readability by moving the conditional checks for the flow mode into
these helpers, instead of having them spread out throughout the
code (which was the cause of the original logic error).

As part of this change, the flow quantum calculation is consolidated
into a helper function, which means that the dithering applied to the
ost load scaling is now applied both in the DRR rotation and when a
sparse flow's quantum is first initiated. The only user-visible effect
of this is that the maximum packet size that can be sent while a flow
stays sparse will now vary with +/- one byte in some cases. This should
not make a noticeable difference in practice, and thus it's not worth
complicating the code to preserve the old behaviour.
CVSS Score: 7.1 (HIGH)
CWE: CWE-125
References: https://git.kernel.org/stable/c/27202e2e8721c3b23831563c36ed5ac7818641ba; https://git.kernel.org/stable/c/44fe1efb4961c1a5ccab16bb579dfc6b308ad58b; https://git.kernel.org/stable/c/737d4d91d35b5f7fa5bb[PII_REDACTED]77318b0bfd
CVE: CVE-2025-21648
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

netfilter: conntrack: clamp maximum hashtable size to INT_MAX

Use INT_MAX as maximum size for the conntrack hashtable. Otherwise, it
is possible to hit WARN_ON_ONCE in __kvmalloc_node_noprof() when
resizing hashtable because __GFP_NOWARN is unset. See:

  0708a0afe291 ("mm: Consider __GFP_NOWARN flag for oversized kvmalloc() calls")

Note: hashtable resize is only possible from init_netns.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/5552b4fd44be3393b930434a7845d8d95a2a3c33; https://git.kernel.org/stable/c/a965f7f0ea3ae61b9165bed619d5d6da02c75f80; https://git.kernel.org/stable/c/b1b2353d768f1b80cd7fe045a70adee576b9b338
CVE: CVE-2025-21650
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: fixed hclge_fetch_pf_reg accesses bar space out of bounds issue

The TQP BAR space is divided into two segments. TQPs 0-1023 and TQPs
1024-1279 are in different BAR space addresses. However,
hclge_fetch_pf_reg does not distinguish the tqp space information when
reading the tqp space information. When the number of TQPs is greater
than 1024, access bar space overwriting occurs.
The problem of different segments has been considered during the
initialization of tqp.io_base. Therefore, tqp.io_base is directly used
when the queue is read in hclge_fetch_pf_reg.

The error message:

Unable to handle kernel paging request at virtual address ffff[PII_REDACTED]00
pc : hclge_fetch_pf_reg+0x138/0x250 [hclge]
lr : hclge_get_regs+0x84/0x1d0 [hclge]
Call trace:
 hclge_fetch_pf_reg+0x138/0x250 [hclge]
 hclge_get_regs+0x84/0x1d0 [hclge]
 hns3_get_regs+0x2c/0x50 [hns3]
 ethtool_get_regs+0xf4/0x270
 dev_ethtool+0x674/0x8a0
 dev_ioctl+0x270/0x36c
 sock_do_ioctl+0x110/0x2a0
 sock_ioctl+0x2ac/0x530
 __arm64_sys_ioctl+0xa8/0x100
 invoke_syscall+0x4c/0x124
 el0_svc_common.constprop.0+0x140/0x15c
 do_el0_svc+0x30/0xd0
 el0_svc+0x1c/0x2c
 el0_sync_handler+0xb0/0xb4
 el0_sync+0x168/0x180
CVSS Score: 7.8 (HIGH)
CWE: CWE-787, CWE-787
References: https://git.kernel.org/stable/c/0575baa733fc4219f230aef22d5bc35d922f1e9a; https://git.kernel.org/stable/c/7997ddd46c54408bcba5e37fe18b4d832e45d4d4
CVE: CVE-2025-21651
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

net: hns3: don't auto enable misc vector

Currently, there is a time window between misc irq enabled
and service task inited. If an interrupte is reported at
this time, it will cause warning like below:

[   16.324639] Call trace:
[   16.324641]  __queue_delayed_work+0xb8/0xe0
[   16.324643]  mod_delayed_work_on+0x78/0xd0
[   16.324655]  hclge_errhand_task_schedule+0x58/0x90 [hclge]
[   16.324662]  hclge_misc_irq_handle+0x168/0x240 [hclge]
[   16.324666]  __handle_irq_event_percpu+0x64/0x1e0
[   16.324667]  handle_irq_event+0x80/0x170
[   16.324670]  handle_fasteoi_edge_irq+0x110/0x2bc
[   16.324671]  __handle_domain_irq+0x84/0xfc
[   16.324673]  gic_handle_irq+0x88/0x2c0
[   16.324674]  el1_irq+0xb8/0x140
[   16.324677]  arch_cpu_idle+0x18/0x40
[   16.324679]  default_idle_call+0x5c/0x1bc
[   16.324682]  cpuidle_idle_call+0x18c/0x1c4
[   16.324684]  do_idle+0x174/0x17c
[   16.324685]  cpu_startup_entry+0x30/0x6c
[   16.324687]  secondary_start_kernel+0x1a4/0x280
[   16.324688] ---[ end trace 6aa0bff672a964aa ]---

So don't auto enable misc vector when request irq..
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362
References: https://git.kernel.org/stable/c/98b1e3b27734139c76295754b6c317aa4df6d32e; https://git.kernel.org/stable/c/bcf430d3bb5525fc89a92a0c451c725ba1aa4306
CVE: CVE-2025-21653
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

net_sched: cls_flow: validate TCA_FLOW_RSHIFT attribute

syzbot found that TCA_FLOW_RSHIFT attribute was not validated.
Right shitfing a 32bit integer is undefined for large shift values.

UBSAN: shift-out-of-bounds in net/sched/cls_flow.c:329:23
shift exponent 9445 is too large for 32-bit type 'u32' (aka 'unsigned int')
CPU: 1 UID: 0 PID: 54 Comm: kworker/u8:3 Not tainted 6.13.0-rc3-syzkaller-00180-g4f619d518db9 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: ipv6_addrconf addrconf_dad_work
Call Trace:
 <TASK>
  __dump_stack lib/dump_stack.c:94 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
  ubsan_epilogue lib/ubsan.c:231 [inline]
  __ubsan_handle_shift_out_of_bounds+0x3c8/0x420 lib/ubsan.c:468
  flow_classify+0x24d5/0x25b0 net/sched/cls_flow.c:329
  tc_classify include/net/tc_wrapper.h:197 [inline]
  __tcf_classify net/sched/cls_api.c:1771 [inline]
  tcf_classify+0x420/0x1160 net/sched/cls_api.c:1867
  sfb_classify net/sched/sch_sfb.c:260 [inline]
  sfb_enqueue+0x3ad/0x18b0 net/sched/sch_sfb.c:318
  dev_qdisc_enqueue+0x4b/0x290 net/core/dev.c:3793
  __dev_xmit_skb net/core/dev.c:3889 [inline]
  __dev_queue_xmit+0xf0e/0x3f50 net/core/dev.c:4400
  dev_queue_xmit include/linux/netdevice.h:3168 [inline]
  neigh_hh_output include/net/neighbour.h:523 [inline]
  neigh_output include/net/neighbour.h:537 [inline]
  ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236
  iptunnel_xmit+0x55d/0x9b0 net/ipv4/ip_tunnel_core.c:82
  udp_tunnel_xmit_skb+0x262/0x3b0 net/ipv4/udp_tunnel_core.c:173
  geneve_xmit_skb drivers/net/geneve.c:916 [inline]
  geneve_xmit+0x21dc/0x2d00 drivers/net/geneve.c:1039
  __netdev_start_xmit include/linux/netdevice.h:5002 [inline]
  netdev_start_xmit include/linux/netdevice.h:5011 [inline]
  xmit_one net/core/dev.c:3590 [inline]
  dev_hard_start_xmit+0x27a/0x7d0 net/core/dev.c:3606
  __dev_queue_xmit+0x1b73/0x3f50 net/core/dev.c:4434
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/2011749ca[PII_REDACTED]4dfc7e0fde53ebee96f3c; https://git.kernel.org/stable/c/43658e4a5f2770ad94e93362885ff51c10cf3179; https://git.kernel.org/stable/c/6fde663f[PII_REDACTED]645ee602a[PII_REDACTED]42f
CVE: CVE-2025-21654
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

ovl: support encoding fid from inode with no alias

Dmitry Safonov reported that a WARN_ON() assertion can be trigered by
userspace when calling inotify_show_fdinfo() for an overlayfs watched
inode, whose dentry aliases were discarded with drop_caches.

The WARN_ON() assertion in inotify_show_fdinfo() was removed, because
it is possible for encoding file handle to fail for other reason, but
the impact of failing to encode an overlayfs file handle goes beyond
this assertion.

As shown in the LTP test case mentioned in the link below, failure to
encode an overlayfs file handle from a non-aliased inode also leads to
failure to report an fid with FAN_DELETE_SELF fanotify events.

As Dmitry notes in his analyzis of the problem, ovl_encode_fh() fails
if it cannot find an alias for the inode, but this failure can be fixed.
ovl_encode_fh() seldom uses the alias and in the case of non-decodable
file handles, as is often the case with fanotify fid info,
ovl_encode_fh() never needs to use the alias to encode a file handle.

Defer finding an alias until it is actually needed so ovl_encode_fh()
will not fail in the common case of FAN_DELETE_SELF fanotify events.
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-617
References: https://git.kernel.org/stable/c/3c7c90274ae339e1ad443c9be1c67a20b80b9c76; https://git.kernel.org/stable/c/c45beebfde34aa71afbc48b2c54cdda623515037; https://git.kernel.org/stable/c/f0c0ac84de17c37e6e84da65fb920f91dada55ad
CVE: CVE-2024-57904
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: at91: call input_free_device() on allocated iio_dev

Current implementation of at91_ts_register() calls input_free_deivce()
on st->ts_input, however, the err label can be reached before the
allocated iio_dev is stored to st->ts_input. Thus call
input_free_device() on input instead of st->ts_input.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/028a1ba8e3bae593d701aee4f690ce7c195b67d6; https://git.kernel.org/stable/c/09e067e3c83e0695d338e8a26916e3c2bc44be02; https://git.kernel.org/stable/c/25ef52f1c15db67d890b80203a911b9a57b0bf71
CVE: CVE-2024-57905
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: ti-ads1119: fix information leak in triggered buffer

The 'scan' local struct is used to push data to user space from a
triggered buffer, but it has a hole between the sample (unsigned int)
and the timestamp. This hole is never initialized.

Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/2f1687cca911a2f294313c762e0646cd9e7be8cc; https://git.kernel.org/stable/c/75f339d3ecd38cb1ce05357d647189d4a7f7ed08
CVE: CVE-2024-57906
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: ti-ads8688: fix information leak in triggered buffer

The 'buffer' local array is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.

Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/1c80a0985a9a14f33dbf63cd703ca010f094f878; https://git.kernel.org/stable/c/2a7377ccfd940cd6e9201756aff1e7852c266e69; https://git.kernel.org/stable/c/3bf8d1e87939b8a19c9b738564fddf5b73322f2f
CVE: CVE-2024-57907
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: adc: rockchip_saradc: fix information leak in triggered buffer

The 'data' local struct is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.

Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/[PII_REDACTED]4e1e3b278b4053f102b49ea06ee17c; https://git.kernel.org/stable/c/5a95fbbecec7a34bbad5dcc3156700b8711d53c4; https://git.kernel.org/stable/c/64b79afdca7b27a768c7d3716b7f4deb1d6b955c
CVE: CVE-2024-57908
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: imu: kmx61: fix information leak in triggered buffer

The 'buffer' local array is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.

Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/0871eb8d700b33dd7fa86c80630d62ddaef58c2c; https://git.kernel.org/stable/c/565814cbbaa674d[PII_REDACTED]801de49a611e59d; https://git.kernel.org/stable/c/6985ba4467e4b15b809043fa7740d1fb23a1897b
CVE: CVE-2024-57909
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: light: bh1745: fix information leak in triggered buffer

The 'scan' local struct is used to push data to user space from a
triggered buffer, but it does not set values for inactive channels, as
it only uses iio_for_each_active_channel() to assign new values.

Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/1cca2a666e099aa018e5ab385f0a6e01a3053629; https://git.kernel.org/stable/c/b62fbe3b8eedd3cf3c9ad0b7cb9f72c3f40815f0
CVE: CVE-2024-57910
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: light: vcnl4035: fix information leak in triggered buffer

The 'buffer' local array is used to push data to userspace from a
triggered buffer, but it does not set an initial value for the single
data element, which is an u16 aligned to 8 bytes. That leaves at least
4 bytes uninitialized even after writing an integer value with
regmap_read().

Initialize the array to zero before using it to avoid pushing
uninitialized information to userspace.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/13e56229fc81051a42731046e200493c4a7c28ff; https://git.kernel.org/stable/c/47b43e53c0a0edf5578d5d12f5fc71c019649279; https://git.kernel.org/stable/c/47d245be86492974db3aeb[PII_REDACTED]67f56518
CVE: CVE-2024-57911
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: dummy: iio_simply_dummy_buffer: fix information leak in triggered buffer

The 'data' array is allocated via kmalloc() and it is used to push data
to user space from a triggered buffer, but it does not set values for
inactive channels, as it only uses iio_for_each_active_channel()
to assign new values.

Use kzalloc for the memory allocation to avoid pushing uninitialized
information to userspace.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/[PII_REDACTED]88a632c5d6f93e47c41760fa627f77; https://git.kernel.org/stable/c/03fa47621bf8fcbf5994c[PII_REDACTED]853f9af3d; https://git.kernel.org/stable/c/333be433ee908a53f283beb95585dfc14c8ffb46
CVE: CVE-2024-57912
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

iio: pressure: zpa2326: fix information leak in triggered buffer

The 'sample' local struct is used to push data to user space from a
triggered buffer, but it has a hole between the temperature and the
timestamp (u32 pressure, u16 temperature, GAP, u64 timestamp).
This hole is never initialized.

Initialize the struct to zero before using it to avoid pushing
uninitialized information to userspace.
CVSS Score: 7.1 (HIGH)
CWE: CWE-908, CWE-908
References: https://git.kernel.org/stable/c/6007d10c5262f6f71479627c1216899ea7f09073; https://git.kernel.org/stable/c/64a989aa7475b8e76e69b9ec86819ea293e53bab; https://git.kernel.org/stable/c/9629ff1a86823269b12fb1ba9ca4efa945906287
CVE: CVE-2024-57913
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

usb: gadget: f_fs: Remove WARN_ON in functionfs_bind

This commit addresses an issue related to below kernel panic where
panic_on_warn is enabled. It is caused by the unnecessary use of WARN_ON
in functionsfs_bind, which easily leads to the following scenarios.

1.adb_write in adbd               2. UDC write via configfs
  =================	             =====================

->usb_ffs_open_thread()           ->UDC write
 ->open_functionfs()               ->configfs_write_iter()
  ->adb_open()                      ->gadget_dev_desc_UDC_store()
   ->adb_write()                     ->usb_gadget_register_driver_owner
                                      ->driver_register()
->StartMonitor()                       ->bus_add_driver()
 ->adb_read()                           ->gadget_bind_driver()
<times-out without BIND event>           ->configfs_composite_bind()
                                          ->usb_add_function()
->open_functionfs()                        ->ffs_func_bind()
 ->adb_open()                               ->functionfs_bind()
                                       <ffs->state !=FFS_ACTIVE>

The adb_open, adb_read, and adb_write operations are invoked from the
daemon, but trying to bind the function is a process that is invoked by
UDC write through configfs, which opens up the possibility of a race
condition between the two paths. In this race scenario, the kernel panic
occurs due to the WARN_ON from functionfs_bind when panic_on_warn is
enabled. This commit fixes the kernel panic by removing the unnecessary
WARN_ON.

Kernel panic - not syncing: kernel: panic_on_warn set ...
[   14.542395] Call trace:
[   14.542464]  ffs_func_bind+0x1c8/0x14a8
[   14.542468]  usb_add_function+0xcc/0x1f0
[   14.542473]  configfs_composite_bind+0x468/0x588
[   14.542478]  gadget_bind_driver+0x108/0x27c
[   14.542483]  really_probe+0x190/0x374
[   14.542488]  __driver_probe_device+0xa0/0x12c
[   14.542492]  driver_probe_device+0x3c/0x220
[   14.542498]  __driver_attach+0x11c/0x1fc
[   14.542502]  bus_for_each_dev+0x104/0x160
[   14.542506]  driver_attach+0x24/0x34
[   14.542510]  bus_add_driver+0x154/0x270
[   14.542514]  driver_register+0x68/0x104
[   14.542518]  usb_gadget_register_driver_owner+0x48/0xf4
[   14.542523]  gadget_dev_desc_UDC_store+0xf8/0x144
[   14.542526]  configfs_write_iter+0xf0/0x138
CVSS Score: 4.7 (MEDIUM)
CWE: CWE-362, CWE-362
References: https://git.kernel.org/stable/c/19fc1c83454ca9d5699e39633ec79ce26355251c; https://git.kernel.org/stable/c/3e4d32cc145955d5c56c5498a3ff057e4aafa9d1; https://git.kernel.org/stable/c/82f60f3600aecd9ffcd0fbc4e193694511c85b47
CVE: CVE-2024-57915
Published: 2025-01-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-57916
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

misc: microchip: pci1xxxx: Resolve kernel panic during GPIO IRQ handling

Resolve kernel panic caused by improper handling of IRQs while
accessing GPIO values. This is done by replacing generic_handle_irq with
handle_nested_irq.
CVSS Score: 5.5 (MEDIUM)
References: https://git.kernel.org/stable/c/194f9f94a5169547d682e9bbcc5ae6d18a564735; https://git.kernel.org/stable/c/25692750c0259c5b65afec467d97201a485e8a00; https://git.kernel.org/stable/c/47d3749ec0cb56b7b98917c190a8c10cb54216fd
CVE: CVE-2024-57917
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

topology: Keep the cpumask unchanged when printing cpumap

During fuzz testing, the following warning was discovered:

 different return values (15 and 11) from vsnprintf("%*pbl
 ", ...)

 test:keyward is WARNING in kvasprintf
 WARNING: CPU: 55 PID: 1168477 at lib/kasprintf.c:30 kvasprintf+0x121/0x130
 Call Trace:
  kvasprintf+0x121/0x130
  kasprintf+0xa6/0xe0
  bitmap_print_to_buf+0x89/0x100
  core_siblings_list_read+0x7e/0xb0
  kernfs_file_read_iter+0x15b/0x270
  new_sync_read+0x153/0x260
  vfs_read+0x215/0x290
  ksys_read+0xb9/0x160
  do_syscall_64+0x56/0x100
  entry_SYSCALL_64_after_hwframe+0x78/0xe2

The call trace shows that kvasprintf() reported this warning during the
printing of core_siblings_list. kvasprintf() has several steps:

 (1) First, calculate the length of the resulting formatted string.

 (2) Allocate a buffer based on the returned length.

 (3) Then, perform the actual string formatting.

 (4) Check whether the lengths of the formatted strings returned in
     steps (1) and (2) are consistent.

If the core_cpumask is modified between steps (1) and (3), the lengths
obtained in these two steps may not match. Indeed our test includes cpu
hotplugging, which should modify core_cpumask while printing.

To fix this issue, cache the cpumask into a temporary variable before
calling cpumap_print_{list, cpumask}_to_buf(), to keep it unchanged
during the printing process.
CVSS Score: 7.8 (HIGH)
References: https://git.kernel.org/stable/c/1c7818e2746e747838a3de1687e89eac7b947f08; https://git.kernel.org/stable/c/360596e7fe319a5db1b5fb34a3952862ae53c924; https://git.kernel.org/stable/c/b02cf1d27e460ab2b3e1c8c9ce472d562cad2e8d
CVE: CVE-2024-57920
Published: 2025-01-19
Description: Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE: CVE-2024-57921
Published: 2025-01-19
Description: In the Linux kernel, the following vulnerability has been resolved:

drm/amdgpu: Add a lock when accessing the buddy trim function

When running YouTube videos and Steam games simultaneously,
the tester found a system hang / race condition issue with
the multi-display configuration setting. Adding a lock to
the buddy allocator's trim function would be the solution.

<log snip>
[ 7197.250436] general protection fault, probably for non-canonical address 0xdead[PII_REDACTED]08
[ 7197.250447] RIP: 0010:__alloc_range+0x8b/0x340 [amddrm_buddy]
[ 7197.250470] Call Trace:
[ 7197.250472]  <TASK>
[ 7197.250475]  ? show_regs+0x6d/0x80
[ 7197.250481]  ? die_addr+0x37/0xa0
[ 7197.250483]  ? exc_general_protection+0x1db/0x480
[ 7197.250488]  ? drm_suballoc_new+0x13c/0x93d [drm_suballoc_helper]
[ 7197.250493]  ? asm_exc_general_protection+0x27/0x30
[ 7197.250498]  ? __alloc_range+0x8b/0x340 [amddrm_buddy]
[ 7197.250501]  ? __alloc_range+0x109/0x340 [amddrm_buddy]
[ 7197.250506]  amddrm_buddy_block_trim+0x1b5/0x260 [amddrm_buddy]
[ 7197.250511]  amdgpu_vram_mgr_new+0x4f5/0x590 [amdgpu]
[ 7197.250682]  amdttm_resource_alloc+0x46/0xb0 [amdttm]
[ 7197.250689]  ttm_bo_alloc_resource+0xe4/0x370 [amdttm]
[ 7197.250696]  amdttm_bo_validate+0x9d/0x180 [amdttm]
[ 7197.250701]  amdgpu_bo_pin+0x15a/0x2f0 [amdgpu]
[ 7197.250831]  amdgpu_dm_plane_helper_prepare_fb+0xb2/0x360 [amdgpu]
[ 7197.251025]  ? try_wait_for_completion+0x59/0x70
[ 7197.251030]  drm_atomic_helper_prepare_planes.part.0+0x2f/0x1e0
[ 7197.251035]  drm_atomic_helper_prepare_planes+0x5d/0x70
[ 7197.251037]  drm_atomic_helper_commit+0x84/0x160
[ 7197.251040]  drm_atomic_nonblocking_commit+0x59/0x70
[ 7197.251043]  drm_mode_atomic_ioctl+0x720/0x850
[ 7197.251047]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[ 7197.251049]  drm_ioctl_kernel+0xb9/0x120
[ 7197.251053]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 7197.251056]  drm_ioctl+0x2d4/0x550
[ 7197.251058]  ? __pfx_drm_mode_atomic_ioctl+0x10/0x10
[ 7197.251063]  amdgpu_drm_ioctl+0x4e/0x90 [amdgpu]
[ 7197.251186]  __x64_sys_ioctl+0xa0/0xf0
[ 7197.251190]  x64_sys_call+0x143b/0x25c0
[ 7197.251193]  do_syscall_64+0x7f/0x180
[ 7197.251197]  ? srso_alias_return_thunk+0x5/0xfbef5
[ 7197.251199]  ? amdgpu_display_user_framebuffer_create+0x215/0x320 [amdgpu]
[ 7197.251329]  ? drm_internal_framebuffer_create+0xb7/0x1a0
[ 7197.251332]  ? srso_alias_return_thunk+0x5/0xfbef5

(cherry picked from commit 3318ba94e56b9183d0304577c74b33b6b01ce516)
CVSS Score: 5.5 (MEDIUM)
CWE: CWE-667
References: https://git.kernel.org/stable/c/758e3c3054b65336cf0c5f240221f63b4fb98478; https://git.kernel.org/stable/c/75c8b703e5bded1e33b08fb09b829e7c2c1ed50a