{"schema_version":"1.7.2","id":"OESA-2024-2370","modified":"2024-11-08T15:10:15Z","published":"2024-11-08T15:10:15Z","upstream":["CVE-2022-48948","CVE-2022-48949","CVE-2022-48960","CVE-2022-48962","CVE-2022-48966","CVE-2022-48971","CVE-2022-48972","CVE-2022-48978","CVE-2022-48992","CVE-2022-49002","CVE-2022-49005","CVE-2022-49011","CVE-2022-49020","CVE-2022-49021","CVE-2022-49031","CVE-2022-49032","CVE-2024-47659","CVE-2024-47669","CVE-2024-47696","CVE-2024-47697","CVE-2024-47701","CVE-2024-47742","CVE-2024-49860","CVE-2024-49877","CVE-2024-49878","CVE-2024-49881","CVE-2024-49882","CVE-2024-49883","CVE-2024-49884","CVE-2024-49889","CVE-2024-49924","CVE-2024-49936","CVE-2024-49950","CVE-2024-49981","CVE-2024-49991","CVE-2024-49995","CVE-2024-50033","CVE-2024-50035","CVE-2024-50058","CVE-2024-50073"],"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: gadget: uvc: Prevent buffer overflow in setup handler  Setup function uvc_function_setup permits control transfer requests with up to 64 bytes of payload (UVC_MAX_REQUEST_SIZE), data stage handler for OUT transfer uses memcpy to copy req-\u0026gt;actual bytes to uvc_event-\u0026gt;data.data array of size 60. This may result in an overflow of 4 bytes.(CVE-2022-48948)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  igb: Initialize mailbox message for VF reset  When a MAC address is not assigned to the VF, that portion of the message sent to the VF is not set. The memory, however, is allocated from the stack meaning that information may be leaked to the VM. Initialize the message buffer to 0 so that no information is passed to the VM in this case.(CVE-2022-48949)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: hisilicon: Fix potential use-after-free in hix5hd2_rx()  The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: hisilicon: Fix potential use-after-free in hisi_femac_rx()  The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48962)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: mvneta: Prevent out of bounds read in mvneta_config_rss()  The pp-\u0026gt;indir[0] value comes from the user.  It is passed to:   if (cpu_online(pp-\u0026gt;rxq_def))  inside the mvneta_percpu_elect() function.  It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap.(CVE-2022-48966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Fix not cleanup led when bt_init fails  bt_init() calls bt_leds_init() to register led, but if it fails later, bt_leds_cleanup() is not called to unregister it.  This can cause panic if the argument \u0026quot;bluetooth-power\u0026quot; in text is freed and then another led_trigger_register() tries to access it:  BUG: unable to handle page fault for address: ffffffffc06d3bc0 RIP: 0010:strcmp+0xc/0x30   Call Trace:     \u0026lt;TASK\u0026gt;     led_trigger_register+0x10d/0x4f0     led_trigger_register_simple+0x7d/0x100     bt_init+0x39/0xf7 [bluetooth]     do_one_initcall+0xd0/0x4e0(CVE-2022-48971)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()  Kernel fault injection test reports null-ptr-deref as follows:  BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Call Trace:  \u0026lt;TASK\u0026gt;  raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87  call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944  unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982  unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879  register_netdevice+0x9a8/0xb90 net/core/dev.c:10083  ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659  ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229  mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316  ieee802154_if_add() allocates wpan_dev as netdev\u0026apos;s private data, but not init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage the list when device register/unregister, and may lead to null-ptr-deref.  Use INIT_LIST_HEAD() on it to initialize it correctly.(CVE-2022-48972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  HID: core: fix shift-out-of-bounds in hid_report_raw_event  Syzbot reported shift-out-of-bounds in hid_report_raw_event.  microsoft 0003:045E:07DA.0001: hid_field_extract() called with n (128) \u0026gt; 32! (swapper/0) ====================================================================== UBSAN: shift-out-of-bounds in drivers/hid/hid-core.c:1323:20 shift exponent 127 is too large for 32-bit type \u0026apos;int\u0026apos; CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rc4-syzkaller-00159-g4bbf3422df78 #0 Hardware name: Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace:  \u0026lt;IRQ\u0026gt;  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x1e3/0x2cb lib/dump_stack.c:106  ubsan_epilogue lib/ubsan.c:151 [inline]  __ubsan_handle_shift_out_of_bounds+0x3a6/0x420 lib/ubsan.c:322  snto32 drivers/hid/hid-core.c:1323 [inline]  hid_input_fetch_field drivers/hid/hid-core.c:1572 [inline]  hid_process_report drivers/hid/hid-core.c:1665 [inline]  hid_report_raw_event+0xd56/0x18b0 drivers/hid/hid-core.c:1998  hid_input_report+0x408/0x4f0 drivers/hid/hid-core.c:2066  hid_irq_in+0x459/0x690 drivers/hid/usbhid/hid-core.c:284  __usb_hcd_giveback_urb+0x369/0x530 drivers/usb/core/hcd.c:1671  dummy_timer+0x86b/0x3110 drivers/usb/gadget/udc/dummy_hcd.c:1988  call_timer_fn+0xf5/0x210 kernel/time/timer.c:1474  expire_timers kernel/time/timer.c:1519 [inline]  __run_timers+0x76a/0x980 kernel/time/timer.c:1790  run_timer_softirq+0x63/0xf0 kernel/time/timer.c:1803  __do_softirq+0x277/0x75b kernel/softirq.c:571  __irq_exit_rcu+0xec/0x170 kernel/softirq.c:650  irq_exit_rcu+0x5/0x20 kernel/softirq.c:662  sysvec_apic_timer_interrupt+0x91/0xb0 arch/x86/kernel/apic/apic.c:1107 ======================================================================  If the size of the integer (unsigned n) is bigger than 32 in snto32(), shift exponent will be too large for 32-bit type \u0026apos;int\u0026apos;, resulting in a shift-out-of-bounds bug. Fix this by adding a check on the size of the integer (unsigned n) in snto32(). To add support for n greater than 32 bits, set n to 32, if n is greater than 32.(CVE-2022-48978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: soc-pcm: Add NULL check in BE reparenting  Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test.(CVE-2022-48992)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iommu/vt-d: Fix PCI device refcount leak in dmar_dev_scope_init()  for_each_pci_dev() is implemented by pci_get_device(). The comment of pci_get_device() says that it will increase the reference count for the returned pci_dev and also decrease the reference count for the input pci_dev @from if it is not NULL.  If we break for_each_pci_dev() loop with pdev not NULL, we need to call pci_dev_put() to decrease the reference count. Add the missing pci_dev_put() for the error path to avoid reference count leak.(CVE-2022-49002)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: ops: Fix bounds check for _sx controls  For _sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in snd_soc_put_volsw_sx() needs to just check against the maximum value.(CVE-2022-49005)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()  As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it after using to avoid refcount leak.(CVE-2022-49011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/9p: Fix a potential socket leak in p9_socket_open  Both p9_fd_create_tcp() and p9_fd_create_unix() will call p9_socket_open(). If the creation of p9_trans_fd fails, p9_fd_create_tcp() and p9_fd_create_unix() will return an error directly instead of releasing the cscoket, which will result in a socket leak.  This patch adds sock_release() to fix the leak issue.(CVE-2022-49020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: phy: fix null-ptr-deref while probe() failed  I got a null-ptr-deref report as following when doing fault injection test:  BUG: kernel NULL pointer dereference, address: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klist_put+0x2d/0xd0 Call Trace:  \u0026lt;TASK\u0026gt;  klist_remove+0xf1/0x1c0  device_release_driver_internal+0x23e/0x2d0  bus_remove_device+0x1bd/0x240  device_del+0x357/0x770  phy_device_remove+0x11/0x30  mdiobus_unregister+0xa5/0x140  release_nodes+0x6a/0xa0  devres_release_all+0xf8/0x150  device_unbind_cleanup+0x19/0xd0  //probe path: phy_device_register()   device_add()  phy_connect   phy_attach_direct() //set device driver     probe() //it\u0026apos;s failed, driver is not bound     device_bind_driver() // probe failed, it\u0026apos;s not called  //remove path: phy_device_remove()   device_del()     device_release_driver_internal()       __device_release_driver() //dev-\u0026gt;drv is not NULL         klist_remove() \u0026lt;- knode_driver is not added yet, cause null-ptr-deref  In phy_attach_direct(), after setting the \u0026apos;dev-\u0026gt;driver\u0026apos;, probe() fails, device_bind_driver() is not called, so the knode_driver-\u0026gt;n_klist is not set, then it causes null-ptr-deref in __device_release_driver() while deleting device. Fix this by setting dev-\u0026gt;driver to NULL in the error path in phy_attach_direct().(CVE-2022-49021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: health: afe4403: Fix oob read in afe4403_read_raw  KASAN report out-of-bounds read as follows:  BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279  Call Trace:  afe4403_read_raw  iio_read_channel_info  dev_attr_show  The buggy address belongs to the variable:  afe4403_channel_leds+0x18/0xffffffffffffe9e0  This issue can be reproduced by singe command:   $ cat /sys/bus/spi/devices/spi0.0/iio\\:device0/in_intensity6_raw  The array size of afe4403_channel_leds is less than channels, so access with chan-\u0026gt;address cause OOB read in afe4403_read_raw. Fix it by moving access before use it.(CVE-2022-49031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw  KASAN report out-of-bounds read as follows:  BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278  Call Trace:  afe4404_read_raw  iio_read_channel_info  dev_attr_show  The buggy address belongs to the variable:  afe4404_channel_leds+0x18/0xffffffffffffe9c0  This issue can be reproduce by singe command:   $ cat /sys/bus/i2c/devices/0-0058/iio\\:device0/in_intensity6_raw  The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan-\u0026gt;address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them.(CVE-2022-49032)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmack: tcp: ipv4, fix incorrect labeling\r\n\r\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label \u0026apos;foo\u0026apos; connects to a label \u0026apos;bar\u0026apos; with tcp/ipv4,\n\u0026apos;foo\u0026apos; always gets \u0026apos;foo\u0026apos; in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled (\u0026apos;foo\u0026apos; instead of \u0026apos;bar\u0026apos;)\n2) \u0026apos;bar\u0026apos; can write to \u0026apos;foo\u0026apos; without being authorized to write.\r\n\r\nHere is a scenario how to see this:\r\n\r\n* Take two machines, let\u0026apos;s call them C and S,\n   with active Smack in the default state\n   (no settings, no rules, no labeled hosts, only builtin labels)\r\n\r\n* At S, add Smack rule \u0026apos;foo bar w\u0026apos;\n   (labels \u0026apos;foo\u0026apos; and \u0026apos;bar\u0026apos; are instantiated at S at this moment)\r\n\r\n* At S, at label \u0026apos;bar\u0026apos;, launch a program\n   that listens for incoming tcp/ipv4 connections\r\n\r\n* From C, at label \u0026apos;foo\u0026apos;, connect to the listener at S.\n   (label \u0026apos;foo\u0026apos; is instantiated at C at this moment)\n   Connection succeedes and works.\r\n\r\n* Send some data in both directions.\n* Collect network traffic of this connection.\r\n\r\nAll packets in both directions are labeled with the CIPSO\nof the label \u0026apos;foo\u0026apos;. Hence, label \u0026apos;bar\u0026apos; writes to \u0026apos;foo\u0026apos; without\nbeing authorized, and even without ever being known at C.\r\n\r\nIf anybody cares: exactly the same happens with DCCP.\r\n\r\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\r\n\r\nI changed returned packes label into the \u0026apos;bar\u0026apos;,\nto bring it into line with the Smack documentation claims.(CVE-2024-47659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix state management in error path of log writing function\r\n\r\nAfter commit a694291a6211 (\u0026quot;nilfs2: separate wait function from\nnilfs_segctor_write\u0026quot;) was applied, the log writing function\nnilfs_segctor_do_construct() was able to issue I/O requests continuously\neven if user data blocks were split into multiple logs across segments,\nbut two potential flaws were introduced in its error handling.\r\n\r\nFirst, if nilfs_segctor_begin_construction() fails while creating the\nsecond or subsequent logs, the log writing function returns without\ncalling nilfs_segctor_abort_construction(), so the writeback flag set on\npages/folios will remain uncleared.  This causes page cache operations to\nhang waiting for the writeback flag.  For example,\ntruncate_inode_pages_final(), which is called via nilfs_evict_inode() when\nan inode is evicted from memory, will hang.\r\n\r\nSecond, the NILFS_I_COLLECTED flag set on normal inodes remain uncleared. \nAs a result, if the next log write involves checkpoint creation, that\u0026apos;s\nfine, but if a partial log write is performed that does not, inodes with\nNILFS_I_COLLECTED set are erroneously removed from the \u0026quot;sc_dirty_files\u0026quot;\nlist, and their data and b-tree blocks may not be written to the device,\ncorrupting the block mapping.\r\n\r\nFix these issues by uniformly calling nilfs_segctor_abort_construction()\non failure of each step in the loop in nilfs_segctor_do_construct(),\nhaving it clean up logs and segment usages according to progress, and\ncorrecting the conditions for calling nilfs_redirty_inodes() to ensure\nthat the NILFS_I_COLLECTED flag is cleared.(CVE-2024-47669)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency  In the commit aee2424246f9 (\u0026quot;RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\u0026quot;), the function flush_workqueue is invoked to flush the work queue iwcm_wq.  But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.  Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn\u0026apos;t have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn\u0026apos;t have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock.  The call trace is as below:  [  125.350876][ T1430] Call Trace: [  125.356281][ T1430]  \u0026lt;TASK\u0026gt; [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [  125.566487][ T1430]  \u0026lt;/TASK\u0026gt; [  125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drivers: media: dvb-frontends/rtl2830: fix an out-of-bounds write error  Ensure index in rtl2830_pid_filter does not exceed 31 to prevent out-of-bounds access.  dev-\u0026gt;filters is a 32-bit value, so set_bit and clear_bit functions should only operate on indices from 0 to 31. If index is 32, it will attempt to access a non-existent 33rd bit, leading to out-of-bounds access. Change the boundary check from index \u0026gt; 32 to index \u0026gt;= 32 to resolve this issue.(CVE-2024-47697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid OOB when system.data xattr changes underneath the filesystem  When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF.  EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103  CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500  ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697  __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573  ext4_lookup_entry fs/ext4/namei.c:1727 [inline]  ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795  lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633  filename_create+0x297/0x540 fs/namei.c:3980  do_symlinkat+0xf9/0x3a0 fs/namei.c:4587  __do_sys_symlinkat fs/namei.c:4610 [inline]  __se_sys_symlinkat fs/namei.c:4607 [inline]  __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0  \u0026lt;/TASK\u0026gt;  Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Block path traversal  Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such.  However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are:   - lpfc_sli4_request_firmware_update() seems to construct the firmware    filename from \u0026quot;ModelName\u0026quot;, a string that was previously parsed out of    some descriptor (\u0026quot;Vital Product Data\u0026quot;) in lpfc_fill_vpd()  - nfp_net_fw_find() seems to construct a firmware filename from a model    name coming from nfp_hwinfo_lookup(pf-\u0026gt;hwinfo, \u0026quot;nffw.partno\u0026quot;), which I    think parses some descriptor that was read from the device.    (But this case likely isn\u0026apos;t exploitable because the format string looks    like \u0026quot;netronome/nic_%s\u0026quot;, and there shouldn\u0026apos;t be any *folders* starting    with \u0026quot;netronome/nic_\u0026quot;. The previous case was different because there,    the \u0026quot;%s\u0026quot; is *at the start* of the format string.)  - module_flash_fw_schedule() is reachable from the    ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as    GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is    enough to pass the privilege check), and takes a userspace-provided    firmware name.    (But I think to reach this case, you need to have CAP_NET_ADMIN over a    network namespace that a special kind of ethernet device is mapped into,    so I think this is not a viable attack path in practice.)  Fix it by rejecting any firmware names containing \u0026quot;..\u0026quot; path components.  For what it\u0026apos;s worth, I went looking and haven\u0026apos;t found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: sysfs: validate return type of _STR method  Only buffer objects are valid return values of _STR.  If something else is returned description_show() will access invalid memory.(CVE-2024-49860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate  When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.(CVE-2024-49877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  resource: fix region_intersects() vs add_memory_driver_managed()  On a system with CXL memory, the resource tree (/proc/iomem) related to CXL memory may look like something as follows.  490000000-50fffffff : CXL Window 0   490000000-50fffffff : region0     490000000-50fffffff : dax0.0       490000000-50fffffff : System RAM (kmem)  Because drivers/dax/kmem.c calls add_memory_driver_managed() during onlining CXL memory, which makes \u0026quot;System RAM (kmem)\u0026quot; a descendant of \u0026quot;CXL Window X\u0026quot;.  This confuses region_intersects(), which expects all \u0026quot;System RAM\u0026quot; resources to be at the top level of iomem_resource.  This can lead to bugs.  For example, when the following command line is executed to write some memory in CXL memory range via /dev/mem,   $ dd if=data of=/dev/mem bs=$((1 \u0026lt;\u0026lt; 10)) seek=$((0x490000000 \u0026gt;\u0026gt; 10)) count=1  dd: error writing \u0026apos;/dev/mem\u0026apos;: Bad address  1+0 records in  0+0 records out  0 bytes copied, 0.0283507 s, 0.0 kB/s  the command fails as expected.  However, the error code is wrong.  It should be \u0026quot;Operation not permitted\u0026quot; instead of \u0026quot;Bad address\u0026quot;.  More seriously, the /dev/mem permission checking in devmem_is_allowed() passes incorrectly.  Although the accessing is prevented later because ioremap() isn\u0026apos;t allowed to map system RAM, it is a potential security issue.  During command executing, the following warning is reported in the kernel log for calling ioremap() on system RAM.   ioremap on RAM at 0x0000000490000000 - 0x0000000490000fff  WARNING: CPU: 2 PID: 416 at arch/x86/mm/ioremap.c:216 __ioremap_caller.constprop.0+0x131/0x35d  Call Trace:   memremap+0xcb/0x184   xlate_dev_mem_ptr+0x25/0x2f   write_mem+0x94/0xfb   vfs_write+0x128/0x26d   ksys_write+0xac/0xfe   do_syscall_64+0x9a/0xfd   entry_SYSCALL_64_after_hwframe+0x4b/0x53  The details of command execution process are as follows.  In the above resource tree, \u0026quot;System RAM\u0026quot; is a descendant of \u0026quot;CXL Window 0\u0026quot; instead of a top level resource.  So, region_intersects() will report no System RAM resources in the CXL memory region incorrectly, because it only checks the top level resources.  Consequently, devmem_is_allowed() will return 1 (allow access via /dev/mem) for CXL memory region incorrectly.  Fortunately, ioremap() doesn\u0026apos;t allow to map System RAM and reject the access.  So, region_intersects() needs to be fixed to work correctly with the resource tree with \u0026quot;System RAM\u0026quot; not at top level as above.  To fix it, if we found a unmatched resource in the top level, we will continue to search matched resources in its descendant resources.  So, we will not miss any matched resources in resource tree anymore.  In the new implementation, an example resource tree  |------------- \u0026quot;CXL Window 0\u0026quot; ------------| |-- \u0026quot;System RAM\u0026quot; --|  will behave similar as the following fake resource tree for region_intersects(, IORESOURCE_SYSTEM_RAM, ),  |-- \u0026quot;System RAM\u0026quot; --||-- \u0026quot;CXL Window 0a\u0026quot; --|  Where \u0026quot;CXL Window 0a\u0026quot; is part of the original \u0026quot;CXL Window 0\u0026quot; that isn\u0026apos;t covered by \u0026quot;System RAM\u0026quot;.(CVE-2024-49878)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: update orig_path in ext4_find_extent()  In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don\u0026apos;t update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example:  ext4_split_extent   path = *ppath = 2000   ext4_find_extent     if (depth \u0026gt; path[0].p_maxdepth)       kfree(path = 2000);       *orig_path = path = NULL;       path = kcalloc() = 3000   ext4_split_extent_at(*ppath = NULL)     path = *ppath;     ex = path[depth].p_ext;     // NULL pointer dereference!  ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_split_extent.isra.0+0xcb/0x1b0  ext4_ext_convert_to_initialized+0x168/0x6c0  ext4_ext_handle_unwritten_extents+0x325/0x4d0  ext4_ext_map_blocks+0x520/0xdb0  ext4_map_blocks+0x2b0/0x690  ext4_iomap_begin+0x20e/0x2c0 [...] ==================================================================  Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix double brelse() the buffer of the extents path  In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows:    split2    map    split1 |--------|-------|--------|  ext4_ext_map_blocks  ext4_ext_handle_unwritten_extents   ext4_split_convert_extents    // path-\u0026gt;p_depth == 0    ext4_split_extent      // 1. do split1      ext4_split_extent_at        |ext4_ext_insert_extent        |  ext4_ext_create_new_leaf        |    ext4_ext_grow_indepth        |      le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)        |    ext4_find_extent        |      // return -ENOMEM        |// get error and try zeroout        |path = ext4_find_extent        |  path-\u0026gt;p_depth = 1        |ext4_ext_try_to_merge        |  ext4_ext_try_to_merge_up        |    path-\u0026gt;p_depth = 0        |    brelse(path[1].p_bh)  ---\u0026gt; not set to NULL here        |// zeroout success      // 2. update path      ext4_find_extent      // 3. do split2      ext4_split_extent_at        ext4_ext_insert_extent          ext4_ext_create_new_leaf            ext4_ext_grow_indepth              le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)            ext4_find_extent              path[0].p_bh = NULL;              path-\u0026gt;p_depth = 1              read_extent_tree_block  ---\u0026gt; return err              // path[1].p_bh is still the old value              ext4_free_ext_path                ext4_ext_drop_refs                  // path-\u0026gt;p_depth == 1                  brelse(path[1].p_bh)  ---\u0026gt; brelse a buffer twice  Finally got the following WARRNING when removing the buffer from lru:  ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace:  \u0026lt;TASK\u0026gt;  __find_get_block+0x6e7/0x810  bdev_getblk+0x2b/0x480  __ext4_get_inode_loc+0x48a/0x1240  ext4_get_inode_loc+0xb2/0x150  ext4_reserve_inode_write+0xb7/0x230  __ext4_mark_inode_dirty+0x144/0x6a0  ext4_ext_insert_extent+0x9c8/0x3230  ext4_ext_map_blocks+0xf45/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: aovid use-after-free in ext4_ext_insert_extent()  As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we\u0026apos;ll use the stale path and cause UAF. Below is a sample trace with dummy values:  ext4_ext_insert_extent   path = *ppath = 2000   ext4_ext_create_new_leaf(ppath)     ext4_find_extent(ppath)       path = *ppath = 2000       if (depth \u0026gt; path[0].p_maxdepth)             kfree(path = 2000);             *ppath = path = NULL;       path = kcalloc() = 3000       *ppath = 3000;       return path;   /* here path is still 2000, UAF! */   eh = path[depth].p_hdr  ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_ext_insert_extent+0x26d4/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800 [...]  Allocated by task 179:  ext4_find_extent+0x81c/0x1f70  ext4_ext_map_blocks+0x146/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...]  Freed by task 179:  kfree+0xcb/0x240  ext4_find_extent+0x7c0/0x1f70  ext4_ext_insert_extent+0xa26/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...] ==================================================================  So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix slab-use-after-free in ext4_split_extent_at()  We hit the following use-after-free:  ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace:  \u0026lt;TASK\u0026gt;  kasan_report+0x93/0xc0  ext4_split_extent_at+0xba8/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Allocated by task 40:  __kmalloc_noprof+0x1ac/0x480  ext4_find_extent+0xf3b/0x1e70  ext4_ext_map_blocks+0x188/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Freed by task 40:  kfree+0xf1/0x2b0  ext4_find_extent+0xa71/0x1e70  ext4_ext_insert_extent+0xa22/0x3260  ext4_split_extent_at+0x3ef/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================  The flow of issue triggering is as follows:  ext4_split_extent_at   path = *ppath   ext4_ext_insert_extent(ppath)     ext4_ext_create_new_leaf(ppath)       ext4_find_extent(orig_path)         path = *orig_path         read_extent_tree_block           // return -ENOMEM or -EIO         ext4_free_ext_path(path)           kfree(path)         *orig_path = NULL   a. If err is -ENOMEM:   ext4_ext_dirty(path + path-\u0026gt;p_depth)   // path use-after-free !!!   b. If err is -EIO and we have EXT_DEBUG defined:   ext4_ext_show_leaf(path)     eh = path[depth].p_hdr     // path also use-after-free !!!  So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path.  In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid use-after-free in ext4_ext_show_leaf()  In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows:  ext4_split_extent   path = *ppath;   ext4_split_extent_at(ppath)   path = ext4_find_extent(ppath)   ext4_split_extent_at(ppath)     // ext4_find_extent fails to free path     // but zeroout succeeds   ext4_ext_show_leaf(inode, path)     eh = path[depth].p_hdr     // path use-after-free !!!  Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way.  Same problem in ext4_ext_handle_unwritten_extents(). Since \u0026apos;path\u0026apos; is only used in ext4_ext_show_leaf(), remove \u0026apos;path\u0026apos; and use *ppath directly.  This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fbdev: pxafb: Fix possible use after free in pxafb_task()  In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which \u0026amp;fbi-\u0026gt;task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the \u0026amp;pxafb_ops struct is capable of scheduling work.  If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi-\u0026gt;fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                                CPU1                                     | pxafb_task pxafb_remove                       | unregister_framebuffer(info)       | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info)               | // free fbi-\u0026gt;fb                    | set_ctrlr_state(fbi, state)                                    | __pxafb_lcd_power(fbi, 0)                                    | fbi-\u0026gt;lcd_power(on, \u0026amp;fbi-\u0026gt;fb.var)                                    | //use fbi-\u0026gt;fb  Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove.  Note that only root user can remove the driver at runtime.(CVE-2024-49924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/xen-netback: prevent UAF in xenvif_flush_hash()  During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head-\u0026gt;next after the entry becomes free.  Therefore, to solve this, you need to change it to list_for_each_entry_safe.(CVE-2024-49936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix uaf in l2cap_connect  [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54  CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0xc3/0x620 mm/kasan/report.c:488  kasan_report+0xd9/0x110 mm/kasan/report.c:601  l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949  l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]  l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]  l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]  l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825  l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514  hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]  hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ...  Freed by task 5245:  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47  kasan_save_track+0x14/0x30 mm/kasan/common.c:68  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579  poison_slab_object+0xf7/0x160 mm/kasan/common.c:240  __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2256 [inline]  slab_free mm/slub.c:4477 [inline]  kfree+0x12a/0x3b0 mm/slub.c:4598  l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]  kref_put include/linux/kref.h:65 [inline]  l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]  l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802  l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241  hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]  hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265  hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583  abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917  hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-49950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: venus: fix use after free bug in venus_remove due to race condition  in venus_probe, core-\u0026gt;work is bound with venus_sys_error_handler, which is used to handle error. The code use core-\u0026gt;sys_err_done to make sync work. The core-\u0026gt;work is started in venus_event_notify.  If we call venus_remove, there might be an unfished work. The possible sequence is as follows:  CPU0                  CPU1                       |venus_sys_error_handler venus_remove         | hfi_destroy     | venus_hfi_destroy  | kfree(hdev);      |                      |hfi_reinit       |venus_hfi_queues_reinit                      |//use hdev  Fix it by canceling the work in venus_remove.(CVE-2024-49981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amdkfd: amdkfd_free_gtt_mem clear the correct pointer  Pass pointer reference to amdgpu_bo_unref to clear the correct pointer, otherwise amdgpu_bo_unref clear the local variable, the original pointer not set to NULL, this could cause use-after-free bug.(CVE-2024-49991)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tipc: guard against string buffer overrun  Smatch reports that copying media_name and if_name to name_parts may overwrite the destination.   .../bearer.c:166 bearer_name_validate() error: strcpy() \u0026apos;media_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;media_name\u0026apos; (32 vs 16)  .../bearer.c:167 bearer_name_validate() error: strcpy() \u0026apos;if_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;if_name\u0026apos; (1010102 vs 16)  This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs.  Introduced by commit b97bf3fd8f6a (\u0026quot;[TIPC] Initial merge\u0026quot;)  Compile tested only.(CVE-2024-49995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  slip: make slhc_remember() more robust against malicious packets  syzbot found that slhc_remember() was missing checks against malicious packets [1].  slhc_remember() only checked the size of the packet was at least 20, which is not good enough.  We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried.  Add iph and th pointers to make the code more readable.  [1]  BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455   ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]   ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212   ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4091 [inline]   slab_alloc_node mm/slub.c:4134 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ppp: fix ppp_async_encode() illegal access  syzbot reported an issue in ppp_async_encode() [1]  In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb.  BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]  BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]   ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]   ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4092 [inline]   slab_alloc_node mm/slub.c:4135 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  serial: protect uart_port_dtr_rts() in uart_shutdown() too  Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \u0026quot;uart_port_dtr_rts(uport, false);\u0026quot; call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports.  Or it cannot be NULL at this point at all for some reason :P.  Until the above is investigated, stay on the safe side and move this dereference to the if too.  I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tty: n_gsm: Fix use-after-free in gsm_cleanup_mux  BUG: KASAN: slab-use-after-free in gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm] Read of size 8 at addr ffff88815fe99c00 by task poc/3379 CPU: 0 UID: 0 PID: 3379 Comm: poc Not tainted 6.11.0+ #56 Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 11/12/2020 Call Trace:  \u0026lt;TASK\u0026gt;  gsm_cleanup_mux+0x77b/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]  __pfx_gsm_cleanup_mux+0x10/0x10 drivers/tty/n_gsm.c:3124 [n_gsm]  __pfx_sched_clock_cpu+0x10/0x10 kernel/sched/clock.c:389  update_load_avg+0x1c1/0x27b0 kernel/sched/fair.c:4500  __pfx_min_vruntime_cb_rotate+0x10/0x10 kernel/sched/fair.c:846  __rb_insert_augmented+0x492/0xbf0 lib/rbtree.c:161  gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]  _raw_spin_lock_irqsave+0x92/0xf0 arch/x86/include/asm/atomic.h:107  __pfx_gsmld_ioctl+0x10/0x10 drivers/tty/n_gsm.c:3822 [n_gsm]  ktime_get+0x5e/0x140 kernel/time/timekeeping.c:195  ldsem_down_read+0x94/0x4e0 arch/x86/include/asm/atomic64_64.h:79  __pfx_ldsem_down_read+0x10/0x10 drivers/tty/tty_ldsem.c:338  __pfx_do_vfs_ioctl+0x10/0x10 fs/ioctl.c:805  tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818  Allocated by task 65:  gsm_data_alloc.constprop.0+0x27/0x190 drivers/tty/n_gsm.c:926 [n_gsm]  gsm_send+0x2c/0x580 drivers/tty/n_gsm.c:819 [n_gsm]  gsm1_receive+0x547/0xad0 drivers/tty/n_gsm.c:3038 [n_gsm]  gsmld_receive_buf+0x176/0x280 drivers/tty/n_gsm.c:3609 [n_gsm]  tty_ldisc_receive_buf+0x101/0x1e0 drivers/tty/tty_buffer.c:391  tty_port_default_receive_buf+0x61/0xa0 drivers/tty/tty_port.c:39  flush_to_ldisc+0x1b0/0x750 drivers/tty/tty_buffer.c:445  process_scheduled_works+0x2b0/0x10d0 kernel/workqueue.c:3229  worker_thread+0x3dc/0x950 kernel/workqueue.c:3391  kthread+0x2a3/0x370 kernel/kthread.c:389  ret_from_fork+0x2d/0x70 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:257  Freed by task 3367:  kfree+0x126/0x420 mm/slub.c:4580  gsm_cleanup_mux+0x36c/0x7b0 drivers/tty/n_gsm.c:3160 [n_gsm]  gsmld_ioctl+0x395/0x1450 drivers/tty/n_gsm.c:3408 [n_gsm]  tty_ioctl+0x643/0x1100 drivers/tty/tty_io.c:2818  [Analysis] gsm_msg on the tx_ctrl_list or tx_data_list of gsm_mux can be freed by multi threads through ioctl,which leads to the occurrence of uaf. Protect it by gsm tx lock.(CVE-2024-50073)","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-2411.2.0.0302.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","kernel-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","perf-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2411.2.0.0302.oe2003sp4.src.rpm"],"x86_64":["bpftool-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","kernel-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","perf-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2411.2.0.0302.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2370"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48948"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48949"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48960"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48962"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48966"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48971"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48972"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48978"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48992"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49002"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49005"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49011"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49020"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49031"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49032"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47659"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47669"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47696"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47697"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47701"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47742"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49860"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49877"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49878"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49881"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49882"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49883"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49884"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49889"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49936"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49950"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49991"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49995"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50035"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50058"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50073"}],"database_specific":{"severity":"High"}}