{"schema_version":"1.7.2","id":"OESA-2024-2535","modified":"2024-12-13T13:17:57Z","published":"2024-12-13T13:17:57Z","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"],"summary":"kernel security update","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)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2412.2.0.0307.oe2003sp4"}]}],"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"]}}],"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"}],"database_specific":{"severity":"High"}}