GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration

OESA-2024-2535 (CVE-2024-50150)

Vulnerability from osv_openeuler – Published: 2024-12-13 11:08 – Updated: 2026-08-06 11:08 – Source website
VLAI
Summary
kernel security update
Details

The Linux Kernel, the operating system core itself.

Security Fix(es):

In the Linux kernel, the following vulnerability has been resolved: usb: typec: altmode should keep reference to parent The altmode device release refers to its parent device, but without keeping a reference to it. When registering the altmode, get a reference to the parent and put it in the release function. Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this: [ 43.572860] kobject: 'port0.0' (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.573532] kobject: 'port0.1' (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [ 43.574407] kobject: 'port0' (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [ 43.575059] kobject: 'port1.0' (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.575908] kobject: 'port1.1' (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.576908] kobject: 'typec' (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [ 43.577769] kobject: 'port1' (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [ 46.612867] ================================================================== [ 46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [ 46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [ 46.614538] [ 46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [ 46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [ 46.616042] Workqueue: events kobject_delayed_cleanup [ 46.616446] Call Trace: [ 46.616648] <TASK> [ 46.616820] dump_stack_lvl+0x5b/0x7c [ 46.617112] ? typec_altmode_release+0x38/0x129 [ 46.617470] print_report+0x14c/0x49e [ 46.617769] ? rcu_read_unlock_sched+0x56/0x69 [ 46.618117] ? __virt_addr_valid+0x19a/0x1ab [ 46.618456] ? kmem_cache_debug_flags+0xc/0x1d [ 46.618807] ? typec_altmode_release+0x38/0x129 [ 46.619161] kasan_report+0x8d/0xb4 [ 46.619447] ? typec_altmode_release+0x38/0x129 [ 46.619809] ? process_scheduled_works+0x3cb/0x85f [ 46.620185] typec_altmode_release+0x38/0x129 [ 46.620537] ? process_scheduled_works+0x3cb/0x85f [ 46.620907] device_release+0xaf/0xf2 [ 46.621206] kobject_delayed_cleanup+0x13b/0x17a [ 46.621584] process_scheduled_works+0x4f6/0x85f [ 46.621955] ? __pfx_process_scheduled_works+0x10/0x10 [ 46.622353] ? hlock_class+0x31/0x9a [ 46.622647] ? lock_acquired+0x361/0x3c3 [ 46.622956] ? move_linked_works+0x46/0x7d [ 46.623277] worker_thread+0x1ce/0x291 [ 46.623582] ? __kthread_parkme+0xc8/0xdf [ 46.623900] ? __pfx_worker_thread+0x10/0x10 [ 46.624236] kthread+0x17e/0x190 [ 46.624501] ? kthread+0xfb/0x190 [ 46.624756] ? __pfx_kthread+0x10/0x10 [ 46.625015] ret_from_fork+0x20/0x40 [ 46.625268] ? __pfx_kthread+0x10/0x10 [ 46.625532] ret_from_fork_asm+0x1a/0x30 [ 46.625805] </TASK> [ 46.625953] [ 46.626056] Allocated by task 678: [ 46.626287] kasan_save_stack+0x24/0x44 [ 46.626555] kasan_save_track+0x14/0x2d [ 46.626811] __kasan_kmalloc+0x3f/0x4d [ 46.627049] __kmalloc_noprof+0x1bf/0x1f0 [ 46.627362] typec_register_port+0x23/0x491 [ 46.627698] cros_typec_probe+0x634/0xbb6 [ 46.628026] platform_probe+0x47/0x8c [ 46.628311] really_probe+0x20a/0x47d [ 46.628605] device_driver_attach+0x39/0x72 [ 46.628940] bind_store+0x87/0xd7 [ 46.629213] kernfs_fop_write_iter+0x1aa/0x218 [ 46.629574] vfs_write+0x1d6/0x29b [ 46.629856] ksys_write+0xcd/0x13b [ 46.630128] do_syscall_64+0xd4/0x139 [ 46.630420] entry_SYSCALL_64_after_hwframe+0x76/0x7e [ 46.630820] [ 46.630946] Freed by task 48: [ 46.631182] kasan_save_stack+0x24/0x44 [ 46.631493] kasan_save_track+0x14/0x2d [ 46.631799] kasan_save_free_info+0x3f/0x4d [ 46.632144] __kasan_slab_free+0x37/0x45 [ 46.632474] ---truncated---(CVE-2024-50150)

In the Linux kernel, the following vulnerability has been resolved: mm/swapfile: skip HugeTLB pages for unuse_vma I got a bad pud error and lost a 1GB HugeTLB when calling swapoff. The problem can be reproduced by the following steps: 1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory. 2. Swapout the above anonymous memory. 3. run swapoff and we will get a bad pud error in kernel message: mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7) We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace. And therefore the HugeTLB pages will never be freed because we lost it from page table. We can skip HugeTLB pages for unuse_vma to fix it.(CVE-2024-50199)

In the Linux kernel, the following vulnerability has been resolved: posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime() If get_clock_desc() succeeds, it calls fget() for the clockid's fd, and get the clk->rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid's fd to make the refcount balance and release the fd related resource. However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the "ts" is not changed after that. pabeni@redhat.com: fixed commit message typo

In the Linux kernel, the following vulnerability has been resolved: USB: serial: io_edgeport: fix use after free in debug printk The "dev_dbg(&urb->dev->dev, ..." which happens after usb_free_urb(urb) is a use after free of the "urb" pointer. Store the "dev" pointer at the start of the function to avoid this issue.(CVE-2024-50267)

In the Linux kernel, the following vulnerability has been resolved: dm cache: fix potential out-of-bounds access on the first resume Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue. Reproduce steps: 1. prepare component devices: dmsetup create cmeta --table "0 8192 linear /dev/sdc 0" dmsetup create cdata --table "0 65536 linear /dev/sdc 8192" dmsetup create corig --table "0 524288 linear /dev/sdc 262144" dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct 2. load a cache table of 512 cache blocks, and deliberately expand the fast device before resuming the cache, making the in-core data structures inadequate. dmsetup create cache --notable dmsetup reload cache --table "0 524288 cache /dev/mapper/cmeta \ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0" dmsetup reload cdata --table "0 131072 linear /dev/sdc 8192" dmsetup resume cdata dmsetup resume cache 3. suspend the cache to write out the in-core dirty bitset and hint array, leading to out-of-bounds access to the dirty bitset at offset 0x40: dmsetup suspend cache KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80 Read of size 8 at addr ffffc90000085040 by task dmsetup/90 (...snip...) The buggy address belongs to the virtual mapping at [ffffc90000085000, ffffc90000087000) created by: cache_ctr+0x176a/0x35f0 (...snip...) Memory state around the buggy address: ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 >ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8 ^ ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 Fix by checking the size change on the first resume.(CVE-2024-50278)

In the Linux kernel, the following vulnerability has been resolved: media: v4l2-tpg: prevent the risk of a division by zero As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero. Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.(CVE-2024-50287)

In the Linux kernel, the following vulnerability has been resolved: HID: core: zero-initialize the report buffer Since the report buffer is used by all kinds of drivers in various ways, let's zero-initialize it during allocation to make sure that it can't be ever used to leak kernel memory via specially-crafted report.(CVE-2024-50302)

In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.(CVE-2024-53104)

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
References
To clipboard 

{
  "affected": [
    {
      "ecosystem_specific": {
        "aarch64": [
          "bpftool-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "bpftool-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "kernel-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "kernel-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "kernel-debugsource-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "kernel-devel-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "kernel-source-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "kernel-tools-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "kernel-tools-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "kernel-tools-devel-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "perf-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "python2-perf-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "python2-perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "python3-perf-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm",
          "python3-perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.aarch64.rpm"
        ],
        "src": [
          "kernel-4.19.90-2412.2.0.0307.oe2003sp4.src.rpm"
        ],
        "x86_64": [
          "bpftool-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "bpftool-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "kernel-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "kernel-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "kernel-debugsource-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "kernel-devel-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "kernel-source-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "kernel-tools-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "kernel-tools-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "kernel-tools-devel-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "perf-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "python2-perf-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "python2-perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "python3-perf-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm",
          "python3-perf-debuginfo-4.19.90-2412.2.0.0307.oe2003sp4.x86_64.rpm"
        ]
      },
      "package": {
        "ecosystem": "openEuler:20.03-LTS-SP4",
        "name": "kernel",
        "purl": "pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.19.90-2412.2.0.0307.oe2003sp4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "database_specific": {
    "severity": "High"
  },
  "details": "The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  usb: typec: altmode should keep reference to parent  The altmode device release refers to its parent device, but without keeping a reference to it.  When registering the altmode, get a reference to the parent and put it in the release function.  Before this fix, when using CONFIG_DEBUG_KOBJECT_RELEASE, we see issues like this:  [   43.572860] kobject: \u0026apos;port0.0\u0026apos; (ffff8880057ba008): kobject_release, parent 0000000000000000 (delayed 3000) [   43.573532] kobject: \u0026apos;port0.1\u0026apos; (ffff8880057bd008): kobject_release, parent 0000000000000000 (delayed 1000) [   43.574407] kobject: \u0026apos;port0\u0026apos; (ffff8880057b9008): kobject_release, parent 0000000000000000 (delayed 3000) [   43.575059] kobject: \u0026apos;port1.0\u0026apos; (ffff8880057ca008): kobject_release, parent 0000000000000000 (delayed 4000) [   43.575908] kobject: \u0026apos;port1.1\u0026apos; (ffff8880057c9008): kobject_release, parent 0000000000000000 (delayed 4000) [   43.576908] kobject: \u0026apos;typec\u0026apos; (ffff8880062dbc00): kobject_release, parent 0000000000000000 (delayed 4000) [   43.577769] kobject: \u0026apos;port1\u0026apos; (ffff8880057bf008): kobject_release, parent 0000000000000000 (delayed 3000) [   46.612867] ================================================================== [   46.613402] BUG: KASAN: slab-use-after-free in typec_altmode_release+0x38/0x129 [   46.614003] Read of size 8 at addr ffff8880057b9118 by task kworker/2:1/48 [   46.614538] [   46.614668] CPU: 2 UID: 0 PID: 48 Comm: kworker/2:1 Not tainted 6.12.0-rc1-00138-gedbae730ad31 #535 [   46.615391] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014 [   46.616042] Workqueue: events kobject_delayed_cleanup [   46.616446] Call Trace: [   46.616648]  \u0026lt;TASK\u0026gt; [   46.616820]  dump_stack_lvl+0x5b/0x7c [   46.617112]  ? typec_altmode_release+0x38/0x129 [   46.617470]  print_report+0x14c/0x49e [   46.617769]  ? rcu_read_unlock_sched+0x56/0x69 [   46.618117]  ? __virt_addr_valid+0x19a/0x1ab [   46.618456]  ? kmem_cache_debug_flags+0xc/0x1d [   46.618807]  ? typec_altmode_release+0x38/0x129 [   46.619161]  kasan_report+0x8d/0xb4 [   46.619447]  ? typec_altmode_release+0x38/0x129 [   46.619809]  ? process_scheduled_works+0x3cb/0x85f [   46.620185]  typec_altmode_release+0x38/0x129 [   46.620537]  ? process_scheduled_works+0x3cb/0x85f [   46.620907]  device_release+0xaf/0xf2 [   46.621206]  kobject_delayed_cleanup+0x13b/0x17a [   46.621584]  process_scheduled_works+0x4f6/0x85f [   46.621955]  ? __pfx_process_scheduled_works+0x10/0x10 [   46.622353]  ? hlock_class+0x31/0x9a [   46.622647]  ? lock_acquired+0x361/0x3c3 [   46.622956]  ? move_linked_works+0x46/0x7d [   46.623277]  worker_thread+0x1ce/0x291 [   46.623582]  ? __kthread_parkme+0xc8/0xdf [   46.623900]  ? __pfx_worker_thread+0x10/0x10 [   46.624236]  kthread+0x17e/0x190 [   46.624501]  ? kthread+0xfb/0x190 [   46.624756]  ? __pfx_kthread+0x10/0x10 [   46.625015]  ret_from_fork+0x20/0x40 [   46.625268]  ? __pfx_kthread+0x10/0x10 [   46.625532]  ret_from_fork_asm+0x1a/0x30 [   46.625805]  \u0026lt;/TASK\u0026gt; [   46.625953] [   46.626056] Allocated by task 678: [   46.626287]  kasan_save_stack+0x24/0x44 [   46.626555]  kasan_save_track+0x14/0x2d [   46.626811]  __kasan_kmalloc+0x3f/0x4d [   46.627049]  __kmalloc_noprof+0x1bf/0x1f0 [   46.627362]  typec_register_port+0x23/0x491 [   46.627698]  cros_typec_probe+0x634/0xbb6 [   46.628026]  platform_probe+0x47/0x8c [   46.628311]  really_probe+0x20a/0x47d [   46.628605]  device_driver_attach+0x39/0x72 [   46.628940]  bind_store+0x87/0xd7 [   46.629213]  kernfs_fop_write_iter+0x1aa/0x218 [   46.629574]  vfs_write+0x1d6/0x29b [   46.629856]  ksys_write+0xcd/0x13b [   46.630128]  do_syscall_64+0xd4/0x139 [   46.630420]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [   46.630820] [   46.630946] Freed by task 48: [   46.631182]  kasan_save_stack+0x24/0x44 [   46.631493]  kasan_save_track+0x14/0x2d [   46.631799]  kasan_save_free_info+0x3f/0x4d [   46.632144]  __kasan_slab_free+0x37/0x45 [   46.632474] ---truncated---(CVE-2024-50150)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mm/swapfile: skip HugeTLB pages for unuse_vma  I got a bad pud error and lost a 1GB HugeTLB when calling swapoff.  The problem can be reproduced by the following steps:   1. Allocate an anonymous 1GB HugeTLB and some other anonymous memory.  2. Swapout the above anonymous memory.  3. run swapoff and we will get a bad pud error in kernel message:    mm/pgtable-generic.c:42: bad pud 00000000743d215d(84000001400000e7)  We can tell that pud_clear_bad is called by pud_none_or_clear_bad in unuse_pud_range() by ftrace.  And therefore the HugeTLB pages will never be freed because we lost it from page table.  We can skip HugeTLB pages for unuse_vma to fix it.(CVE-2024-50199)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  posix-clock: posix-clock: Fix unbalanced locking in pc_clock_settime()  If get_clock_desc() succeeds, it calls fget() for the clockid\u0026apos;s fd, and get the clk-\u0026gt;rwsem read lock, so the error path should release the lock to make the lock balance and fput the clockid\u0026apos;s fd to make the refcount balance and release the fd related resource.  However the below commit left the error path locked behind resulting in unbalanced locking. Check timespec64_valid_strict() before get_clock_desc() to fix it, because the \u0026quot;ts\u0026quot; is not changed after that.  [pabeni@redhat.com: fixed commit message typo](CVE-2024-50210)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  USB: serial: io_edgeport: fix use after free in debug printk  The \u0026quot;dev_dbg(\u0026amp;urb-\u0026gt;dev-\u0026gt;dev, ...\u0026quot; which happens after usb_free_urb(urb) is a use after free of the \u0026quot;urb\u0026quot; pointer.  Store the \u0026quot;dev\u0026quot; pointer at the start of the function to avoid this issue.(CVE-2024-50267)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  dm cache: fix potential out-of-bounds access on the first resume  Out-of-bounds access occurs if the fast device is expanded unexpectedly before the first-time resume of the cache table. This happens because expanding the fast device requires reloading the cache table for cache_create to allocate new in-core data structures that fit the new size, and the check in cache_preresume is not performed during the first resume, leading to the issue.  Reproduce steps:  1. prepare component devices:  dmsetup create cmeta --table \u0026quot;0 8192 linear /dev/sdc 0\u0026quot; dmsetup create cdata --table \u0026quot;0 65536 linear /dev/sdc 8192\u0026quot; dmsetup create corig --table \u0026quot;0 524288 linear /dev/sdc 262144\u0026quot; dd if=/dev/zero of=/dev/mapper/cmeta bs=4k count=1 oflag=direct  2. load a cache table of 512 cache blocks, and deliberately expand the    fast device before resuming the cache, making the in-core data    structures inadequate.  dmsetup create cache --notable dmsetup reload cache --table \u0026quot;0 524288 cache /dev/mapper/cmeta \\ /dev/mapper/cdata /dev/mapper/corig 128 2 metadata2 writethrough smq 0\u0026quot; dmsetup reload cdata --table \u0026quot;0 131072 linear /dev/sdc 8192\u0026quot; dmsetup resume cdata dmsetup resume cache  3. suspend the cache to write out the in-core dirty bitset and hint    array, leading to out-of-bounds access to the dirty bitset at offset    0x40:  dmsetup suspend cache  KASAN reports:    BUG: KASAN: vmalloc-out-of-bounds in is_dirty_callback+0x2b/0x80   Read of size 8 at addr ffffc90000085040 by task dmsetup/90    (...snip...)   The buggy address belongs to the virtual mapping at    [ffffc90000085000, ffffc90000087000) created by:    cache_ctr+0x176a/0x35f0    (...snip...)   Memory state around the buggy address:    ffffc90000084f00: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8    ffffc90000084f80: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8   \u0026gt;ffffc90000085000: 00 00 00 00 00 00 00 00 f8 f8 f8 f8 f8 f8 f8 f8                                              ^    ffffc90000085080: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8    ffffc90000085100: f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8 f8  Fix by checking the size change on the first resume.(CVE-2024-50278)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: v4l2-tpg: prevent the risk of a division by zero  As reported by Coverity, the logic at tpg_precalculate_line() blindly rescales the buffer even when scaled_witdh is equal to zero. If this ever happens, this will cause a division by zero.  Instead, add a WARN_ON_ONCE() to trigger such cases and return without doing any precalculation.(CVE-2024-50287)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  HID: core: zero-initialize the report buffer  Since the report buffer is used by all kinds of drivers in various ways, let\u0026apos;s zero-initialize it during allocation to make sure that it can\u0026apos;t be ever used to leak kernel memory via specially-crafted report.(CVE-2024-50302)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: uvcvideo: Skip parsing frames of type UVC_VS_UNDEFINED in uvc_parse_format  This can lead to out of bounds writes since frames of this type were not taken into account when calculating the size of the frames buffer in uvc_parse_streaming.(CVE-2024-53104)",
  "id": "OESA-2024-2535",
  "modified": "2026-08-06T11:08:01Z",
  "published": "2024-12-13T11:08:01Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2535"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50150"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50199"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50210"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50267"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50278"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50287"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-50302"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-53104"
    }
  ],
  "schema_version": "1.7.2",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "kernel security update",
  "upstream": [
    "CVE-2024-50150",
    "CVE-2024-50199",
    "CVE-2024-50210",
    "CVE-2024-50267",
    "CVE-2024-50278",
    "CVE-2024-50287",
    "CVE-2024-50302",
    "CVE-2024-53104"
  ]
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.


Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.