Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> perf/x86/intel/uncore: Fix reference count leak in snr_uncore_mmio_map()<br /> <br /> pci_get_device() will increase the reference count for the returned<br /> pci_dev, so snr_uncore_get_mc_dev() will return a pci_dev with its<br /> reference count increased. We need to call pci_dev_put() to decrease the<br /> reference count. Let&amp;#39;s add the missing pci_dev_put().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> regulator: core: Use different devices for resource allocation and DT lookup<br /> <br /> Following by the below discussion, there&amp;#39;s the potential UAF issue<br /> between regulator and mfd.<br /> https://lore.kernel.org/all/20221128143601.1698148-1-yangyingliang@huawei.com/<br /> <br /> From the analysis of Yingliang<br /> <br /> CPU A |CPU B<br /> mt6370_probe() |<br /> devm_mfd_add_devices() |<br /> |mt6370_regulator_probe()<br /> | regulator_register()<br /> | //allocate init_data and add it to devres<br /> | regulator_of_get_init_data()<br /> i2c_unregister_device() |<br /> device_del() |<br /> devres_release_all() |<br /> // init_data is freed |<br /> release_nodes() |<br /> | // using init_data causes UAF<br /> | regulator_register()<br /> <br /> It&amp;#39;s common to use mfd core to create child device for the regulator.<br /> In order to do the DT lookup for init data, the child that registered<br /> the regulator would pass its parent as the parameter. And this causes<br /> init data resource allocated to its parent, not itself. The issue happen<br /> when parent device is going to release and regulator core is still doing<br /> some operation of init data constraint for the regulator of child device.<br /> <br /> To fix it, this patch expand &amp;#39;regulator_register&amp;#39; API to use the<br /> different devices for init data allocation and DT lookup.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/powerplay/psm: Fix memory leak in power state init<br /> <br /> Commit 902bc65de0b3 ("drm/amdgpu/powerplay/psm: return an error in power<br /> state init") made the power state init function return early in case of<br /> failure to get an entry from the powerplay table, but it missed to clean up<br /> the allocated memory for the current power state before returning.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mmc: meson-gx: fix return value check of mmc_add_host()<br /> <br /> mmc_add_host() may return error, if we ignore its return value,<br /> it will lead two issues:<br /> 1. The memory that allocated in mmc_alloc_host() is leaked.<br /> 2. In the remove() path, mmc_remove_host() will be called to<br /> delete device, but it&amp;#39;s not added yet, it will lead a kernel<br /> crash because of null-ptr-deref in device_del().<br /> <br /> Fix this by checking the return value and goto error path which<br /> will call mmc_free_host().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdkfd: Fix memory leak in kfd_mem_dmamap_userptr()<br /> <br /> If the number of pages from the userptr BO differs from the SG BO then the<br /> allocated memory for the SG table doesn&amp;#39;t get freed before returning<br /> -EINVAL, which may lead to a memory leak in some error paths. Fix this by<br /> checking the number of pages before allocating memory for the SG table.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to invalidate dcc-&gt;f2fs_issue_discard in error path<br /> <br /> Syzbot reports a NULL pointer dereference issue as below:<br /> <br /> __refcount_add include/linux/refcount.h:193 [inline]<br /> __refcount_inc include/linux/refcount.h:250 [inline]<br /> refcount_inc include/linux/refcount.h:267 [inline]<br /> get_task_struct include/linux/sched/task.h:110 [inline]<br /> kthread_stop+0x34/0x1c0 kernel/kthread.c:703<br /> f2fs_stop_discard_thread+0x3c/0x5c fs/f2fs/segment.c:1638<br /> kill_f2fs_super+0x5c/0x194 fs/f2fs/super.c:4522<br /> deactivate_locked_super+0x70/0xe8 fs/super.c:332<br /> deactivate_super+0xd0/0xd4 fs/super.c:363<br /> cleanup_mnt+0x1f8/0x234 fs/namespace.c:1186<br /> __cleanup_mnt+0x20/0x30 fs/namespace.c:1193<br /> task_work_run+0xc4/0x14c kernel/task_work.c:177<br /> exit_task_work include/linux/task_work.h:38 [inline]<br /> do_exit+0x26c/0xbe0 kernel/exit.c:795<br /> do_group_exit+0x60/0xe8 kernel/exit.c:925<br /> __do_sys_exit_group kernel/exit.c:936 [inline]<br /> __se_sys_exit_group kernel/exit.c:934 [inline]<br /> __wake_up_parent+0x0/0x40 kernel/exit.c:934<br /> __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline]<br /> invoke_syscall arch/arm64/kernel/syscall.c:52 [inline]<br /> el0_svc_common+0x138/0x220 arch/arm64/kernel/syscall.c:142<br /> do_el0_svc+0x48/0x164 arch/arm64/kernel/syscall.c:206<br /> el0_svc+0x58/0x150 arch/arm64/kernel/entry-common.c:636<br /> el0t_64_sync_handler+0x84/0xf0 arch/arm64/kernel/entry-common.c:654<br /> el0t_64_sync+0x18c/0x190 arch/arm64/kernel/entry.S:581<br /> <br /> The root cause of this issue is in error path of f2fs_start_discard_thread(),<br /> it missed to invalidate dcc-&gt;f2fs_issue_discard, later kthread_stop() may<br /> access invalid pointer.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> md/raid0, raid10: Don&amp;#39;t set discard sectors for request queue<br /> <br /> It should use disk_stack_limits to get a proper max_discard_sectors<br /> rather than setting a value by stack drivers.<br /> <br /> And there is a bug. If all member disks are rotational devices,<br /> raid0/raid10 set max_discard_sectors. So the member devices are<br /> not ssd/nvme, but raid0/raid10 export the wrong value. It reports<br /> warning messages in function __blkdev_issue_discard when mkfs.xfs<br /> like this:<br /> <br /> [ 4616.022599] ------------[ cut here ]------------<br /> [ 4616.027779] WARNING: CPU: 4 PID: 99634 at block/blk-lib.c:50 __blkdev_issue_discard+0x16a/0x1a0<br /> [ 4616.140663] RIP: 0010:__blkdev_issue_discard+0x16a/0x1a0<br /> [ 4616.146601] Code: 24 4c 89 20 31 c0 e9 fe fe ff ff c1 e8 09 8d 48 ff 4c 89 f0 4c 09 e8 48 85 c1 0f 84 55 ff ff ff b8 ea ff ff ff e9 df fe ff ff 0b 48 8d 74 24 08 e8 ea d6 00 00 48 c7 c6 20 1e 89 ab 48 c7 c7<br /> [ 4616.167567] RSP: 0018:ffffaab88cbffca8 EFLAGS: 00010246<br /> [ 4616.173406] RAX: ffff9ba1f9e44678 RBX: 0000000000000000 RCX: ffff9ba1c9792080<br /> [ 4616.181376] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff9ba1c9792080<br /> [ 4616.189345] RBP: 0000000000000cc0 R08: ffffaab88cbffd10 R09: 0000000000000000<br /> [ 4616.197317] R10: 0000000000000012 R11: 0000000000000000 R12: 0000000000000000<br /> [ 4616.205288] R13: 0000000000400000 R14: 0000000000000cc0 R15: ffff9ba1c9792080<br /> [ 4616.213259] FS: 00007f9a5534e980(0000) GS:ffff9ba1b7c80000(0000) knlGS:0000000000000000<br /> [ 4616.222298] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 4616.228719] CR2: 000055a390a4c518 CR3: 0000000123e40006 CR4: 00000000001706e0<br /> [ 4616.236689] Call Trace:<br /> [ 4616.239428] blkdev_issue_discard+0x52/0xb0<br /> [ 4616.244108] blkdev_common_ioctl+0x43c/0xa00<br /> [ 4616.248883] blkdev_ioctl+0x116/0x280<br /> [ 4616.252977] __x64_sys_ioctl+0x8a/0xc0<br /> [ 4616.257163] do_syscall_64+0x5c/0x90<br /> [ 4616.261164] ? handle_mm_fault+0xc5/0x2a0<br /> [ 4616.265652] ? do_user_addr_fault+0x1d8/0x690<br /> [ 4616.270527] ? do_syscall_64+0x69/0x90<br /> [ 4616.274717] ? exc_page_fault+0x62/0x150<br /> [ 4616.279097] entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> [ 4616.284748] RIP: 0033:0x7f9a55398c6b

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fbcon: Set fb_display[i]-&gt;mode to NULL when the mode is released<br /> <br /> Recently, we discovered the following issue through syzkaller:<br /> <br /> BUG: KASAN: slab-use-after-free in fb_mode_is_equal+0x285/0x2f0<br /> Read of size 4 at addr ff11000001b3c69c by task syz.xxx<br /> ...<br /> Call Trace:<br /> <br /> dump_stack_lvl+0xab/0xe0<br /> print_address_description.constprop.0+0x2c/0x390<br /> print_report+0xb9/0x280<br /> kasan_report+0xb8/0xf0<br /> fb_mode_is_equal+0x285/0x2f0<br /> fbcon_mode_deleted+0x129/0x180<br /> fb_set_var+0xe7f/0x11d0<br /> do_fb_ioctl+0x6a0/0x750<br /> fb_ioctl+0xe0/0x140<br /> __x64_sys_ioctl+0x193/0x210<br /> do_syscall_64+0x5f/0x9c0<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> <br /> Based on experimentation and analysis, during framebuffer unregistration,<br /> only the memory of fb_info-&gt;modelist is freed, without setting the<br /> corresponding fb_display[i]-&gt;mode to NULL for the freed modes. This leads<br /> to UAF issues during subsequent accesses. Here&amp;#39;s an example of reproduction<br /> steps:<br /> 1. With /dev/fb0 already registered in the system, load a kernel module<br /> to register a new device /dev/fb1;<br /> 2. Set fb1&amp;#39;s mode to the global fb_display[] array (via FBIOPUT_CON2FBMAP);<br /> 3. Switch console from fb to VGA (to allow normal rmmod of the ko);<br /> 4. Unload the kernel module, at this point fb1&amp;#39;s modelist is freed, leaving<br /> a wild pointer in fb_display[];<br /> 5. Trigger the bug via system calls through fb0 attempting to delete a mode<br /> from fb0.<br /> <br /> Add a check in do_unregister_framebuffer(): if the mode to be freed exists<br /> in fb_display[], set the corresponding mode pointer to NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Fix crash in nfsd4_read_release()<br /> <br /> When tracing is enabled, the trace_nfsd_read_done trace point<br /> crashes during the pynfs read.testNoFh test.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFSD: Define actions for the new time_deleg FATTR4 attributes<br /> <br /> NFSv4 clients won&amp;#39;t send legitimate GETATTR requests for these new<br /> attributes because they are intended to be used only with CB_GETATTR<br /> and SETATTR. But NFSD has to do something besides crashing if it<br /> ever sees a GETATTR request that queries these attributes.<br /> <br /> RFC 8881 Section 18.7.3 states:<br /> <br /> &gt; The server MUST return a value for each attribute that the client<br /> &gt; requests if the attribute is supported by the server for the<br /> &gt; target file system. If the server does not support a particular<br /> &gt; attribute on the target file system, then it MUST NOT return the<br /> &gt; attribute value and MUST NOT set the attribute bit in the result<br /> &gt; bitmap. The server MUST return an error if it supports an<br /> &gt; attribute on the target but cannot obtain its value. In that case,<br /> &gt; no attribute values will be returned.<br /> <br /> Further, RFC 9754 Section 5 states:<br /> <br /> &gt; These new attributes are invalid to be used with GETATTR, VERIFY,<br /> &gt; and NVERIFY, and they can only be used with CB_GETATTR and SETATTR<br /> &gt; by a client holding an appropriate delegation.<br /> <br /> Thus there does not appear to be a specific server response mandated<br /> by specification. Taking the guidance that querying these attributes<br /> via GETATTR is "invalid", NFSD will return nfserr_inval, failing the<br /> request entirely.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: gadget: f_fs: Fix epfile null pointer access after ep enable.<br /> <br /> A race condition occurs when ffs_func_eps_enable() runs concurrently<br /> with ffs_data_reset(). The ffs_data_clear() called in ffs_data_reset()<br /> sets ffs-&gt;epfiles to NULL before resetting ffs-&gt;eps_count to 0, leading<br /> to a NULL pointer dereference when accessing epfile-&gt;ep in<br /> ffs_func_eps_enable() after successful usb_ep_enable().<br /> <br /> The ffs-&gt;epfiles pointer is set to NULL in both ffs_data_clear() and<br /> ffs_data_close() functions, and its modification is protected by the<br /> spinlock ffs-&gt;eps_lock. And the whole ffs_func_eps_enable() function<br /> is also protected by ffs-&gt;eps_lock.<br /> <br /> Thus, add NULL pointer handling for ffs-&gt;epfiles in the<br /> ffs_func_eps_enable() function to fix issues

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/mediatek: Fix device use-after-free on unbind<br /> <br /> A recent change fixed device reference leaks when looking up drm<br /> platform device driver data during bind() but failed to remove a partial<br /> fix which had been added by commit 80805b62ea5b ("drm/mediatek: Fix<br /> kobject put for component sub-drivers").<br /> <br /> This results in a reference imbalance on component bind() failures and<br /> on unbind() which could lead to a user-after-free.<br /> <br /> Make sure to only drop the references after retrieving the driver data<br /> by effectively reverting the previous partial fix.<br /> <br /> Note that holding a reference to a device does not prevent its driver<br /> data from going away so there is no point in keeping the reference.