medikoo — es5-ext
  es5-ext contains ECMAScript 5 extensions. Passing functions with very long names or complex default argument names into `function#copy` or `function#toStringTokens` may cause the script to stall. The vulnerability is patched in v0.10.63. 2024-02-26 not yet calculated CVE-2024-27088
security-advisories@github.com
security-advisories@github.com
security-advisories@github.com
security-advisories@github.com linux — linux
  In the Linux kernel, the following vulnerability has been resolved: netlabel: fix out-of-bounds memory accesses There are two array out-of-bounds memory accesses, one in cipso_v4_map_lvl_valid(), the other in netlbl_bitmap_walk(). Both errors are embarassingly simple, and the fixes are straightforward. As a FYI for anyone backporting this patch to kernels prior to v4.8, you’ll want to apply the netlbl_bitmap_walk() patch to cipso_v4_bitmap_walk() as netlbl_bitmap_walk() doesn’t exist before Linux v4.8. 2024-02-26 not yet calculated CVE-2019-25160
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 N/A — N/A
  Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. 2024-02-26 not yet calculated CVE-2019-25161 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: Fix a potential use after free Free the adap structure only after we are done using it. This patch just moves the put_device() down a bit to avoid the use after free. [wsa: added comment to the code, added Fixes tag] 2024-02-26 not yet calculated CVE-2019-25162
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid potential deadlock Using f2fs_trylock_op() in f2fs_write_compressed_pages() to avoid potential deadlock like we did in f2fs_write_single_data_page(). 2024-02-26 not yet calculated CVE-2020-36775
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: thermal/drivers/cpufreq_cooling: Fix slab OOB issue Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below the power of OPP0 in EM table, it will cause slab out-of-bound issue with negative array index. Return the lowest frequency if limited power cannot found a suitable OPP in EM table to fix this issue. Backtrace: [<ffffffd02d2a37f0>] die+0x104/0x5ac [<ffffffd02d2a5630>] bug_handler+0x64/0xd0 [<ffffffd02d288ce4>] brk_handler+0x160/0x258 [<ffffffd02d281e5c>] do_debug_exception+0x248/0x3f0 [<ffffffd02d284488>] el1_dbg+0x14/0xbc [<ffffffd02d75d1d4>] __kasan_report+0x1dc/0x1e0 [<ffffffd02d75c2e0>] kasan_report+0x10/0x20 [<ffffffd02d75def8>] __asan_report_load8_noabort+0x18/0x28 [<ffffffd02e6fce5c>] cpufreq_power2state+0x180/0x43c [<ffffffd02e6ead80>] power_actor_set_power+0x114/0x1d4 [<ffffffd02e6fac24>] allocate_power+0xaec/0xde0 [<ffffffd02e6f9f80>] power_allocator_throttle+0x3ec/0x5a4 [<ffffffd02e6ea888>] handle_thermal_trip+0x160/0x294 [<ffffffd02e6edd08>] thermal_zone_device_check+0xe4/0x154 [<ffffffd02d351cb4>] process_one_work+0x5e4/0xe28 [<ffffffd02d352f44>] worker_thread+0xa4c/0xfac [<ffffffd02d360124>] kthread+0x33c/0x358 [<ffffffd02d289940>] ret_from_fork+0xc/0x18 2024-02-27 not yet calculated CVE-2020-36776
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: media: dvbdev: Fix memory leak in dvb_media_device_free() dvb_media_device_free() is leaking memory. Free `dvbdev->adapter->conn` before setting it to NULL, as documented in include/media/media-device.h: “The media_entity instance itself must be freed explicitly by the driver if required.” 2024-02-27 not yet calculated CVE-2020-36777
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: xiic: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in xiic_xfer and xiic_i2c_remove. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. 2024-02-28 not yet calculated CVE-2020-36778
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: stm32f7: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in these stm32f7_i2c_xx serious functions. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. 2024-02-28 not yet calculated CVE-2020-36779
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: sprd: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in sprd_i2c_master_xfer() and sprd_i2c_remove(). However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. 2024-02-28 not yet calculated CVE-2020-36780
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: imx: fix reference leak when pm_runtime_get_sync fails In i2c_imx_xfer() and i2c_imx_remove(), the pm reference count is not expected to be incremented on return. However, pm_runtime_get_sync will increment pm reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. 2024-02-28 not yet calculated CVE-2020-36781
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: imx-lpi2c: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in lpi2c_imx_master_enable. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. 2024-02-28 not yet calculated CVE-2020-36782
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: img-scb: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions img_i2c_xfer and img_i2c_init. However, pm_runtime_get_sync will increment the PM reference count even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. 2024-02-28 not yet calculated CVE-2020-36783
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: cadence: fix reference leak when pm_runtime_get_sync fails The PM reference count is not expected to be incremented on return in functions cdns_i2c_master_xfer and cdns_reg_slave. However, pm_runtime_get_sync will increment pm usage counter even failed. Forgetting to putting operation will result in a reference leak here. Replace it with pm_runtime_resume_and_get to keep usage counter balanced. 2024-02-28 not yet calculated CVE-2020-36784
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: media: atomisp: Fix use after free in atomisp_alloc_css_stat_bufs() The “s3a_buf” is freed along with all the other items on the “asd->s3a_stats” list. It leads to a double free and a use after free. 2024-02-28 not yet calculated CVE-2020-36785
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: media: [next] staging: media: atomisp: fix memory leak of object flash In the case where the call to lm3554_platform_data_func returns an error there is a memory leak on the error return path of object flash. Fix this by adding an error return path that will free flash and rename labels fail2 to fail3 and fail1 to fail2. 2024-02-28 not yet calculated CVE-2020-36786
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: media: aspeed: fix clock handling logic Video engine uses eclk and vclk for its clock sources and its reset control is coupled with eclk so the current clock enabling sequence works like below. Enable eclk De-assert Video Engine reset 10ms delay Enable vclk It introduces improper reset on the Video Engine hardware and eventually the hardware generates unexpected DMA memory transfers that can corrupt memory region in random and sporadic patterns. This issue is observed very rarely on some specific AST2500 SoCs but it causes a critical kernel panic with making a various shape of signature so it’s extremely hard to debug. Moreover, the issue is observed even when the video engine is not actively used because udevd turns on the video engine hardware for a short time to make a query in every boot. To fix this issue, this commit changes the clock handling logic to make the reset de-assertion triggered after enabling both eclk and vclk. Also, it adds clk_unprepare call for a case when probe fails. clk: ast2600: fix reset settings for eclk and vclk Video engine reset setting should be coupled with eclk to match it with the setting for previous Aspeed SoCs which is defined in clk-aspeed.c since all Aspeed SoCs are sharing a single video engine driver. Also, reset bit 6 is defined as ‘Video Engine’ reset in datasheet so it should be de-asserted when eclk is enabled. This commit fixes the setting. 2024-02-28 not yet calculated CVE-2020-36787
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33072 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33084 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33085 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33099 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33100 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33102 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33109 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33111 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33112 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33116 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33121 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33125 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33127 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33131 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33132 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33133 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33134 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33136 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33138 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33140 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33141 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33142 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33143 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33144 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33145 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33146 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33148 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33151 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33152 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33153 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33154 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33156 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33157 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33158 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33160 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33161 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33162 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33163 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33165 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-33167 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-37405 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-3885 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41851 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41852 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41853 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41854 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41855 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41856 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41857 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41858 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41859 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-41860 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-43351 N/A — N/A
  Rejected reason: This is unused. 2024-02-23 not yet calculated CVE-2021-44457 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: hso: fix null-ptr-deref during tty device unregistration Multiple ttys try to claim the same the minor number causing a double unregistration of the same device. The first unregistration succeeds but the next one results in a null-ptr-deref. The get_free_serial_index() function returns an available minor number but doesn’t assign it immediately. The assignment is done by the caller later. But before this assignment, calls to get_free_serial_index() would return the same minor number. Fix this by modifying get_free_serial_index to assign the minor number immediately after one is found to be and rename it to obtain_minor() to better reflect what it does. Similary, rename set_serial_by_index() to release_minor() and modify it to free up the minor number of the given hso_serial. Every obtain_minor() should have corresponding release_minor() call. 2024-02-26 not yet calculated CVE-2021-46904
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: hso: fix NULL-deref on disconnect regression Commit 8a12f8836145 (“net: hso: fix null-ptr-deref during tty device unregistration”) fixed the racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on every disconnect instead. Specifically, the serial device table must no longer be accessed after the minor has been released by hso_serial_tty_unregister(). 2024-02-26 not yet calculated CVE-2021-46905
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: HID: usbhid: fix info leak in hid_submit_ctrl In hid_submit_ctrl(), the way of calculating the report length doesn’t take into account that report->size can be zero. When running the syzkaller reproducer, a report of size 0 causes hid_submit_ctrl) to calculate transfer_buffer_length as 16384. When this urb is passed to the usb core layer, KMSAN reports an info leak of 16384 bytes. To fix this, first modify hid_report_len() to account for the zero report size case by using DIV_ROUND_UP for the division. Then, call it from hid_submit_ctrl(). 2024-02-26 not yet calculated CVE-2021-46906
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Don’t use vcpu->run->internal.ndata as an array index __vmx_handle_exit() uses vcpu->run->internal.ndata as an index for an array access. Since vcpu->run is (can be) mapped to a user address space with a writer permission, the ‘ndata’ could be updated by the user process at anytime (the user process can set it to outside the bounds of the array). So, it is not safe that __vmx_handle_exit() uses the ‘ndata’ that way. 2024-02-27 not yet calculated CVE-2021-46907
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: bpf: Use correct permission flag for mixed signed bounds arithmetic We forbid adding unknown scalars with mixed signed bounds due to the spectre v1 masking mitigation. Hence this also needs bypass_spec_v1 flag instead of allow_ptr_leaks. 2024-02-27 not yet calculated CVE-2021-46908
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ARM: footbridge: fix PCI interrupt mapping Since commit 30fdfb929e82 (“PCI: Add a call to pci_assign_irq() in pci_device_probe()”), the PCI code will call the IRQ mapping function whenever a PCI driver is probed. If these are marked as __init, this causes an oops if a PCI driver is loaded or bound after the kernel has initialised. 2024-02-27 not yet calculated CVE-2021-46909
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ARM: 9063/1: mm: reduce maximum number of CPUs if DEBUG_KMAP_LOCAL is enabled The debugging code for kmap_local() doubles the number of per-CPU fixmap slots allocated for kmap_local(), in order to use half of them as guard regions. This causes the fixmap region to grow downwards beyond the start of its reserved window if the supported number of CPUs is large, and collide with the newly added virtual DT mapping right below it, which is obviously not good. One manifestation of this is EFI boot on a kernel built with NR_CPUS=32 and CONFIG_DEBUG_KMAP_LOCAL=y, which may pass the FDT in highmem, resulting in block entries below the fixmap region that the fixmap code misidentifies as fixmap table entries, and subsequently tries to dereference using a phys-to-virt translation that is only valid for lowmem. This results in a cryptic splat such as the one below. ftrace: allocating 45548 entries in 89 pages 8<— cut here — Unable to handle kernel paging request at virtual address fc6006f0 pgd = (ptrval) [fc6006f0] *pgd=80000040207003, *pmd=00000000 Internal error: Oops: a06 [#1] SMP ARM Modules linked in: CPU: 0 PID: 0 Comm: swapper Not tainted 5.11.0+ #382 Hardware name: Generic DT based system PC is at cpu_ca15_set_pte_ext+0x24/0x30 LR is at __set_fixmap+0xe4/0x118 pc : [<c041ac9c>] lr : [<c04189d8>] psr: 400000d3 sp : c1601ed8 ip : 00400000 fp : 00800000 r10: 0000071f r9 : 00421000 r8 : 00c00000 r7 : 00c00000 r6 : 0000071f r5 : ffade000 r4 : 4040171f r3 : 00c00000 r2 : 4040171f r1 : c041ac78 r0 : fc6006f0 Flags: nZcv IRQs off FIQs off Mode SVC_32 ISA ARM Segment none Control: 30c5387d Table: 40203000 DAC: 00000001 Process swapper (pid: 0, stack limit = 0x(ptrval)) So let’s limit CONFIG_NR_CPUS to 16 when CONFIG_DEBUG_KMAP_LOCAL=y. Also, fix the BUILD_BUG_ON() check that was supposed to catch this, by checking whether the region grows below the start address rather than above the end address. 2024-02-27 not yet calculated CVE-2021-46910
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ch_ktls: Fix kernel panic Taking page refcount is not ideal and causes kernel panic sometimes. It’s better to take tx_ctx lock for the complete skb transmit, to avoid page cleanup if ACK received in middle. 2024-02-27 not yet calculated CVE-2021-46911
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: Make tcp_allowed_congestion_control readonly in non-init netns Currently, tcp_allowed_congestion_control is global and writable; writing to it in any net namespace will leak into all other net namespaces. tcp_available_congestion_control and tcp_allowed_congestion_control are the only sysctls in ipv4_net_table (the per-netns sysctl table) with a NULL data pointer; their handlers (proc_tcp_available_congestion_control and proc_allowed_congestion_control) have no other way of referencing a struct net. Thus, they operate globally. Because ipv4_net_table does not use designated initializers, there is no easy way to fix up this one “bad” table entry. However, the data pointer updating logic shouldn’t be applied to NULL pointers anyway, so we instead force these entries to be read-only. These sysctls used to exist in ipv4_table (init-net only), but they were moved to the per-net ipv4_net_table, presumably without realizing that tcp_allowed_congestion_control was writable and thus introduced a leak. Because the intent of that commit was only to know (i.e. read) “which congestion algorithms are available or allowed”, this read-only solution should be sufficient. The logic added in recent commit 31c4d2f160eb: (“net: Ensure net namespace isolation of sysctls”) does not and cannot check for NULL data pointers, because other table entries (e.g. /proc/sys/net/netfilter/nf_log/) have .data=NULL but use other methods (.extra2) to access the struct net. 2024-02-27 not yet calculated CVE-2021-46912
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: clone set element expression template memcpy() breaks when using connlimit in set elements. Use nft_expr_clone() to initialize the connlimit expression list, otherwise connlimit garbage collector crashes when walking on the list head copy. [ 493.064656] Workqueue: events_power_efficient nft_rhash_gc [nf_tables] [ 493.064685] RIP: 0010:find_or_evict+0x5a/0x90 [nf_conncount] [ 493.064694] Code: 2b 43 40 83 f8 01 77 0d 48 c7 c0 f5 ff ff ff 44 39 63 3c 75 df 83 6d 18 01 48 8b 43 08 48 89 de 48 8b 13 48 8b 3d ee 2f 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 00 00 ad de 48 89 03 48 83 [ 493.064699] RSP: 0018:ffffc90000417dc0 EFLAGS: 00010297 [ 493.064704] RAX: 0000000000000000 RBX: ffff888134f38410 RCX: 0000000000000000 [ 493.064708] RDX: 0000000000000000 RSI: ffff888134f38410 RDI: ffff888100060cc0 [ 493.064711] RBP: ffff88812ce594a8 R08: ffff888134f38438 R09: 00000000ebb9025c [ 493.064714] R10: ffffffff8219f838 R11: 0000000000000017 R12: 0000000000000001 [ 493.064718] R13: ffffffff82146740 R14: ffff888134f38410 R15: 0000000000000000 [ 493.064721] FS: 0000000000000000(0000) GS:ffff88840e440000(0000) knlGS:0000000000000000 [ 493.064725] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 493.064729] CR2: 0000000000000008 CR3: 00000001330aa002 CR4: 00000000001706e0 [ 493.064733] Call Trace: [ 493.064737] nf_conncount_gc_list+0x8f/0x150 [nf_conncount] [ 493.064746] nft_rhash_gc+0x106/0x390 [nf_tables] 2024-02-27 not yet calculated CVE-2021-46913
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ixgbe: fix unbalanced device enable/disable in suspend/resume pci_disable_device() called in __ixgbe_shutdown() decreases dev->enable_cnt by 1. pci_enable_device_mem() which increases dev->enable_cnt by 1, was removed from ixgbe_resume() in commit 6f82b2558735 (“ixgbe: use generic power management”). This caused unbalanced increase/decrease. So add pci_enable_device_mem() back. Fix the following call trace. ixgbe 0000:17:00.1: disabling already-disabled device Call Trace: __ixgbe_shutdown+0x10a/0x1e0 [ixgbe] ixgbe_suspend+0x32/0x70 [ixgbe] pci_pm_suspend+0x87/0x160 ? pci_pm_freeze+0xd0/0xd0 dpm_run_callback+0x42/0x170 __device_suspend+0x114/0x460 async_suspend+0x1f/0xa0 async_run_entry_fn+0x3c/0xf0 process_one_work+0x1dd/0x410 worker_thread+0x34/0x3f0 ? cancel_delayed_work+0x90/0x90 kthread+0x14c/0x170 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 2024-02-27 not yet calculated CVE-2021-46914
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: nft_limit: avoid possible divide error in nft_limit_init div_u64() divides u64 by u32. nft_limit_init() wants to divide u64 by u64, use the appropriate math function (div64_u64) divide error: 0000 [#1] PREEMPT SMP KASAN CPU: 1 PID: 8390 Comm: syz-executor188 Not tainted 5.12.0-rc4-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:div_u64_rem include/linux/math64.h:28 [inline] RIP: 0010:div_u64 include/linux/math64.h:127 [inline] RIP: 0010:nft_limit_init+0x2a2/0x5e0 net/netfilter/nft_limit.c:85 Code: ef 4c 01 eb 41 0f 92 c7 48 89 de e8 38 a5 22 fa 4d 85 ff 0f 85 97 02 00 00 e8 ea 9e 22 fa 4c 0f af f3 45 89 ed 31 d2 4c 89 f0 <49> f7 f5 49 89 c6 e8 d3 9e 22 fa 48 8d 7d 48 48 b8 00 00 00 00 00 RSP: 0018:ffffc90009447198 EFLAGS: 00010246 RAX: 0000000000000000 RBX: 0000200000000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffffffff875152e6 RDI: 0000000000000003 RBP: ffff888020f80908 R08: 0000200000000000 R09: 0000000000000000 R10: ffffffff875152d8 R11: 0000000000000000 R12: ffffc90009447270 R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 FS: 000000000097a300(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200001c4 CR3: 0000000026a52000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: nf_tables_newexpr net/netfilter/nf_tables_api.c:2675 [inline] nft_expr_init+0x145/0x2d0 net/netfilter/nf_tables_api.c:2713 nft_set_elem_expr_alloc+0x27/0x280 net/netfilter/nf_tables_api.c:5160 nf_tables_newset+0x1997/0x3150 net/netfilter/nf_tables_api.c:4321 nfnetlink_rcv_batch+0x85a/0x21b0 net/netfilter/nfnetlink.c:456 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:580 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:598 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 entry_SYSCALL_64_after_hwframe+0x44/0xae 2024-02-27 not yet calculated CVE-2021-46915
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ixgbe: Fix NULL pointer dereference in ethtool loopback test The ixgbe driver currently generates a NULL pointer dereference when performing the ethtool loopback test. This is due to the fact that there isn’t a q_vector associated with the test ring when it is setup as interrupts are not normally added to the test rings. To address this I have added code that will check for a q_vector before returning a napi_id value. If a q_vector is not present it will return a value of 0. 2024-02-27 not yet calculated CVE-2021-46916
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix wq cleanup of WQCFG registers A pre-release silicon erratum workaround where wq reset does not clear WQCFG registers was leaked into upstream code. Use wq reset command instead of blasting the MMIO region. This also address an issue where we clobber registers in future devices. 2024-02-27 not yet calculated CVE-2021-46917
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: clear MSIX permission entry on shutdown Add disabling/clearing of MSIX permission entries on device shutdown to mirror the enabling of the MSIX entries on probe. Current code left the MSIX enabled and the pasid entries still programmed at device shutdown. 2024-02-27 not yet calculated CVE-2021-46918
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: fix wq size store permission state WQ size can only be changed when the device is disabled. Current code allows change when device is enabled but wq is disabled. Change the check to detect device state. 2024-02-27 not yet calculated CVE-2021-46919
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix clobbering of SWERR overflow bit on writeback Current code blindly writes over the SWERR and the OVERFLOW bits. Write back the bits actually read instead so the driver avoids clobbering the OVERFLOW bit that comes after the register is read. 2024-02-27 not yet calculated CVE-2021-46920
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: locking/qrwlock: Fix ordering in queued_write_lock_slowpath() While this code is executed with the wait_lock held, a reader can acquire the lock without holding wait_lock. The writer side loops checking the value with the atomic_cond_read_acquire(), but only truly acquires the lock when the compare-and-exchange is completed successfully which isn’t ordered. This exposes the window between the acquire and the cmpxchg to an A-B-A problem which allows reads following the lock acquisition to observe values speculatively before the write lock is truly acquired. We’ve seen a problem in epoll where the reader does a xchg while holding the read lock, but the writer can see a value change out from under it. Writer | Reader ——————————————————————————– ep_scan_ready_list() | |- write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | | read_lock_irqsave(&ep->lock, flags); –> (observes value before unlock) | chain_epi_lockless() | | epi->next = xchg(&ep->ovflist, epi); | | read_unlock_irqrestore(&ep->lock, flags); | | | atomic_cmpxchg_relaxed() | |– READ_ONCE(ep->ovflist); | A core can order the read of the ovflist ahead of the atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire semantics addresses this issue at which point the atomic_cond_read can be switched to use relaxed semantics. [peterz: use try_cmpxchg()] 2024-02-27 not yet calculated CVE-2021-46921
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix TPM reservation for seal/unseal The original patch 8c657a0590de (“KEYS: trusted: Reserve TPM for seal and unseal operations”) was correct on the mailing list: https://lore.kernel.org/linux-integrity/20210128235621.127925-4-jarkko@kernel.org/ But somehow got rebased so that the tpm_try_get_ops() in tpm2_seal_trusted() got lost. This causes an imbalanced put of the TPM ops and causes oopses on TIS based hardware. This fix puts back the lost tpm_try_get_ops() 2024-02-27 not yet calculated CVE-2021-46922
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: fs/mount_setattr: always cleanup mount_kattr Make sure that finish_mount_kattr() is called after mount_kattr was succesfully built in both the success and failure case to prevent leaking any references we took when we built it. We returned early if path lookup failed thereby risking to leak an additional reference we took when building mount_kattr when an idmapped mount was requested. 2024-02-27 not yet calculated CVE-2021-46923
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: NFC: st21nfca: Fix memory leak in device probe and remove ‘phy->pending_skb’ is alloced when device probe, but forgot to free in the error handling path and remove path, this cause memory leak as follows: unreferenced object 0xffff88800bc06800 (size 512): comm “8”, pid 11775, jiffies 4295159829 (age 9.032s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<00000000d66c09ce>] __kmalloc_node_track_caller+0x1ed/0x450 [<00000000c93382b3>] kmalloc_reserve+0x37/0xd0 [<000000005fea522c>] __alloc_skb+0x124/0x380 [<0000000019f29f9a>] st21nfca_hci_i2c_probe+0x170/0x8f2 Fix it by freeing ‘pending_skb’ in error and remove. 2024-02-27 not yet calculated CVE-2021-46924
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net/smc: fix kernel panic caused by race of smc_sock A crash occurs when smc_cdc_tx_handler() tries to access smc_sock but smc_release() has already freed it. [ 4570.695099] BUG: unable to handle page fault for address: 000000002eae9e88 [ 4570.696048] #PF: supervisor write access in kernel mode [ 4570.696728] #PF: error_code(0x0002) – not-present page [ 4570.697401] PGD 0 P4D 0 [ 4570.697716] Oops: 0002 [#1] PREEMPT SMP NOPTI [ 4570.698228] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.16.0-rc4+ #111 [ 4570.699013] Hardware name: Alibaba Cloud Alibaba Cloud ECS, BIOS 8c24b4c 04/0 [ 4570.699933] RIP: 0010:_raw_spin_lock+0x1a/0x30 <…> [ 4570.711446] Call Trace: [ 4570.711746] <IRQ> [ 4570.711992] smc_cdc_tx_handler+0x41/0xc0 [ 4570.712470] smc_wr_tx_tasklet_fn+0x213/0x560 [ 4570.712981] ? smc_cdc_tx_dismisser+0x10/0x10 [ 4570.713489] tasklet_action_common.isra.17+0x66/0x140 [ 4570.714083] __do_softirq+0x123/0x2f4 [ 4570.714521] irq_exit_rcu+0xc4/0xf0 [ 4570.714934] common_interrupt+0xba/0xe0 Though smc_cdc_tx_handler() checked the existence of smc connection, smc_release() may have already dismissed and released the smc socket before smc_cdc_tx_handler() further visits it. smc_cdc_tx_handler() |smc_release() if (!conn) | | |smc_cdc_tx_dismiss_slots() | smc_cdc_tx_dismisser() | |sock_put(&smc->sk) <- last sock_put, | smc_sock freed bh_lock_sock(&smc->sk) (panic) | To make sure we won’t receive any CDC messages after we free the smc_sock, add a refcount on the smc_connection for inflight CDC message(posted to the QP but haven’t received related CQE), and don’t release the smc_connection until all the inflight CDC messages haven been done, for both success or failed ones. Using refcount on CDC messages brings another problem: when the link is going to be destroyed, smcr_link_clear() will reset the QP, which then remove all the pending CQEs related to the QP in the CQ. To make sure all the CQEs will always come back so the refcount on the smc_connection can always reach 0, smc_ib_modify_qp_reset() was replaced by smc_ib_modify_qp_error(). And remove the timeout in smc_wr_tx_wait_no_pending_sends() since we need to wait for all pending WQEs done, or we may encounter use-after- free when handling CQEs. For IB device removal routine, we need to wait for all the QPs on that device been destroyed before we can destroy CQs on the device, or the refcount on smc_connection won’t reach 0 and smc_sock cannot be released. 2024-02-27 not yet calculated CVE-2021-46925
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: ALSA: hda: intel-sdw-acpi: harden detection of controller The existing code currently sets a pointer to an ACPI handle before checking that it’s actually a SoundWire controller. This can lead to issues where the graph walk continues and eventually fails, but the pointer was set already. This patch changes the logic so that the information provided to the caller is set when a controller is found. 2024-02-27 not yet calculated CVE-2021-46926
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nitro_enclaves: Use get_user_pages_unlocked() call to handle mmap assert After commit 5b78ed24e8ec (“mm/pagemap: add mmap_assert_locked() annotations to find_vma*()”), the call to get_user_pages() will trigger the mmap assert. static inline void mmap_assert_locked(struct mm_struct *mm) { lockdep_assert_held(&mm->mmap_lock); VM_BUG_ON_MM(!rwsem_is_locked(&mm->mmap_lock), mm); } [ 62.521410] kernel BUG at include/linux/mmap_lock.h:156! ………………………………………………….. [ 62.538938] RIP: 0010:find_vma+0x32/0x80 ………………………………………………….. [ 62.605889] Call Trace: [ 62.608502] <TASK> [ 62.610956] ? lock_timer_base+0x61/0x80 [ 62.614106] find_extend_vma+0x19/0x80 [ 62.617195] __get_user_pages+0x9b/0x6a0 [ 62.620356] __gup_longterm_locked+0x42d/0x450 [ 62.623721] ? finish_wait+0x41/0x80 [ 62.626748] ? __kmalloc+0x178/0x2f0 [ 62.629768] ne_set_user_memory_region_ioctl.isra.0+0x225/0x6a0 [nitro_enclaves] [ 62.635776] ne_enclave_ioctl+0x1cf/0x6d7 [nitro_enclaves] [ 62.639541] __x64_sys_ioctl+0x82/0xb0 [ 62.642620] do_syscall_64+0x3b/0x90 [ 62.645642] entry_SYSCALL_64_after_hwframe+0x44/0xae Use get_user_pages_unlocked() when setting the enclave memory regions. That’s a similar pattern as mmap_read_lock() used together with get_user_pages(). 2024-02-27 not yet calculated CVE-2021-46927
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: parisc: Clear stale IIR value on instruction access rights trap When a trap 7 (Instruction access rights) occurs, this means the CPU couldn’t execute an instruction due to missing execute permissions on the memory region. In this case it seems the CPU didn’t even fetched the instruction from memory and thus did not store it in the cr19 (IIR) register before calling the trap handler. So, the trap handler will find some random old stale value in cr19. This patch simply overwrites the stale IIR value with a constant magic “bad food” value (0xbaadf00d), in the hope people don’t start to try to understand the various random IIR values in trap 7 dumps. 2024-02-27 not yet calculated CVE-2021-46928
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: sctp: use call_rcu to free endpoint This patch is to delay the endpoint free by calling call_rcu() to fix another use-after-free issue in sctp_sock_dump(): BUG: KASAN: use-after-free in __lock_acquire+0x36d9/0x4c20 Call Trace: __lock_acquire+0x36d9/0x4c20 kernel/locking/lockdep.c:3218 lock_acquire+0x1ed/0x520 kernel/locking/lockdep.c:3844 __raw_spin_lock_bh include/linux/spinlock_api_smp.h:135 [inline] _raw_spin_lock_bh+0x31/0x40 kernel/locking/spinlock.c:168 spin_lock_bh include/linux/spinlock.h:334 [inline] __lock_sock+0x203/0x350 net/core/sock.c:2253 lock_sock_nested+0xfe/0x120 net/core/sock.c:2774 lock_sock include/net/sock.h:1492 [inline] sctp_sock_dump+0x122/0xb20 net/sctp/diag.c:324 sctp_for_each_transport+0x2b5/0x370 net/sctp/socket.c:5091 sctp_diag_dump+0x3ac/0x660 net/sctp/diag.c:527 __inet_diag_dump+0xa8/0x140 net/ipv4/inet_diag.c:1049 inet_diag_dump+0x9b/0x110 net/ipv4/inet_diag.c:1065 netlink_dump+0x606/0x1080 net/netlink/af_netlink.c:2244 __netlink_dump_start+0x59a/0x7c0 net/netlink/af_netlink.c:2352 netlink_dump_start include/linux/netlink.h:216 [inline] inet_diag_handler_cmd+0x2ce/0x3f0 net/ipv4/inet_diag.c:1170 __sock_diag_cmd net/core/sock_diag.c:232 [inline] sock_diag_rcv_msg+0x31d/0x410 net/core/sock_diag.c:263 netlink_rcv_skb+0x172/0x440 net/netlink/af_netlink.c:2477 sock_diag_rcv+0x2a/0x40 net/core/sock_diag.c:274 This issue occurs when asoc is peeled off and the old sk is freed after getting it by asoc->base.sk and before calling lock_sock(sk). To prevent the sk free, as a holder of the sk, ep should be alive when calling lock_sock(). This patch uses call_rcu() and moves sock_put and ep free into sctp_endpoint_destroy_rcu(), so that it’s safe to try to hold the ep under rcu_read_lock in sctp_transport_traverse_process(). If sctp_endpoint_hold() returns true, it means this ep is still alive and we have held it and can continue to dump it; If it returns false, it means this ep is dead and can be freed after rcu_read_unlock, and we should skip it. In sctp_sock_dump(), after locking the sk, if this ep is different from tsp->asoc->ep, it means during this dumping, this asoc was peeled off before calling lock_sock(), and the sk should be skipped; If this ep is the same with tsp->asoc->ep, it means no peeloff happens on this asoc, and due to lock_sock, no peeloff will happen either until release_sock. Note that delaying endpoint free won’t delay the port release, as the port release happens in sctp_endpoint_destroy() before calling call_rcu(). Also, freeing endpoint by call_rcu() makes it safe to access the sk by asoc->base.sk in sctp_assocs_seq_show() and sctp_rcv(). Thanks Jones to bring this issue up. v1->v2: – improve the changelog. – add kfree(ep) into sctp_endpoint_destroy_rcu(), as Jakub noticed. 2024-02-27 not yet calculated CVE-2021-46929
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: usb: mtu3: fix list_head check warning This is caused by uninitialization of list_head. BUG: KASAN: use-after-free in __list_del_entry_valid+0x34/0xe4 Call trace: dump_backtrace+0x0/0x298 show_stack+0x24/0x34 dump_stack+0x130/0x1a8 print_address_description+0x88/0x56c __kasan_report+0x1b8/0x2a0 kasan_report+0x14/0x20 __asan_load8+0x9c/0xa0 __list_del_entry_valid+0x34/0xe4 mtu3_req_complete+0x4c/0x300 [mtu3] mtu3_gadget_stop+0x168/0x448 [mtu3] usb_gadget_unregister_driver+0x204/0x3a0 unregister_gadget_item+0x44/0xa4 2024-02-27 not yet calculated CVE-2021-46930
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Wrap the tx reporter dump callback to extract the sq Function mlx5e_tx_reporter_dump_sq() casts its void * argument to struct mlx5e_txqsq *, but in TX-timeout-recovery flow the argument is actually of type struct mlx5e_tx_timeout_ctx *. mlx5_core 0000:08:00.1 enp8s0f1: TX timeout detected mlx5_core 0000:08:00.1 enp8s0f1: TX timeout on queue: 1, SQ: 0x11ec, CQ: 0x146d, SQ Cons: 0x0 SQ Prod: 0x1, usecs since last trans: 21565000 BUG: stack guard page was hit at 0000000093f1a2de (stack is 00000000b66ea0dc..000000004d932dae) kernel stack overflow (page fault): 0000 [#1] SMP NOPTI CPU: 5 PID: 95 Comm: kworker/u20:1 Tainted: G W OE 5.13.0_mlnx #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 Workqueue: mlx5e mlx5e_tx_timeout_work [mlx5_core] RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 [mlx5_core] Call Trace: mlx5e_tx_reporter_dump+0x43/0x1c0 [mlx5_core] devlink_health_do_dump.part.91+0x71/0xd0 devlink_health_report+0x157/0x1b0 mlx5e_reporter_tx_timeout+0xb9/0xf0 [mlx5_core] ? mlx5e_tx_reporter_err_cqe_recover+0x1d0/0x1d0 [mlx5_core] ? mlx5e_health_queue_dump+0xd0/0xd0 [mlx5_core] ? update_load_avg+0x19b/0x550 ? set_next_entity+0x72/0x80 ? pick_next_task_fair+0x227/0x340 ? finish_task_switch+0xa2/0x280 mlx5e_tx_timeout_work+0x83/0xb0 [mlx5_core] process_one_work+0x1de/0x3a0 worker_thread+0x2d/0x3c0 ? process_one_work+0x3a0/0x3a0 kthread+0x115/0x130 ? kthread_park+0x90/0x90 ret_from_fork+0x1f/0x30 –[ end trace 51ccabea504edaff ]— RIP: 0010:mlx5e_tx_reporter_dump_sq+0xd3/0x180 PKRU: 55555554 Kernel panic – not syncing: Fatal exception Kernel Offset: disabled end Kernel panic – not syncing: Fatal exception To fix this bug add a wrapper for mlx5e_tx_reporter_dump_sq() which extracts the sq from struct mlx5e_tx_timeout_ctx and set it as the TX-timeout-recovery flow dump callback. 2024-02-27 not yet calculated CVE-2021-46931
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: Input: appletouch – initialize work before device registration Syzbot has reported warning in __flush_work(). This warning is caused by work->func == NULL, which means missing work initialization. This may happen, since input_dev->close() calls cancel_work_sync(&dev->work), but dev->work initalization happens _after_ input_register_device() call. So this patch moves dev->work initialization before registering input device 2024-02-27 not yet calculated CVE-2021-46932
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: usb: gadget: f_fs: Clear ffs_eventfd in ffs_data_clear. ffs_data_clear is indirectly called from both ffs_fs_kill_sb and ffs_ep0_release, so it ends up being called twice when userland closes ep0 and then unmounts f_fs. If userland provided an eventfd along with function’s USB descriptors, it ends up calling eventfd_ctx_put as many times, causing a refcount underflow. NULL-ify ffs_eventfd to prevent these extraneous eventfd_ctx_put calls. Also, set epfiles to NULL right after de-allocating it, for readability. For completeness, ffs_data_clear actually ends up being called thrice, the last call being before the whole ffs structure gets freed, so when this specific sequence happens there is a second underflow happening (but not being reported): /sys/kernel/debug/tracing# modprobe usb_f_fs /sys/kernel/debug/tracing# echo ffs_data_clear > set_ftrace_filter /sys/kernel/debug/tracing# echo function > current_tracer /sys/kernel/debug/tracing# echo 1 > tracing_on (setup gadget, run and kill function userland process, teardown gadget) /sys/kernel/debug/tracing# echo 0 > tracing_on /sys/kernel/debug/tracing# cat trace smartcard-openp-436 [000] ….. 1946.208786: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] ….. 1946.279147: ffs_data_clear <-ffs_data_closed smartcard-openp-431 [000] .n… 1946.905512: ffs_data_clear <-ffs_data_put Warning output corresponding to above trace: [ 1946.284139] WARNING: CPU: 0 PID: 431 at lib/refcount.c:28 refcount_warn_saturate+0x110/0x15c [ 1946.293094] refcount_t: underflow; use-after-free. [ 1946.298164] Modules linked in: usb_f_ncm(E) u_ether(E) usb_f_fs(E) hci_uart(E) btqca(E) btrtl(E) btbcm(E) btintel(E) bluetooth(E) nls_ascii(E) nls_cp437(E) vfat(E) fat(E) bcm2835_v4l2(CE) bcm2835_mmal_vchiq(CE) videobuf2_vmalloc(E) videobuf2_memops(E) sha512_generic(E) videobuf2_v4l2(E) sha512_arm(E) videobuf2_common(E) videodev(E) cpufreq_dt(E) snd_bcm2835(CE) brcmfmac(E) mc(E) vc4(E) ctr(E) brcmutil(E) snd_soc_core(E) snd_pcm_dmaengine(E) drbg(E) snd_pcm(E) snd_timer(E) snd(E) soundcore(E) drm_kms_helper(E) cec(E) ansi_cprng(E) rc_core(E) syscopyarea(E) raspberrypi_cpufreq(E) sysfillrect(E) sysimgblt(E) cfg80211(E) max17040_battery(OE) raspberrypi_hwmon(E) fb_sys_fops(E) regmap_i2c(E) ecdh_generic(E) rfkill(E) ecc(E) bcm2835_rng(E) rng_core(E) vchiq(CE) leds_gpio(E) libcomposite(E) fuse(E) configfs(E) ip_tables(E) x_tables(E) autofs4(E) ext4(E) crc16(E) mbcache(E) jbd2(E) crc32c_generic(E) sdhci_iproc(E) sdhci_pltfm(E) sdhci(E) [ 1946.399633] CPU: 0 PID: 431 Comm: smartcard-openp Tainted: G C OE 5.15.0-1-rpi #1 Debian 5.15.3-1 [ 1946.417950] Hardware name: BCM2835 [ 1946.425442] Backtrace: [ 1946.432048] [<c08d60a0>] (dump_backtrace) from [<c08d62ec>] (show_stack+0x20/0x24) [ 1946.448226] r7:00000009 r6:0000001c r5:c04a948c r4:c0a64e2c [ 1946.458412] [<c08d62cc>] (show_stack) from [<c08d9ae0>] (dump_stack+0x28/0x30) [ 1946.470380] [<c08d9ab8>] (dump_stack) from [<c0123500>] (__warn+0xe8/0x154) [ 1946.482067] r5:c04a948c r4:c0a71dc8 [ 1946.490184] [<c0123418>] (__warn) from [<c08d6948>] (warn_slowpath_fmt+0xa0/0xe4) [ 1946.506758] r7:00000009 r6:0000001c r5:c0a71dc8 r4:c0a71e04 [ 1946.517070] [<c08d68ac>] (warn_slowpath_fmt) from [<c04a948c>] (refcount_warn_saturate+0x110/0x15c) [ 1946.535309] r8:c0100224 r7:c0dfcb84 r6:ffffffff r5:c3b84c00 r4:c24a17c0 [ 1946.546708] [<c04a937c>] (refcount_warn_saturate) from [<c0380134>] (eventfd_ctx_put+0x48/0x74) [ 1946.564476] [<c03800ec>] (eventfd_ctx_put) from [<bf5464e8>] (ffs_data_clear+0xd0/0x118 [usb_f_fs]) [ 1946.582664] r5:c3b84c00 r4:c2695b00 [ 1946.590668] [<bf546418>] (ffs_data_clear [usb_f_fs]) from [<bf547cc0>] (ffs_data_closed+0x9c/0x150 [usb_f_fs]) [ 1946.609608] r5:bf54d014 r4:c2695b00 [ 1946.617522] [<bf547c24>] (ffs_data_closed [usb_f_fs]) from [<bf547da0>] (ffs_fs_kill_sb+0x2c/0x30 [usb_f_fs]) [ 1946.636217] r7:c0dfcb —truncated— 2024-02-27 not yet calculated CVE-2021-46933
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: validate user data in compat ioctl Wrong user data may cause warning in i2c_transfer(), ex: zero msgs. Userspace should not be able to trigger warnings, so this patch adds validation checks for user data in compact ioctl to prevent reported warnings 2024-02-27 not yet calculated CVE-2021-46934
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: binder: fix async_free_space accounting for empty parcels In 4.13, commit 74310e06be4d (“android: binder: Move buffer out of area shared with user space”) fixed a kernel structure visibility issue. As part of that patch, sizeof(void *) was used as the buffer size for 0-length data payloads so the driver could detect abusive clients sending 0-length asynchronous transactions to a server by enforcing limits on async_free_size. Unfortunately, on the “free” side, the accounting of async_free_space did not add the sizeof(void *) back. The result was that up to 8-bytes of async_free_space were leaked on every async transaction of 8-bytes or less. These small transactions are uncommon, so this accounting issue has gone undetected for several years. The fix is to use “buffer_size” (the allocated buffer size) instead of “size” (the logical buffer size) when updating the async_free_space during the free operation. These are the same except for this corner case of asynchronous transactions with payloads < 8 bytes. 2024-02-27 not yet calculated CVE-2021-46935
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: fix use-after-free in tw_timer_handler A real world panic issue was found as follow in Linux 5.4. BUG: unable to handle page fault for address: ffffde49a863de28 PGD 7e6fe62067 P4D 7e6fe62067 PUD 7e6fe63067 PMD f51e064067 PTE 0 RIP: 0010:tw_timer_handler+0x20/0x40 Call Trace: <IRQ> call_timer_fn+0x2b/0x120 run_timer_softirq+0x1ef/0x450 __do_softirq+0x10d/0x2b8 irq_exit+0xc7/0xd0 smp_apic_timer_interrupt+0x68/0x120 apic_timer_interrupt+0xf/0x20 This issue was also reported since 2017 in the thread [1], unfortunately, the issue was still can be reproduced after fixing DCCP. The ipv4_mib_exit_net is called before tcp_sk_exit_batch when a net namespace is destroyed since tcp_sk_ops is registered befrore ipv4_mib_ops, which means tcp_sk_ops is in the front of ipv4_mib_ops in the list of pernet_list. There will be a use-after-free on net->mib.net_statistics in tw_timer_handler after ipv4_mib_exit_net if there are some inflight time-wait timers. This bug is not introduced by commit f2bf415cfed7 (“mib: add net to NET_ADD_STATS_BH”) since the net_statistics is a global variable instead of dynamic allocation and freeing. Actually, commit 61a7e26028b9 (“mib: put net statistics on struct net”) introduces the bug since it put net statistics on struct net and free it when net namespace is destroyed. Moving init_ipv4_mibs() to the front of tcp_init() to fix this bug and replace pr_crit() with panic() since continuing is meaningless when init_ipv4_mibs() fails. [1] https://groups.google.com/g/syzkaller/c/p1tn-_Kc6l4/m/smuL_FMAAgAJ?pli=1 2024-02-27 not yet calculated CVE-2021-46936
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mm/damon/dbgfs: fix ‘struct pid’ leaks in ‘dbgfs_target_ids_write()’ DAMON debugfs interface increases the reference counts of ‘struct pid’s for targets from the ‘target_ids’ file write callback (‘dbgfs_target_ids_write()’), but decreases the counts only in DAMON monitoring termination callback (‘dbgfs_before_terminate()’). Therefore, when ‘target_ids’ file is repeatedly written without DAMON monitoring start/termination, the reference count is not decreased and therefore memory for the ‘struct pid’ cannot be freed. This commit fixes this issue by decreasing the reference counts when ‘target_ids’ is written. 2024-02-27 not yet calculated CVE-2021-46937
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dm rq: fix double free of blk_mq_tag_set in dev remove after table load fails When loading a device-mapper table for a request-based mapped device, and the allocation/initialization of the blk_mq_tag_set for the device fails, a following device remove will cause a double free. E.g. (dmesg): device-mapper: core: Cannot initialize queue for request-based dm-mq mapped device device-mapper: ioctl: unable to set up device queue for new table. Unable to handle kernel pointer dereference in virtual kernel address space Failing address: 0305e098835de000 TEID: 0305e098835de803 Fault in home space mode while using kernel ASCE. AS:000000025efe0007 R3:0000000000000024 Oops: 0038 ilc:3 [#1] SMP Modules linked in: … lots of modules … Supported: Yes, External CPU: 0 PID: 7348 Comm: multipathd Kdump: loaded Tainted: G W X 5.3.18-53-default #1 SLE15-SP3 Hardware name: IBM 8561 T01 7I2 (LPAR) Krnl PSW : 0704e00180000000 000000025e368eca (kfree+0x42/0x330) R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:2 PM:0 RI:0 EA:3 Krnl GPRS: 000000000000004a 000000025efe5230 c1773200d779968d 0000000000000000 000000025e520270 000000025e8d1b40 0000000000000003 00000007aae10000 000000025e5202a2 0000000000000001 c1773200d779968d 0305e098835de640 00000007a8170000 000003ff80138650 000000025e5202a2 000003e00396faa8 Krnl Code: 000000025e368eb8: c4180041e100 lgrl %r1,25eba50b8 000000025e368ebe: ecba06b93a55 risbg %r11,%r10,6,185,58 #000000025e368ec4: e3b010000008 ag %r11,0(%r1) >000000025e368eca: e310b0080004 lg %r1,8(%r11) 000000025e368ed0: a7110001 tmll %r1,1 000000025e368ed4: a7740129 brc 7,25e369126 000000025e368ed8: e320b0080004 lg %r2,8(%r11) 000000025e368ede: b904001b lgr %r1,%r11 Call Trace: [<000000025e368eca>] kfree+0x42/0x330 [<000000025e5202a2>] blk_mq_free_tag_set+0x72/0xb8 [<000003ff801316a8>] dm_mq_cleanup_mapped_device+0x38/0x50 [dm_mod] [<000003ff80120082>] free_dev+0x52/0xd0 [dm_mod] [<000003ff801233f0>] __dm_destroy+0x150/0x1d0 [dm_mod] [<000003ff8012bb9a>] dev_remove+0x162/0x1c0 [dm_mod] [<000003ff8012a988>] ctl_ioctl+0x198/0x478 [dm_mod] [<000003ff8012ac8a>] dm_ctl_ioctl+0x22/0x38 [dm_mod] [<000000025e3b11ee>] ksys_ioctl+0xbe/0xe0 [<000000025e3b127a>] __s390x_sys_ioctl+0x2a/0x40 [<000000025e8c15ac>] system_call+0xd8/0x2c8 Last Breaking-Event-Address: [<000000025e52029c>] blk_mq_free_tag_set+0x6c/0xb8 Kernel panic – not syncing: Fatal exception: panic_on_oops When allocation/initialization of the blk_mq_tag_set fails in dm_mq_init_request_queue(), it is uninitialized/freed, but the pointer is not reset to NULL; so when dev_remove() later gets into dm_mq_cleanup_mapped_device() it sees the pointer and tries to uninitialize and free it again. Fix this by setting the pointer to NULL in dm_mq_init_request_queue() error-handling. Also set it to NULL in dm_mq_cleanup_mapped_device(). 2024-02-27 not yet calculated CVE-2021-46938
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: tracing: Restructure trace_clock_global() to never block It was reported that a fix to the ring buffer recursion detection would cause a hung machine when performing suspend / resume testing. The following backtrace was extracted from debugging that case: Call Trace: trace_clock_global+0x91/0xa0 __rb_reserve_next+0x237/0x460 ring_buffer_lock_reserve+0x12a/0x3f0 trace_buffer_lock_reserve+0x10/0x50 __trace_graph_return+0x1f/0x80 trace_graph_return+0xb7/0xf0 ? trace_clock_global+0x91/0xa0 ftrace_return_to_handler+0x8b/0xf0 ? pv_hash+0xa0/0xa0 return_to_handler+0x15/0x30 ? ftrace_graph_caller+0xa0/0xa0 ? trace_clock_global+0x91/0xa0 ? __rb_reserve_next+0x237/0x460 ? ring_buffer_lock_reserve+0x12a/0x3f0 ? trace_event_buffer_lock_reserve+0x3c/0x120 ? trace_event_buffer_reserve+0x6b/0xc0 ? trace_event_raw_event_device_pm_callback_start+0x125/0x2d0 ? dpm_run_callback+0x3b/0xc0 ? pm_ops_is_empty+0x50/0x50 ? platform_get_irq_byname_optional+0x90/0x90 ? trace_device_pm_callback_start+0x82/0xd0 ? dpm_run_callback+0x49/0xc0 With the following RIP: RIP: 0010:native_queued_spin_lock_slowpath+0x69/0x200 Since the fix to the recursion detection would allow a single recursion to happen while tracing, this lead to the trace_clock_global() taking a spin lock and then trying to take it again: ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* lock taken */ (something else gets traced by function graph tracer) ring_buffer_lock_reserve() { trace_clock_global() { arch_spin_lock() { queued_spin_lock_slowpath() { /* DEAD LOCK! */ Tracing should *never* block, as it can lead to strange lockups like the above. Restructure the trace_clock_global() code to instead of simply taking a lock to update the recorded “prev_time” simply use it, as two events happening on two different CPUs that calls this at the same time, really doesn’t matter which one goes first. Use a trylock to grab the lock for updating the prev_time, and if it fails, simply try again the next time. If it failed to be taken, that means something else is already updating it. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=212761 2024-02-27 not yet calculated CVE-2021-46939
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: tools/power turbostat: Fix offset overflow issue in index converting The idx_to_offset() function returns type int (32-bit signed), but MSR_PKG_ENERGY_STAT is u32 and would be interpreted as a negative number. The end result is that it hits the if (offset < 0) check in update_msr_sum() which prevents the timer callback from updating the stat in the background when long durations are used. The similar issue exists in offset_to_idx() and update_msr_sum(). Fix this issue by converting the ‘int’ to ‘off_t’ accordingly. 2024-02-27 not yet calculated CVE-2021-46940
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: core: Do core softreset when switch mode According to the programming guide, to switch mode for DRD controller, the driver needs to do the following. To switch from device to host: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(host mode) 3. Reset the host with USBCMD.HCRESET 4. Then follow up with the initializing host registers sequence To switch from host to device: 1. Reset controller with GCTL.CoreSoftReset 2. Set GCTL.PrtCapDir(device mode) 3. Reset the device with DCTL.CSftRst 4. Then follow up with the initializing registers sequence Currently we’re missing step 1) to do GCTL.CoreSoftReset and step 3) of switching from host to device. John Stult reported a lockup issue seen with HiKey960 platform without these steps[1]. Similar issue is observed with Ferry’s testing platform[2]. So, apply the required steps along with some fixes to Yu Chen’s and John Stultz’s version. The main fixes to their versions are the missing wait for clocks synchronization before clearing GCTL.CoreSoftReset and only apply DCTL.CSftRst when switching from host to device. [1] https://lore.kernel.org/linux-usb/20210108015115.27920-1-john.stultz@linaro.org/ [2] https://lore.kernel.org/linux-usb/0ba7a6ba-e6a7-9cd4-0695-64fc927e01f1@gmail.com/ 2024-02-27 not yet calculated CVE-2021-46941
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: io_uring: fix shared sqpoll cancellation hangs [ 736.982891] INFO: task iou-sqp-4294:4295 blocked for more than 122 seconds. [ 736.982897] Call Trace: [ 736.982901] schedule+0x68/0xe0 [ 736.982903] io_uring_cancel_sqpoll+0xdb/0x110 [ 736.982908] io_sqpoll_cancel_cb+0x24/0x30 [ 736.982911] io_run_task_work_head+0x28/0x50 [ 736.982913] io_sq_thread+0x4e3/0x720 We call io_uring_cancel_sqpoll() one by one for each ctx either in sq_thread() itself or via task works, and it’s intended to cancel all requests of a specified context. However the function uses per-task counters to track the number of inflight requests, so it counts more requests than available via currect io_uring ctx and goes to sleep for them to appear (e.g. from IRQ), that will never happen. Cancel a bit more than before, i.e. all ctxs that share sqpoll and continue to use shared counters. Don’t forget that we should not remove ctx from the list before running that task_work sqpoll-cancel, otherwise the function wouldn’t be able to find the context and will hang. 2024-02-27 not yet calculated CVE-2021-46942
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix set_fmt error handling If there in an error during a set_fmt, do not overwrite the previous sizes with the invalid config. Without this patch, v4l2-compliance ends up allocating 4GiB of RAM and causing the following OOPs [ 38.662975] ipu3-imgu 0000:00:05.0: swiotlb buffer is full (sz: 4096 bytes) [ 38.662980] DMA: Out of SW-IOMMU space for 4096 bytes at device 0000:00:05.0 [ 38.663010] general protection fault: 0000 [#1] PREEMPT SMP 2024-02-27 not yet calculated CVE-2021-46943
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: media: staging/intel-ipu3: Fix memory leak in imu_fmt We are losing the reference to an allocated memory if try. Change the order of the check to avoid that. 2024-02-27 not yet calculated CVE-2021-46944
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ext4: always panic when errors=panic is specified Before commit 014c9caa29d3 (“ext4: make ext4_abort() use __ext4_error()”), the following series of commands would trigger a panic: 1. mount /dev/sda -o ro,errors=panic test 2. mount /dev/sda -o remount,abort test After commit 014c9caa29d3, remounting a file system using the test mount option “abort” will no longer trigger a panic. This commit will restore the behaviour immediately before commit 014c9caa29d3. (However, note that the Linux kernel’s behavior has not been consistent; some previous kernel versions, including 5.4 and 4.19 similarly did not panic after using the mount option “abort”.) This also makes a change to long-standing behaviour; namely, the following series commands will now cause a panic, when previously it did not: 1. mount /dev/sda -o ro,errors=panic test 2. echo test > /sys/fs/ext4/sda/trigger_fs_error However, this makes ext4’s behaviour much more consistent, so this is a good thing. 2024-02-27 not yet calculated CVE-2021-46945
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ext4: fix check to prevent false positive report of incorrect used inodes Commit <50122847007> (“ext4: fix check to prevent initializing reserved inodes”) check the block group zero and prevent initializing reserved inodes. But in some special cases, the reserved inode may not all belong to the group zero, it may exist into the second group if we format filesystem below. mkfs.ext4 -b 4096 -g 8192 -N 1024 -I 4096 /dev/sda So, it will end up triggering a false positive report of a corrupted file system. This patch fix it by avoid check reserved inodes if no free inode blocks will be zeroed. 2024-02-27 not yet calculated CVE-2021-46946
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: sfc: adjust efx->xdp_tx_queue_count with the real number of initialized queues efx->xdp_tx_queue_count is initially initialized to num_possible_cpus() and is later used to allocate and traverse efx->xdp_tx_queues lookup array. However, we may end up not initializing all the array slots with real queues during probing. This results, for example, in a NULL pointer dereference, when running “# ethtool -S <iface>”, similar to below [2570283.664955][T4126959] BUG: kernel NULL pointer dereference, address: 00000000000000f8 [2570283.681283][T4126959] #PF: supervisor read access in kernel mode [2570283.695678][T4126959] #PF: error_code(0x0000) – not-present page [2570283.710013][T4126959] PGD 0 P4D 0 [2570283.721649][T4126959] Oops: 0000 [#1] SMP PTI [2570283.734108][T4126959] CPU: 23 PID: 4126959 Comm: ethtool Tainted: G O 5.10.20-cloudflare-2021.3.1 #1 [2570283.752641][T4126959] Hardware name: <redacted> [2570283.781408][T4126959] RIP: 0010:efx_ethtool_get_stats+0x2ca/0x330 [sfc] [2570283.796073][T4126959] Code: 00 85 c0 74 39 48 8b 95 a8 0f 00 00 48 85 d2 74 2d 31 c0 eb 07 48 8b 95 a8 0f 00 00 48 63 c8 49 83 c4 08 83 c0 01 48 8b 14 ca <48> 8b 92 f8 00 00 00 49 89 54 24 f8 39 85 a0 0f 00 00 77 d7 48 8b [2570283.831259][T4126959] RSP: 0018:ffffb79a77657ce8 EFLAGS: 00010202 [2570283.845121][T4126959] RAX: 0000000000000019 RBX: ffffb799cd0c9280 RCX: 0000000000000018 [2570283.860872][T4126959] RDX: 0000000000000000 RSI: ffff96dd970ce000 RDI: 0000000000000005 [2570283.876525][T4126959] RBP: ffff96dd86f0a000 R08: ffff96dd970ce480 R09: 000000000000005f [2570283.892014][T4126959] R10: ffffb799cd0c9fff R11: ffffb799cd0c9000 R12: ffffb799cd0c94f8 [2570283.907406][T4126959] R13: ffffffffc11b1090 R14: ffff96dd970ce000 R15: ffffffffc11cd66c [2570283.922705][T4126959] FS: 00007fa7723f8740(0000) GS:ffff96f51fac0000(0000) knlGS:0000000000000000 [2570283.938848][T4126959] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [2570283.952524][T4126959] CR2: 00000000000000f8 CR3: 0000001a73e6e006 CR4: 00000000007706e0 [2570283.967529][T4126959] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [2570283.982400][T4126959] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [2570283.997308][T4126959] PKRU: 55555554 [2570284.007649][T4126959] Call Trace: [2570284.017598][T4126959] dev_ethtool+0x1832/0x2830 Fix this by adjusting efx->xdp_tx_queue_count after probing to reflect the true value of initialized slots in efx->xdp_tx_queues. 2024-02-27 not yet calculated CVE-2021-46947
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX event handling We’re starting from a TXQ label, not a TXQ type, so efx_channel_get_tx_queue() is inappropriate (and could return NULL, leading to panics). 2024-02-27 not yet calculated CVE-2021-46948
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: sfc: farch: fix TX queue lookup in TX flush done handling We’re starting from a TXQ instance number (‘qid’), not a TXQ type, so efx_get_tx_queue() is inappropriate (and could return NULL, leading to panics). 2024-02-27 not yet calculated CVE-2021-46949
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: md/raid1: properly indicate failure when ending a failed write request This patch addresses a data corruption bug in raid1 arrays using bitmaps. Without this fix, the bitmap bits for the failed I/O end up being cleared. Since we are in the failure leg of raid1_end_write_request, the request either needs to be retried (R1BIO_WriteError) or failed (R1BIO_Degraded). 2024-02-27 not yet calculated CVE-2021-46950
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: tpm: efi: Use local variable for calculating final log size When tpm_read_log_efi is called multiple times, which happens when one loads and unloads a TPM2 driver multiple times, then the global variable efi_tpm_final_log_size will at some point become a negative number due to the subtraction of final_events_preboot_size occurring each time. Use a local variable to avoid this integer underflow. The following issue is now resolved: Mar 8 15:35:12 hibinst kernel: Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 Mar 8 15:35:12 hibinst kernel: Workqueue: tpm-vtpm vtpm_proxy_work [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: RIP: 0010:__memcpy+0x12/0x20 Mar 8 15:35:12 hibinst kernel: Code: 00 b8 01 00 00 00 85 d2 74 0a c7 05 44 7b ef 00 0f 00 00 00 c3 cc cc cc 66 66 90 66 90 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 <f3> 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 Mar 8 15:35:12 hibinst kernel: RSP: 0018:ffff9ac4c0fcfde0 EFLAGS: 00010206 Mar 8 15:35:12 hibinst kernel: RAX: ffff88f878cefed5 RBX: ffff88f878ce9000 RCX: 1ffffffffffffe0f Mar 8 15:35:12 hibinst kernel: RDX: 0000000000000003 RSI: ffff9ac4c003bff9 RDI: ffff88f878cf0e4d Mar 8 15:35:12 hibinst kernel: RBP: ffff9ac4c003b000 R08: 0000000000001000 R09: 000000007e9d6073 Mar 8 15:35:12 hibinst kernel: R10: ffff9ac4c003b000 R11: ffff88f879ad3500 R12: 0000000000000ed5 Mar 8 15:35:12 hibinst kernel: R13: ffff88f878ce9760 R14: 0000000000000002 R15: ffff88f77de7f018 Mar 8 15:35:12 hibinst kernel: FS: 0000000000000000(0000) GS:ffff88f87bd00000(0000) knlGS:0000000000000000 Mar 8 15:35:12 hibinst kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Mar 8 15:35:12 hibinst kernel: CR2: ffff9ac4c003c000 CR3: 00000001785a6004 CR4: 0000000000060ee0 Mar 8 15:35:12 hibinst kernel: Call Trace: Mar 8 15:35:12 hibinst kernel: tpm_read_log_efi+0x152/0x1a7 Mar 8 15:35:12 hibinst kernel: tpm_bios_log_setup+0xc8/0x1c0 Mar 8 15:35:12 hibinst kernel: tpm_chip_register+0x8f/0x260 Mar 8 15:35:12 hibinst kernel: vtpm_proxy_work+0x16/0x60 [tpm_vtpm_proxy] Mar 8 15:35:12 hibinst kernel: process_one_work+0x1b4/0x370 Mar 8 15:35:12 hibinst kernel: worker_thread+0x53/0x3e0 Mar 8 15:35:12 hibinst kernel: ? process_one_work+0x370/0x370 2024-02-27 not yet calculated CVE-2021-46951
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: NFS: fs_context: validate UDP retrans to prevent shift out-of-bounds Fix shift out-of-bounds in xprt_calc_majortimeo(). This is caused by a garbage timeout (retrans) mount option being passed to nfs mount, in this case from syzkaller. If the protocol is XPRT_TRANSPORT_UDP, then ‘retrans’ is a shift value for a 64-bit long integer, so ‘retrans’ cannot be >= 64. If it is >= 64, fail the mount and return an error. 2024-02-27 not yet calculated CVE-2021-46952
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ACPI: GTDT: Don’t corrupt interrupt mappings on watchdow probe failure When failing the driver probe because of invalid firmware properties, the GTDT driver unmaps the interrupt that it mapped earlier. However, it never checks whether the mapping of the interrupt actially succeeded. Even more, should the firmware report an illegal interrupt number that overlaps with the GIC SGI range, this can result in an IPI being unmapped, and subsequent fireworks (as reported by Dann Frazier). Rework the driver to have a slightly saner behaviour and actually check whether the interrupt has been mapped before unmapping things. 2024-02-27 not yet calculated CVE-2021-46953
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net/sched: sch_frag: fix stack OOB read while fragmenting IPv4 packets when ‘act_mirred’ tries to fragment IPv4 packets that had been previously re-assembled using ‘act_ct’, splats like the following can be observed on kernels built with KASAN: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888147009574 by task ping/947 CPU: 0 PID: 947 Comm: ping Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: <IRQ> dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 sch_fragment+0x4bf/0xe40 tcf_mirred_act+0xc3d/0x11a0 [act_mirred] tcf_action_exec+0x104/0x3e0 fl_classify+0x49a/0x5e0 [cls_flower] tcf_classify_ingress+0x18a/0x820 __netif_receive_skb_core+0xae7/0x3340 __netif_receive_skb_one_core+0xb6/0x1b0 process_backlog+0x1ef/0x6c0 __napi_poll+0xaa/0x500 net_rx_action+0x702/0xac0 __do_softirq+0x1e4/0x97f do_softirq+0x71/0x90 </IRQ> __local_bh_enable_ip+0xdb/0xf0 ip_finish_output2+0x760/0x2120 ip_do_fragment+0x15a5/0x1f60 __ip_finish_output+0x4c2/0xea0 ip_output+0x1ca/0x4d0 ip_send_skb+0x37/0xa0 raw_sendmsg+0x1c4b/0x2d00 sock_sendmsg+0xdb/0x110 __sys_sendto+0x1d7/0x2b0 __x64_sys_sendto+0xdd/0x1b0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f82e13853eb Code: 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 f3 0f 1e fa 48 8d 05 75 42 2c 00 41 89 ca 8b 00 85 c0 75 14 b8 2c 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 75 c3 0f 1f 40 00 41 57 4d 89 c7 41 56 41 89 RSP: 002b:00007ffe01fad888 EFLAGS: 00000246 ORIG_RAX: 000000000000002c RAX: ffffffffffffffda RBX: 00005571aac13700 RCX: 00007f82e13853eb RDX: 0000000000002330 RSI: 00005571aac13700 RDI: 0000000000000003 RBP: 0000000000002330 R08: 00005571aac10500 R09: 0000000000000010 R10: 0000000000000000 R11: 0000000000000246 R12: 00007ffe01faefb0 R13: 00007ffe01fad890 R14: 00007ffe01fad980 R15: 00005571aac0f0a0 The buggy address belongs to the page: page:000000001dff2e03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x147009 flags: 0x17ffffc0001000(reserved) raw: 0017ffffc0001000 ffffea00051c0248 ffffea00051c0248 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffff888147009400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009480: f1 f1 f1 f1 04 f2 f2 f2 f2 f2 f2 f2 00 00 00 00 >ffff888147009500: 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 f2 f2 f2 ^ ffff888147009580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888147009600: 00 00 00 00 00 00 00 00 00 00 00 00 00 f2 f2 f2 for IPv4 packets, sch_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in sch_fragment(), similarly to what is done for IPv6 few lines below. 2024-02-27 not yet calculated CVE-2021-46954
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: openvswitch: fix stack OOB read while fragmenting IPv4 packets running openvswitch on kernels built with KASAN, it’s possible to see the following splat while testing fragmentation of IPv4 packets: BUG: KASAN: stack-out-of-bounds in ip_do_fragment+0x1b03/0x1f60 Read of size 1 at addr ffff888112fc713c by task handler2/1367 CPU: 0 PID: 1367 Comm: handler2 Not tainted 5.12.0-rc6+ #418 Hardware name: Red Hat KVM, BIOS 1.11.1-4.module+el8.1.0+4066+0f1aadab 04/01/2014 Call Trace: dump_stack+0x92/0xc1 print_address_description.constprop.7+0x1a/0x150 kasan_report.cold.13+0x7f/0x111 ip_do_fragment+0x1b03/0x1f60 ovs_fragment+0x5bf/0x840 [openvswitch] do_execute_actions+0x1bd5/0x2400 [openvswitch] ovs_execute_actions+0xc8/0x3d0 [openvswitch] ovs_packet_cmd_execute+0xa39/0x1150 [openvswitch] genl_family_rcv_msg_doit.isra.15+0x227/0x2d0 genl_rcv_msg+0x287/0x490 netlink_rcv_skb+0x120/0x380 genl_rcv+0x24/0x40 netlink_unicast+0x439/0x630 netlink_sendmsg+0x719/0xbf0 sock_sendmsg+0xe2/0x110 ____sys_sendmsg+0x5ba/0x890 ___sys_sendmsg+0xe9/0x160 __sys_sendmsg+0xd3/0x170 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f957079db07 Code: c3 66 90 41 54 41 89 d4 55 48 89 f5 53 89 fb 48 83 ec 10 e8 eb ec ff ff 44 89 e2 48 89 ee 89 df 41 89 c0 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 48 89 44 24 08 e8 24 ed ff ff 48 RSP: 002b:00007f956ce35a50 EFLAGS: 00000293 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 0000000000000019 RCX: 00007f957079db07 RDX: 0000000000000000 RSI: 00007f956ce35ae0 RDI: 0000000000000019 RBP: 00007f956ce35ae0 R08: 0000000000000000 R09: 00007f9558006730 R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000 R13: 00007f956ce37308 R14: 00007f956ce35f80 R15: 00007f956ce35ae0 The buggy address belongs to the page: page:00000000af2a1d93 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x112fc7 flags: 0x17ffffc0000000() raw: 0017ffffc0000000 0000000000000000 dead000000000122 0000000000000000 raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000 page dumped because: kasan: bad access detected addr ffff888112fc713c is located in stack of task handler2/1367 at offset 180 in frame: ovs_fragment+0x0/0x840 [openvswitch] this frame has 2 objects: [32, 144) ‘ovs_dst’ [192, 424) ‘ovs_rt’ Memory state around the buggy address: ffff888112fc7000: f3 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7080: 00 f1 f1 f1 f1 00 00 00 00 00 00 00 00 00 00 00 >ffff888112fc7100: 00 00 00 f2 f2 f2 f2 f2 f2 00 00 00 00 00 00 00 ^ ffff888112fc7180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ffff888112fc7200: 00 00 00 00 00 00 f2 f2 f2 00 00 00 00 00 00 00 for IPv4 packets, ovs_fragment() uses a temporary struct dst_entry. Then, in the following call graph: ip_do_fragment() ip_skb_dst_mtu() ip_dst_mtu_maybe_forward() ip_mtu_locked() the pointer to struct dst_entry is used as pointer to struct rtable: this turns the access to struct members like rt_mtu_locked into an OOB read in the stack. Fix this changing the temporary variable used for IPv4 packets in ovs_fragment(), similarly to what is done for IPv6 few lines below. 2024-02-27 not yet calculated CVE-2021-46955
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: virtiofs: fix memory leak in virtio_fs_probe() When accidentally passing twice the same tag to qemu, kmemleak ended up reporting a memory leak in virtiofs. Also, looking at the log I saw the following error (that’s when I realised the duplicated tag): virtiofs: probe of virtio5 failed with error -17 Here’s the kmemleak log for reference: unreferenced object 0xffff888103d47800 (size 1024): comm “systemd-udevd”, pid 118, jiffies 4294893780 (age 18.340s) hex dump (first 32 bytes): 00 00 00 00 ad 4e ad de ff ff ff ff 00 00 00 00 …..N………. ff ff ff ff ff ff ff ff 80 90 02 a0 ff ff ff ff ……………. backtrace: [<000000000ebb87c1>] virtio_fs_probe+0x171/0x7ae [virtiofs] [<00000000f8aca419>] virtio_dev_probe+0x15f/0x210 [<000000004d6baf3c>] really_probe+0xea/0x430 [<00000000a6ceeac8>] device_driver_attach+0xa8/0xb0 [<00000000196f47a7>] __driver_attach+0x98/0x140 [<000000000b20601d>] bus_for_each_dev+0x7b/0xc0 [<00000000399c7b7f>] bus_add_driver+0x11b/0x1f0 [<0000000032b09ba7>] driver_register+0x8f/0xe0 [<00000000cdd55998>] 0xffffffffa002c013 [<000000000ea196a2>] do_one_initcall+0x64/0x2e0 [<0000000008f727ce>] do_init_module+0x5c/0x260 [<000000003cdedab6>] __do_sys_finit_module+0xb5/0x120 [<00000000ad2f48c6>] do_syscall_64+0x33/0x40 [<00000000809526b5>] entry_SYSCALL_64_after_hwframe+0x44/0xae 2024-02-27 not yet calculated CVE-2021-46956
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: riscv/kprobe: fix kernel panic when invoking sys_read traced by kprobe The execution of sys_read end up hitting a BUG_ON() in __find_get_block after installing kprobe at sys_read, the BUG message like the following: [ 65.708663] ————[ cut here ]———— [ 65.709987] kernel BUG at fs/buffer.c:1251! [ 65.711283] Kernel BUG [#1] [ 65.712032] Modules linked in: [ 65.712925] CPU: 0 PID: 51 Comm: sh Not tainted 5.12.0-rc4 #1 [ 65.714407] Hardware name: riscv-virtio,qemu (DT) [ 65.715696] epc : __find_get_block+0x218/0x2c8 [ 65.716835] ra : __getblk_gfp+0x1c/0x4a [ 65.717831] epc : ffffffe00019f11e ra : ffffffe00019f56a sp : ffffffe002437930 [ 65.719553] gp : ffffffe000f06030 tp : ffffffe0015abc00 t0 : ffffffe00191e038 [ 65.721290] t1 : ffffffe00191e038 t2 : 000000000000000a s0 : ffffffe002437960 [ 65.723051] s1 : ffffffe00160ad00 a0 : ffffffe00160ad00 a1 : 000000000000012a [ 65.724772] a2 : 0000000000000400 a3 : 0000000000000008 a4 : 0000000000000040 [ 65.726545] a5 : 0000000000000000 a6 : ffffffe00191e000 a7 : 0000000000000000 [ 65.728308] s2 : 000000000000012a s3 : 0000000000000400 s4 : 0000000000000008 [ 65.730049] s5 : 000000000000006c s6 : ffffffe00240f800 s7 : ffffffe000f080a8 [ 65.731802] s8 : 0000000000000001 s9 : 000000000000012a s10: 0000000000000008 [ 65.733516] s11: 0000000000000008 t3 : 00000000000003ff t4 : 000000000000000f [ 65.734434] t5 : 00000000000003ff t6 : 0000000000040000 [ 65.734613] status: 0000000000000100 badaddr: 0000000000000000 cause: 0000000000000003 [ 65.734901] Call Trace: [ 65.735076] [<ffffffe00019f11e>] __find_get_block+0x218/0x2c8 [ 65.735417] [<ffffffe00020017a>] __ext4_get_inode_loc+0xb2/0x2f6 [ 65.735618] [<ffffffe000201b6c>] ext4_get_inode_loc+0x3a/0x8a [ 65.735802] [<ffffffe000203380>] ext4_reserve_inode_write+0x2e/0x8c [ 65.735999] [<ffffffe00020357a>] __ext4_mark_inode_dirty+0x4c/0x18e [ 65.736208] [<ffffffe000206bb0>] ext4_dirty_inode+0x46/0x66 [ 65.736387] [<ffffffe000192914>] __mark_inode_dirty+0x12c/0x3da [ 65.736576] [<ffffffe000180dd2>] touch_atime+0x146/0x150 [ 65.736748] [<ffffffe00010d762>] filemap_read+0x234/0x246 [ 65.736920] [<ffffffe00010d834>] generic_file_read_iter+0xc0/0x114 [ 65.737114] [<ffffffe0001f5d7a>] ext4_file_read_iter+0x42/0xea [ 65.737310] [<ffffffe000163f2c>] new_sync_read+0xe2/0x15a [ 65.737483] [<ffffffe000165814>] vfs_read+0xca/0xf2 [ 65.737641] [<ffffffe000165bae>] ksys_read+0x5e/0xc8 [ 65.737816] [<ffffffe000165c26>] sys_read+0xe/0x16 [ 65.737973] [<ffffffe000003972>] ret_from_syscall+0x0/0x2 [ 65.738858] —[ end trace fe93f985456c935d ]— A simple reproducer looks like: echo ‘p:myprobe sys_read fd=%a0 buf=%a1 count=%a2’ > /sys/kernel/debug/tracing/kprobe_events echo 1 > /sys/kernel/debug/tracing/events/kprobes/myprobe/enable cat /sys/kernel/debug/tracing/trace Here’s what happens to hit that BUG_ON(): 1) After installing kprobe at entry of sys_read, the first instruction is replaced by ‘ebreak’ instruction on riscv64 platform. 2) Once kernel reach the ‘ebreak’ instruction at the entry of sys_read, it trap into the riscv breakpoint handler, where it do something to setup for coming single-step of origin instruction, including backup the ‘sstatus’ in pt_regs, followed by disable interrupt during single stepping via clear ‘SIE’ bit of ‘sstatus’ in pt_regs. 3) Then kernel restore to the instruction slot contains two instructions, one is original instruction at entry of sys_read, the other is ‘ebreak’. Here it trigger a ‘Instruction page fault’ exception (value at ‘scause’ is ‘0xc’), if PF is not filled into PageTabe for that slot yet. 4) Again kernel trap into page fault exception handler, where it choose different policy according to the state of running kprobe. Because afte 2) the state is KPROBE_HIT_SS, so kernel reset the current kp —truncated— 2024-02-27 not yet calculated CVE-2021-46957
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: btrfs: fix race between transaction aborts and fsyncs leading to use-after-free There is a race between a task aborting a transaction during a commit, a task doing an fsync and the transaction kthread, which leads to an use-after-free of the log root tree. When this happens, it results in a stack trace like the following: BTRFS info (device dm-0): forced readonly BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS: error (device dm-0) in cleanup_transaction:1958: errno=-5 IO failure BTRFS warning (device dm-0): lost page write due to IO error on /dev/mapper/error-test (-5) BTRFS warning (device dm-0): Skipping commit of aborted transaction. BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0xa4e8 len 4096 err no 10 BTRFS error (device dm-0): error writing primary super block to device 1 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e000 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e008 len 4096 err no 10 BTRFS warning (device dm-0): direct IO failed ino 261 rw 0,0 sector 0x12e010 len 4096 err no 10 BTRFS: error (device dm-0) in write_all_supers:4110: errno=-5 IO failure (1 errors while writing supers) BTRFS: error (device dm-0) in btrfs_sync_log:3308: errno=-5 IO failure general protection fault, probably for non-canonical address 0x6b6b6b6b6b6b6b68: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC PTI CPU: 2 PID: 2458471 Comm: fsstress Not tainted 5.12.0-rc5-btrfs-next-84 #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014 RIP: 0010:__mutex_lock+0x139/0xa40 Code: c0 74 19 (…) RSP: 0018:ffff9f18830d7b00 EFLAGS: 00010202 RAX: 6b6b6b6b6b6b6b68 RBX: 0000000000000001 RCX: 0000000000000002 RDX: ffffffffb9c54d13 RSI: 0000000000000000 RDI: 0000000000000000 RBP: ffff9f18830d7bc0 R08: 0000000000000000 R09: 0000000000000000 R10: ffff9f18830d7be0 R11: 0000000000000001 R12: ffff8c6cd199c040 R13: ffff8c6c95821358 R14: 00000000fffffffb R15: ffff8c6cbcf01358 FS: 00007fa9140c2b80(0000) GS:ffff8c6fac600000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fa913d52000 CR3: 000000013d2b4003 CR4: 0000000000370ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? __btrfs_handle_fs_error+0xde/0x146 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] ? btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_log+0x7c1/0xf20 [btrfs] btrfs_sync_file+0x40c/0x580 [btrfs] do_fsync+0x38/0x70 __x64_sys_fsync+0x10/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7fa9142a55c3 Code: 8b 15 09 (…) RSP: 002b:00007fff26278d48 EFLAGS: 00000246 ORIG_RAX: 000000000000004a RAX: ffffffffffffffda RBX: 0000563c83cb4560 RCX: 00007fa9142a55c3 RDX: 00007fff26278cb0 RSI: 00007fff26278cb0 RDI: 0000000000000005 RBP: 0000000000000005 R08: 0000000000000001 R09: 00007fff26278d5c R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000340 R13: 00007fff26278de0 R14: 00007fff26278d96 R15: 0000563c83ca57c0 Modules linked in: btrfs dm_zero dm_snapshot dm_thin_pool (…) —[ end trace ee2f1b19327d791d ]— The steps that lead to this crash are the following: 1) We are at transaction N; 2) We have two tasks with a transaction handle attached to transaction N. Task A and Task B. Task B is doing an fsync; 3) Task B is at btrfs_sync_log(), and has saved fs_info->log_root_tree into a local variable named ‘log_root_tree’ at the top of btrfs_sync_log(). Task B is about to call write_all_supers(), but before that… 4) Task A calls btrfs_commit_transaction(), and after it sets the transaction state to TRANS_STATE_COMMIT_START, an error happens before it w —truncated— 2024-02-27 not yet calculated CVE-2021-46958
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: spi: Fix use-after-free with devm_spi_alloc_* We can’t rely on the contents of the devres list during spi_unregister_controller(), as the list is already torn down at the time we perform devres_find() for devm_spi_release_controller. This causes devices registered with devm_spi_alloc_{master,slave}() to be mistakenly identified as legacy, non-devm managed devices and have their reference counters decremented below 0. ————[ cut here ]———— WARNING: CPU: 1 PID: 660 at lib/refcount.c:28 refcount_warn_saturate+0x108/0x174 [<b0396f04>] (refcount_warn_saturate) from [<b03c56a4>] (kobject_put+0x90/0x98) [<b03c5614>] (kobject_put) from [<b0447b4c>] (put_device+0x20/0x24) r4:b6700140 [<b0447b2c>] (put_device) from [<b07515e8>] (devm_spi_release_controller+0x3c/0x40) [<b07515ac>] (devm_spi_release_controller) from [<b045343c>] (release_nodes+0x84/0xc4) r5:b6700180 r4:b6700100 [<b04533b8>] (release_nodes) from [<b0454160>] (devres_release_all+0x5c/0x60) r8:b1638c54 r7:b117ad94 r6:b1638c10 r5:b117ad94 r4:b163dc10 [<b0454104>] (devres_release_all) from [<b044e41c>] (__device_release_driver+0x144/0x1ec) r5:b117ad94 r4:b163dc10 [<b044e2d8>] (__device_release_driver) from [<b044f70c>] (device_driver_detach+0x84/0xa0) r9:00000000 r8:00000000 r7:b117ad94 r6:b163dc54 r5:b1638c10 r4:b163dc10 [<b044f688>] (device_driver_detach) from [<b044d274>] (unbind_store+0xe4/0xf8) Instead, determine the devm allocation state as a flag on the controller which is guaranteed to be stable during cleanup. 2024-02-29 not yet calculated CVE-2021-46959
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: cifs: Return correct error code from smb2_get_enc_key Avoid a warning if the error percolates back up: [440700.376476] CIFS VFS: \otters.example.com crypt_message: Could not get encryption key [440700.386947] ————[ cut here ]———— [440700.386948] err = 1 [440700.386977] WARNING: CPU: 11 PID: 2733 at /build/linux-hwe-5.4-p6lk6L/linux-hwe-5.4-5.4.0/lib/errseq.c:74 errseq_set+0x5c/0x70 … [440700.397304] CPU: 11 PID: 2733 Comm: tar Tainted: G OE 5.4.0-70-generic #78~18.04.1-Ubuntu … [440700.397334] Call Trace: [440700.397346] __filemap_set_wb_err+0x1a/0x70 [440700.397419] cifs_writepages+0x9c7/0xb30 [cifs] [440700.397426] do_writepages+0x4b/0xe0 [440700.397444] __filemap_fdatawrite_range+0xcb/0x100 [440700.397455] filemap_write_and_wait+0x42/0xa0 [440700.397486] cifs_setattr+0x68b/0xf30 [cifs] [440700.397493] notify_change+0x358/0x4a0 [440700.397500] utimes_common+0xe9/0x1c0 [440700.397510] do_utimes+0xc5/0x150 [440700.397520] __x64_sys_utimensat+0x88/0xd0 2024-02-27 not yet calculated CVE-2021-46960
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: irqchip/gic-v3: Do not enable irqs when handling spurious interrups We triggered the following error while running our 4.19 kernel with the pseudo-NMI patches backported to it: [ 14.816231] ————[ cut here ]———— [ 14.816231] kernel BUG at irq.c:99! [ 14.816232] Internal error: Oops – BUG: 0 [#1] SMP [ 14.816232] Process swapper/0 (pid: 0, stack limit = 0x(____ptrval____)) [ 14.816233] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G O 4.19.95.aarch64 #14 [ 14.816233] Hardware name: evb (DT) [ 14.816234] pstate: 80400085 (Nzcv daIf +PAN -UAO) [ 14.816234] pc : asm_nmi_enter+0x94/0x98 [ 14.816235] lr : asm_nmi_enter+0x18/0x98 [ 14.816235] sp : ffff000008003c50 [ 14.816235] pmr_save: 00000070 [ 14.816237] x29: ffff000008003c50 x28: ffff0000095f56c0 [ 14.816238] x27: 0000000000000000 x26: ffff000008004000 [ 14.816239] x25: 00000000015e0000 x24: ffff8008fb916000 [ 14.816240] x23: 0000000020400005 x22: ffff0000080817cc [ 14.816241] x21: ffff000008003da0 x20: 0000000000000060 [ 14.816242] x19: 00000000000003ff x18: ffffffffffffffff [ 14.816243] x17: 0000000000000008 x16: 003d090000000000 [ 14.816244] x15: ffff0000095ea6c8 x14: ffff8008fff5ab40 [ 14.816244] x13: ffff8008fff58b9d x12: 0000000000000000 [ 14.816245] x11: ffff000008c8a200 x10: 000000008e31fca5 [ 14.816246] x9 : ffff000008c8a208 x8 : 000000000000000f [ 14.816247] x7 : 0000000000000004 x6 : ffff8008fff58b9e [ 14.816248] x5 : 0000000000000000 x4 : 0000000080000000 [ 14.816249] x3 : 0000000000000000 x2 : 0000000080000000 [ 14.816250] x1 : 0000000000120000 x0 : ffff0000095f56c0 [ 14.816251] Call trace: [ 14.816251] asm_nmi_enter+0x94/0x98 [ 14.816251] el1_irq+0x8c/0x180 (IRQ C) [ 14.816252] gic_handle_irq+0xbc/0x2e4 [ 14.816252] el1_irq+0xcc/0x180 (IRQ B) [ 14.816253] arch_timer_handler_virt+0x38/0x58 [ 14.816253] handle_percpu_devid_irq+0x90/0x240 [ 14.816253] generic_handle_irq+0x34/0x50 [ 14.816254] __handle_domain_irq+0x68/0xc0 [ 14.816254] gic_handle_irq+0xf8/0x2e4 [ 14.816255] el1_irq+0xcc/0x180 (IRQ A) [ 14.816255] arch_cpu_idle+0x34/0x1c8 [ 14.816255] default_idle_call+0x24/0x44 [ 14.816256] do_idle+0x1d0/0x2c8 [ 14.816256] cpu_startup_entry+0x28/0x30 [ 14.816256] rest_init+0xb8/0xc8 [ 14.816257] start_kernel+0x4c8/0x4f4 [ 14.816257] Code: 940587f1 d5384100 b9401001 36a7fd01 (d4210000) [ 14.816258] Modules linked in: start_dp(O) smeth(O) [ 15.103092] —[ end trace 701753956cb14aa8 ]— [ 15.103093] Kernel panic – not syncing: Fatal exception in interrupt [ 15.103099] SMP: stopping secondary CPUs [ 15.103100] Kernel Offset: disabled [ 15.103100] CPU features: 0x36,a2400218 [ 15.103100] Memory Limit: none which is cause by a ‘BUG_ON(in_nmi())’ in nmi_enter(). From the call trace, we can find three interrupts (noted A, B, C above): interrupt (A) is preempted by (B), which is further interrupted by (C). Subsequent investigations show that (B) results in nmi_enter() being called, but that it actually is a spurious interrupt. Furthermore, interrupts are reenabled in the context of (B), and (C) fires with NMI priority. We end-up with a nested NMI situation, something we definitely do not want to (and cannot) handle. The bug here is that spurious interrupts should never result in any state change, and we should just return to the interrupted context. Moving the handling of spurious interrupts as early as possible in the GICv3 handler fixes this issue. [maz: rewrote commit message, corrected Fixes: tag] 2024-02-27 not yet calculated CVE-2021-46961
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mmc: uniphier-sd: Fix a resource leak in the remove function A ‘tmio_mmc_host_free()’ call is missing in the remove function, in order to balance a ‘tmio_mmc_host_alloc()’ call in the probe. This is done in the error handling path of the probe, but not in the remove function. Add the missing call. 2024-02-27 not yet calculated CVE-2021-46962
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Fix crash in qla2xxx_mqueuecommand() RIP: 0010:kmem_cache_free+0xfa/0x1b0 Call Trace: qla2xxx_mqueuecommand+0x2b5/0x2c0 [qla2xxx] scsi_queue_rq+0x5e2/0xa40 __blk_mq_try_issue_directly+0x128/0x1d0 blk_mq_request_issue_directly+0x4e/0xb0 Fix incorrect call to free srb in qla2xxx_mqueuecommand(), as srb is now allocated by upper layers. This fixes smatch warning of srb unintended free. 2024-02-27 not yet calculated CVE-2021-46963
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: scsi: qla2xxx: Reserve extra IRQ vectors Commit a6dcfe08487e (“scsi: qla2xxx: Limit interrupt vectors to number of CPUs”) lowers the number of allocated MSI-X vectors to the number of CPUs. That breaks vector allocation assumptions in qla83xx_iospace_config(), qla24xx_enable_msix() and qla2x00_iospace_config(). Either of the functions computes maximum number of qpairs as: ha->max_qpairs = ha->msix_count – 1 (MB interrupt) – 1 (default response queue) – 1 (ATIO, in dual or pure target mode) max_qpairs is set to zero in case of two CPUs and initiator mode. The number is then used to allocate ha->queue_pair_map inside qla2x00_alloc_queues(). No allocation happens and ha->queue_pair_map is left NULL but the driver thinks there are queue pairs available. qla2xxx_queuecommand() tries to find a qpair in the map and crashes: if (ha->mqenable) { uint32_t tag; uint16_t hwq; struct qla_qpair *qpair = NULL; tag = blk_mq_unique_tag(cmd->request); hwq = blk_mq_unique_tag_to_hwq(tag); qpair = ha->queue_pair_map[hwq]; # <- HERE if (qpair) return qla2xxx_mqueuecommand(host, cmd, qpair); } BUG: kernel NULL pointer dereference, address: 0000000000000000 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) – not-present page PGD 0 P4D 0 Oops: 0000 [#1] SMP PTI CPU: 0 PID: 72 Comm: kworker/u4:3 Tainted: G W 5.10.0-rc1+ #25 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014 Workqueue: scsi_wq_7 fc_scsi_scan_rport [scsi_transport_fc] RIP: 0010:qla2xxx_queuecommand+0x16b/0x3f0 [qla2xxx] Call Trace: scsi_queue_rq+0x58c/0xa60 blk_mq_dispatch_rq_list+0x2b7/0x6f0 ? __sbitmap_get_word+0x2a/0x80 __blk_mq_sched_dispatch_requests+0xb8/0x170 blk_mq_sched_dispatch_requests+0x2b/0x50 __blk_mq_run_hw_queue+0x49/0xb0 __blk_mq_delay_run_hw_queue+0xfb/0x150 blk_mq_sched_insert_request+0xbe/0x110 blk_execute_rq+0x45/0x70 __scsi_execute+0x10e/0x250 scsi_probe_and_add_lun+0x228/0xda0 __scsi_scan_target+0xf4/0x620 ? __pm_runtime_resume+0x4f/0x70 scsi_scan_target+0x100/0x110 fc_scsi_scan_rport+0xa1/0xb0 [scsi_transport_fc] process_one_work+0x1ea/0x3b0 worker_thread+0x28/0x3b0 ? process_one_work+0x3b0/0x3b0 kthread+0x112/0x130 ? kthread_park+0x80/0x80 ret_from_fork+0x22/0x30 The driver should allocate enough vectors to provide every CPU it’s own HW queue and still handle reserved (MB, RSP, ATIO) interrupts. The change fixes the crash on dual core VM and prevents unbalanced QP allocation where nr_hw_queues is two less than the number of CPUs. 2024-02-27 not yet calculated CVE-2021-46964
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mtd: physmap: physmap-bt1-rom: Fix unintentional stack access Cast &data to (char *) in order to avoid unintentionally accessing the stack. Notice that data is of type u32, so any increment to &data will be in the order of 4-byte chunks, and this piece of code is actually intended to be a byte offset. Addresses-Coverity-ID: 1497765 (“Out-of-bounds access”) 2024-02-27 not yet calculated CVE-2021-46965
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ACPI: custom_method: fix potential use-after-free issue In cm_write(), buf is always freed when reaching the end of the function. If the requested count is less than table.length, the allocated buffer will be freed but subsequent calls to cm_write() will still try to access it. Remove the unconditional kfree(buf) at the end of the function and set the buf to NULL in the -EINVAL error path to match the rest of function. 2024-02-27 not yet calculated CVE-2021-46966
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: vhost-vdpa: fix vm_flags for virtqueue doorbell mapping The virtqueue doorbell is usually implemented via registeres but we don’t provide the necessary vma->flags like VM_PFNMAP. This may cause several issues e.g when userspace tries to map the doorbell via vhost IOTLB, kernel may panic due to the page is not backed by page structure. This patch fixes this by setting the necessary vm_flags. With this patch, try to map doorbell via IOTLB will fail with bad address. 2024-02-27 not yet calculated CVE-2021-46967
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: s390/zcrypt: fix zcard and zqueue hot-unplug memleak Tests with kvm and a kmemdebug kernel showed, that on hot unplug the zcard and zqueue structs for the unplugged card or queue are not properly freed because of a mismatch with get/put for the embedded kref counter. This fix now adjusts the handling of the kref counters. With init the kref counter starts with 1. This initial value needs to drop to zero with the unregister of the card or queue to trigger the release and free the object. 2024-02-27 not yet calculated CVE-2021-46968
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: bus: mhi: core: Fix invalid error returning in mhi_queue mhi_queue returns an error when the doorbell is not accessible in the current state. This can happen when the device is in non M0 state, like M3, and needs to be waken-up prior ringing the DB. This case is managed earlier by triggering an asynchronous M3 exit via controller resume/suspend callbacks, that in turn will cause M0 transition and DB update. So, since it’s not an error but just delaying of doorbell update, there is no reason to return an error. This also fixes a use after free error for skb case, indeed a caller queuing skb will try to free the skb if the queueing fails, but in that case queueing has been done. 2024-02-27 not yet calculated CVE-2021-46969
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: bus: mhi: pci_generic: Remove WQ_MEM_RECLAIM flag from state workqueue A recent change created a dedicated workqueue for the state-change work with WQ_HIGHPRI (no strong reason for that) and WQ_MEM_RECLAIM flags, but the state-change work (mhi_pm_st_worker) does not guarantee forward progress under memory pressure, and will even wait on various memory allocations when e.g. creating devices, loading firmware, etc… The work is then not part of a memory reclaim path… Moreover, this causes a warning in check_flush_dependency() since we end up in code that flushes a non-reclaim workqueue: [ 40.969601] workqueue: WQ_MEM_RECLAIM mhi_hiprio_wq:mhi_pm_st_worker [mhi] is flushing !WQ_MEM_RECLAIM events_highpri:flush_backlog [ 40.969612] WARNING: CPU: 4 PID: 158 at kernel/workqueue.c:2607 check_flush_dependency+0x11c/0x140 [ 40.969733] Call Trace: [ 40.969740] __flush_work+0x97/0x1d0 [ 40.969745] ? wake_up_process+0x15/0x20 [ 40.969749] ? insert_work+0x70/0x80 [ 40.969750] ? __queue_work+0x14a/0x3e0 [ 40.969753] flush_work+0x10/0x20 [ 40.969756] rollback_registered_many+0x1c9/0x510 [ 40.969759] unregister_netdevice_queue+0x94/0x120 [ 40.969761] unregister_netdev+0x1d/0x30 [ 40.969765] mhi_net_remove+0x1a/0x40 [mhi_net] [ 40.969770] mhi_driver_remove+0x124/0x250 [mhi] [ 40.969776] device_release_driver_internal+0xf0/0x1d0 [ 40.969778] device_release_driver+0x12/0x20 [ 40.969782] bus_remove_device+0xe1/0x150 [ 40.969786] device_del+0x17b/0x3e0 [ 40.969791] mhi_destroy_device+0x9a/0x100 [mhi] [ 40.969796] ? mhi_unmap_single_use_bb+0x50/0x50 [mhi] [ 40.969799] device_for_each_child+0x5e/0xa0 [ 40.969804] mhi_pm_st_worker+0x921/0xf50 [mhi] 2024-02-27 not yet calculated CVE-2021-46970
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: perf/core: Fix unconditional security_locked_down() call Currently, the lockdown state is queried unconditionally, even though its result is used only if the PERF_SAMPLE_REGS_INTR bit is set in attr.sample_type. While that doesn’t matter in case of the Lockdown LSM, it causes trouble with the SELinux’s lockdown hook implementation. SELinux implements the locked_down hook with a check whether the current task’s type has the corresponding “lockdown” class permission (“integrity” or “confidentiality”) allowed in the policy. This means that calling the hook when the access control decision would be ignored generates a bogus permission check and audit record. Fix this by checking sample_type first and only calling the hook when its result would be honored. 2024-02-27 not yet calculated CVE-2021-46971
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ovl: fix leaked dentry Since commit 6815f479ca90 (“ovl: use only uppermetacopy state in ovl_lookup()”), overlayfs doesn’t put temporary dentry when there is a metacopy error, which leads to dentry leaks when shutting down the related superblock: overlayfs: refusing to follow metacopy origin for (/file0) … BUG: Dentry (____ptrval____){i=3f33,n=file3} still in use (1) [unmount of overlay overlay] … WARNING: CPU: 1 PID: 432 at umount_check.cold+0x107/0x14d CPU: 1 PID: 432 Comm: unmount-overlay Not tainted 5.12.0-rc5 #1 … RIP: 0010:umount_check.cold+0x107/0x14d … Call Trace: d_walk+0x28c/0x950 ? dentry_lru_isolate+0x2b0/0x2b0 ? __kasan_slab_free+0x12/0x20 do_one_tree+0x33/0x60 shrink_dcache_for_umount+0x78/0x1d0 generic_shutdown_super+0x70/0x440 kill_anon_super+0x3e/0x70 deactivate_locked_super+0xc4/0x160 deactivate_super+0xfa/0x140 cleanup_mnt+0x22e/0x370 __cleanup_mnt+0x1a/0x30 task_work_run+0x139/0x210 do_exit+0xb0c/0x2820 ? __kasan_check_read+0x1d/0x30 ? find_held_lock+0x35/0x160 ? lock_release+0x1b6/0x660 ? mm_update_next_owner+0xa20/0xa20 ? reacquire_held_locks+0x3f0/0x3f0 ? __sanitizer_cov_trace_const_cmp4+0x22/0x30 do_group_exit+0x135/0x380 __do_sys_exit_group.isra.0+0x20/0x20 __x64_sys_exit_group+0x3c/0x50 do_syscall_64+0x45/0x70 entry_SYSCALL_64_after_hwframe+0x44/0xae … VFS: Busy inodes after unmount of overlay. Self-destruct in 5 seconds. Have a nice day… This fix has been tested with a syzkaller reproducer. 2024-02-27 not yet calculated CVE-2021-46972
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: qrtr: Avoid potential use after free in MHI send It is possible that the MHI ul_callback will be invoked immediately following the queueing of the skb for transmission, leading to the callback decrementing the refcount of the associated sk and freeing the skb. As such the dereference of skb and the increment of the sk refcount must happen before the skb is queued, to avoid the skb to be used after free and potentially the sk to drop its last refcount.. 2024-02-27 not yet calculated CVE-2021-46973
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: bpf: Fix masking negation logic upon negative dst register The negation logic for the case where the off_reg is sitting in the dst register is not correct given then we cannot just invert the add to a sub or vice versa. As a fix, perform the final bitwise and-op unconditionally into AX from the off_reg, then move the pointer from the src to dst and finally use AX as the source for the original pointer arithmetic operation such that the inversion yields a correct result. The single non-AX mov in between is possible given constant blinding is retaining it as it’s not an immediate based operation. 2024-02-27 not yet calculated CVE-2021-46974
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: conntrack: Make global sysctls readonly in non-init netns These sysctls point to global variables: – NF_SYSCTL_CT_MAX (&nf_conntrack_max) – NF_SYSCTL_CT_EXPECT_MAX (&nf_ct_expect_max) – NF_SYSCTL_CT_BUCKETS (&nf_conntrack_htable_size_user) Because their data pointers are not updated to point to per-netns structures, they must be marked read-only in a non-init_net ns. Otherwise, changes in any net namespace are reflected in (leaked into) all other net namespaces. This problem has existed since the introduction of net namespaces. The current logic marks them read-only only if the net namespace is owned by an unprivileged user (other than init_user_ns). Commit d0febd81ae77 (“netfilter: conntrack: re-visit sysctls in unprivileged namespaces”) “exposes all sysctls even if the namespace is unpriviliged.” Since we need to mark them readonly in any case, we can forego the unprivileged user check altogether. 2024-02-27 not yet calculated CVE-2021-46975
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm/i915: Fix crash in auto_retire The retire logic uses the 2 lower bits of the pointer to the retire function to store flags. However, the auto_retire function is not guaranteed to be aligned to a multiple of 4, which causes crashes as we jump to the wrong address, for example like this: 2021-04-24T18:03:53.804300Z WARNING kernel: [ 516.876901] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI 2021-04-24T18:03:53.804310Z WARNING kernel: [ 516.876906] CPU: 7 PID: 146 Comm: kworker/u16:6 Tainted: G U 5.4.105-13595-g3cd84167b2df #1 2021-04-24T18:03:53.804311Z WARNING kernel: [ 516.876907] Hardware name: Google Volteer2/Volteer2, BIOS Google_Volteer2.13672.76.0 02/22/2021 2021-04-24T18:03:53.804312Z WARNING kernel: [ 516.876911] Workqueue: events_unbound active_work 2021-04-24T18:03:53.804313Z WARNING kernel: [ 516.876914] RIP: 0010:auto_retire+0x1/0x20 2021-04-24T18:03:53.804314Z WARNING kernel: [ 516.876916] Code: e8 01 f2 ff ff eb 02 31 db 48 89 d8 5b 5d c3 0f 1f 44 00 00 55 48 89 e5 f0 ff 87 c8 00 00 00 0f 88 ab 47 4a 00 31 c0 5d c3 0f <1f> 44 00 00 55 48 89 e5 f0 ff 8f c8 00 00 00 0f 88 9a 47 4a 00 74 2021-04-24T18:03:53.804319Z WARNING kernel: [ 516.876918] RSP: 0018:ffff9b4d809fbe38 EFLAGS: 00010286 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876919] RAX: 0000000000000007 RBX: ffff927915079600 RCX: 0000000000000007 2021-04-24T18:03:53.804320Z WARNING kernel: [ 516.876921] RDX: ffff9b4d809fbe40 RSI: 0000000000000286 RDI: ffff927915079600 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876922] RBP: ffff9b4d809fbe68 R08: 8080808080808080 R09: fefefefefefefeff 2021-04-24T18:03:53.804321Z WARNING kernel: [ 516.876924] R10: 0000000000000010 R11: ffffffff92e44bd8 R12: ffff9279150796a0 2021-04-24T18:03:53.804322Z WARNING kernel: [ 516.876925] R13: ffff92791c368180 R14: ffff927915079640 R15: 000000001c867605 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876926] FS: 0000000000000000(0000) GS:ffff92791ffc0000(0000) knlGS:0000000000000000 2021-04-24T18:03:53.804323Z WARNING kernel: [ 516.876928] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 2021-04-24T18:03:53.804324Z WARNING kernel: [ 516.876929] CR2: 0000239514955000 CR3: 00000007f82da001 CR4: 0000000000760ee0 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876930] PKRU: 55555554 2021-04-24T18:03:53.804325Z WARNING kernel: [ 516.876931] Call Trace: 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876935] __active_retire+0x77/0xcf 2021-04-24T18:03:53.804326Z WARNING kernel: [ 516.876939] process_one_work+0x1da/0x394 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876941] worker_thread+0x216/0x375 2021-04-24T18:03:53.804327Z WARNING kernel: [ 516.876944] kthread+0x147/0x156 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876946] ? pr_cont_work+0x58/0x58 2021-04-24T18:03:53.804335Z WARNING kernel: [ 516.876948] ? kthread_blkcg+0x2e/0x2e 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876950] ret_from_fork+0x1f/0x40 2021-04-24T18:03:53.804336Z WARNING kernel: [ 516.876952] Modules linked in: cdc_mbim cdc_ncm cdc_wdm xt_cgroup rfcomm cmac algif_hash algif_skcipher af_alg xt_MASQUERADE uinput snd_soc_rt5682_sdw snd_soc_rt5682 snd_soc_max98373_sdw snd_soc_max98373 snd_soc_rl6231 regmap_sdw snd_soc_sof_sdw snd_soc_hdac_hdmi snd_soc_dmic snd_hda_codec_hdmi snd_sof_pci snd_sof_intel_hda_common intel_ipu6_psys snd_sof_xtensa_dsp soundwire_intel soundwire_generic_allocation soundwire_cadence snd_sof_intel_hda snd_sof snd_soc_hdac_hda snd_soc_acpi_intel_match snd_soc_acpi snd_hda_ext_core soundwire_bus snd_hda_intel snd_intel_dspcfg snd_hda_codec snd_hwdep snd_hda_core intel_ipu6_isys videobuf2_dma_contig videobuf2_v4l2 videobuf2_common videobuf2_memops mei_hdcp intel_ipu6 ov2740 ov8856 at24 sx9310 dw9768 v4l2_fwnode cros_ec_typec intel_pmc_mux roles acpi_als typec fuse iio_trig_sysfs cros_ec_light_prox cros_ec_lid_angle cros_ec_sensors cros —truncated— 2024-02-28 not yet calculated CVE-2021-46976
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: KVM: VMX: Disable preemption when probing user return MSRs Disable preemption when probing a user return MSR via RDSMR/WRMSR. If the MSR holds a different value per logical CPU, the WRMSR could corrupt the host’s value if KVM is preempted between the RDMSR and WRMSR, and then rescheduled on a different CPU. Opportunistically land the helper in common x86, SVM will use the helper in a future commit. 2024-02-28 not yet calculated CVE-2021-46977
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: KVM: nVMX: Always make an attempt to map eVMCS after migration When enlightened VMCS is in use and nested state is migrated with vmx_get_nested_state()/vmx_set_nested_state() KVM can’t map evmcs page right away: evmcs gpa is not ‘struct kvm_vmx_nested_state_hdr’ and we can’t read it from VP assist page because userspace may decide to restore HV_X64_MSR_VP_ASSIST_PAGE after restoring nested state (and QEMU, for example, does exactly that). To make sure eVMCS is mapped /vmx_set_nested_state() raises KVM_REQ_GET_NESTED_STATE_PAGES request. Commit f2c7ef3ba955 (“KVM: nSVM: cancel KVM_REQ_GET_NESTED_STATE_PAGES on nested vmexit”) added KVM_REQ_GET_NESTED_STATE_PAGES clearing to nested_vmx_vmexit() to make sure MSR permission bitmap is not switched when an immediate exit from L2 to L1 happens right after migration (caused by a pending event, for example). Unfortunately, in the exact same situation we still need to have eVMCS mapped so nested_sync_vmcs12_to_shadow() reflects changes in VMCS12 to eVMCS. As a band-aid, restore nested_get_evmcs_page() when clearing KVM_REQ_GET_NESTED_STATE_PAGES in nested_vmx_vmexit(). The ‘fix’ is far from being ideal as we can’t easily propagate possible failures and even if we could, this is most likely already too late to do so. The whole ‘KVM_REQ_GET_NESTED_STATE_PAGES’ idea for mapping eVMCS after migration seems to be fragile as we diverge too much from the ‘native’ path when vmptr loading happens on vmx_set_nested_state(). 2024-02-28 not yet calculated CVE-2021-46978
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: iio: core: fix ioctl handlers removal Currently ioctl handlers are removed twice. For the first time during iio_device_unregister() then later on inside iio_device_unregister_eventset() and iio_buffers_free_sysfs_and_mask(). Double free leads to kernel panic. Fix this by not touching ioctl handlers list directly but rather letting code responsible for registration call the matching cleanup routine itself. 2024-02-28 not yet calculated CVE-2021-46979
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: usb: typec: ucsi: Retrieve all the PDOs instead of just the first 4 commit 4dbc6a4ef06d (“usb: typec: ucsi: save power data objects in PD mode”) introduced retrieval of the PDOs when connected to a PD-capable source. But only the first 4 PDOs are received since that is the maximum number that can be fetched at a time given the MESSAGE_IN length limitation (16 bytes). However, as per the PD spec a connected source may advertise up to a maximum of 7 PDOs. If such a source is connected it’s possible the PPM could have negotiated a power contract with one of the PDOs at index greater than 4, and would be reflected in the request data object’s (RDO) object position field. This would result in an out-of-bounds access when the rdo_index() is used to index into the src_pdos array in ucsi_psy_get_voltage_now(). With the help of the UBSAN -fsanitize=array-bounds checker enabled this exact issue is revealed when connecting to a PD source adapter that advertise 5 PDOs and the PPM enters a contract having selected the 5th one. [ 151.545106][ T70] Unexpected kernel BRK exception at EL1 [ 151.545112][ T70] Internal error: BRK handler: f2005512 [#1] PREEMPT SMP … [ 151.545499][ T70] pc : ucsi_psy_get_prop+0x208/0x20c [ 151.545507][ T70] lr : power_supply_show_property+0xc0/0x328 … [ 151.545542][ T70] Call trace: [ 151.545544][ T70] ucsi_psy_get_prop+0x208/0x20c [ 151.545546][ T70] power_supply_uevent+0x1a4/0x2f0 [ 151.545550][ T70] dev_uevent+0x200/0x384 [ 151.545555][ T70] kobject_uevent_env+0x1d4/0x7e8 [ 151.545557][ T70] power_supply_changed_work+0x174/0x31c [ 151.545562][ T70] process_one_work+0x244/0x6f0 [ 151.545564][ T70] worker_thread+0x3e0/0xa64 We can resolve this by instead retrieving and storing up to the maximum of 7 PDOs in the con->src_pdos array. This would involve two calls to the GET_PDOS command. 2024-02-28 not yet calculated CVE-2021-46980
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nbd: Fix NULL pointer in flush_workqueue Open /dev/nbdX first, the config_refs will be 1 and the pointers in nbd_device are still null. Disconnect /dev/nbdX, then reference a null recv_workq. The protection by config_refs in nbd_genl_disconnect is useless. [ 656.366194] BUG: kernel NULL pointer dereference, address: 0000000000000020 [ 656.368943] #PF: supervisor write access in kernel mode [ 656.369844] #PF: error_code(0x0002) – not-present page [ 656.370717] PGD 10cc87067 P4D 10cc87067 PUD 1074b4067 PMD 0 [ 656.371693] Oops: 0002 [#1] SMP [ 656.372242] CPU: 5 PID: 7977 Comm: nbd-client Not tainted 5.11.0-rc5-00040-g76c057c84d28 #1 [ 656.373661] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ 656.375904] RIP: 0010:mutex_lock+0x29/0x60 [ 656.376627] Code: 00 0f 1f 44 00 00 55 48 89 fd 48 83 05 6f d7 fe 08 01 e8 7a c3 ff ff 48 83 05 6a d7 fe 08 01 31 c0 65 48 8b 14 25 00 6d 01 00 <f0> 48 0f b1 55 d [ 656.378934] RSP: 0018:ffffc900005eb9b0 EFLAGS: 00010246 [ 656.379350] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 [ 656.379915] RDX: ffff888104cf2600 RSI: ffffffffaae8f452 RDI: 0000000000000020 [ 656.380473] RBP: 0000000000000020 R08: 0000000000000000 R09: ffff88813bd6b318 [ 656.381039] R10: 00000000000000c7 R11: fefefefefefefeff R12: ffff888102710b40 [ 656.381599] R13: ffffc900005eb9e0 R14: ffffffffb2930680 R15: ffff88810770ef00 [ 656.382166] FS: 00007fdf117ebb40(0000) GS:ffff88813bd40000(0000) knlGS:0000000000000000 [ 656.382806] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 656.383261] CR2: 0000000000000020 CR3: 0000000100c84000 CR4: 00000000000006e0 [ 656.383819] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 656.384370] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 656.384927] Call Trace: [ 656.385111] flush_workqueue+0x92/0x6c0 [ 656.385395] nbd_disconnect_and_put+0x81/0xd0 [ 656.385716] nbd_genl_disconnect+0x125/0x2a0 [ 656.386034] genl_family_rcv_msg_doit.isra.0+0x102/0x1b0 [ 656.386422] genl_rcv_msg+0xfc/0x2b0 [ 656.386685] ? nbd_ioctl+0x490/0x490 [ 656.386954] ? genl_family_rcv_msg_doit.isra.0+0x1b0/0x1b0 [ 656.387354] netlink_rcv_skb+0x62/0x180 [ 656.387638] genl_rcv+0x34/0x60 [ 656.387874] netlink_unicast+0x26d/0x590 [ 656.388162] netlink_sendmsg+0x398/0x6c0 [ 656.388451] ? netlink_rcv_skb+0x180/0x180 [ 656.388750] ____sys_sendmsg+0x1da/0x320 [ 656.389038] ? ____sys_recvmsg+0x130/0x220 [ 656.389334] ___sys_sendmsg+0x8e/0xf0 [ 656.389605] ? ___sys_recvmsg+0xa2/0xf0 [ 656.389889] ? handle_mm_fault+0x1671/0x21d0 [ 656.390201] __sys_sendmsg+0x6d/0xe0 [ 656.390464] __x64_sys_sendmsg+0x23/0x30 [ 656.390751] do_syscall_64+0x45/0x70 [ 656.391017] entry_SYSCALL_64_after_hwframe+0x44/0xa9 To fix it, just add if (nbd->recv_workq) to nbd_disconnect_and_put(). 2024-02-28 not yet calculated CVE-2021-46981
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: f2fs: compress: fix race condition of overwrite vs truncate pos_fsstress testcase complains a panic as belew: ————[ cut here ]———— kernel BUG at fs/f2fs/compress.c:1082! invalid opcode: 0000 [#1] SMP PTI CPU: 4 PID: 2753477 Comm: kworker/u16:2 Tainted: G OE 5.12.0-rc1-custom #1 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014 Workqueue: writeback wb_workfn (flush-252:16) RIP: 0010:prepare_compress_overwrite+0x4c0/0x760 [f2fs] Call Trace: f2fs_prepare_compress_overwrite+0x5f/0x80 [f2fs] f2fs_write_cache_pages+0x468/0x8a0 [f2fs] f2fs_write_data_pages+0x2a4/0x2f0 [f2fs] do_writepages+0x38/0xc0 __writeback_single_inode+0x44/0x2a0 writeback_sb_inodes+0x223/0x4d0 __writeback_inodes_wb+0x56/0xf0 wb_writeback+0x1dd/0x290 wb_workfn+0x309/0x500 process_one_work+0x220/0x3c0 worker_thread+0x53/0x420 kthread+0x12f/0x150 ret_from_fork+0x22/0x30 The root cause is truncate() may race with overwrite as below, so that one reference count left in page can not guarantee the page attaching in mapping tree all the time, after truncation, later find_lock_page() may return NULL pointer. – prepare_compress_overwrite – f2fs_pagecache_get_page – unlock_page – f2fs_setattr – truncate_setsize – truncate_inode_page – delete_from_page_cache – find_lock_page Fix this by avoiding referencing updated page. 2024-02-28 not yet calculated CVE-2021-46982
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nvmet-rdma: Fix NULL deref when SEND is completed with error When running some traffic and taking down the link on peer, a retry counter exceeded error is received. This leads to nvmet_rdma_error_comp which tried accessing the cq_context to obtain the queue. The cq_context is no longer valid after the fix to use shared CQ mechanism and should be obtained similar to how it is obtained in other functions from the wc->qp. [ 905.786331] nvmet_rdma: SEND for CQE 0x00000000e3337f90 failed with status transport retry counter exceeded (12). [ 905.832048] BUG: unable to handle kernel NULL pointer dereference at 0000000000000048 [ 905.839919] PGD 0 P4D 0 [ 905.842464] Oops: 0000 1 SMP NOPTI [ 905.846144] CPU: 13 PID: 1557 Comm: kworker/13:1H Kdump: loaded Tainted: G OE ——— – – 4.18.0-304.el8.x86_64 #1 [ 905.872135] RIP: 0010:nvmet_rdma_error_comp+0x5/0x1b [nvmet_rdma] [ 905.878259] Code: 19 4f c0 e8 89 b3 a5 f6 e9 5b e0 ff ff 0f b7 75 14 4c 89 ea 48 c7 c7 08 1a 4f c0 e8 71 b3 a5 f6 e9 4b e0 ff ff 0f 1f 44 00 00 <48> 8b 47 48 48 85 c0 74 08 48 89 c7 e9 98 bf 49 00 e9 c3 e3 ff ff [ 905.897135] RSP: 0018:ffffab601c45fe28 EFLAGS: 00010246 [ 905.902387] RAX: 0000000000000065 RBX: ffff9e729ea2f800 RCX: 0000000000000000 [ 905.909558] RDX: 0000000000000000 RSI: ffff9e72df9567c8 RDI: 0000000000000000 [ 905.916731] RBP: ffff9e729ea2b400 R08: 000000000000074d R09: 0000000000000074 [ 905.923903] R10: 0000000000000000 R11: ffffab601c45fcc0 R12: 0000000000000010 [ 905.931074] R13: 0000000000000000 R14: 0000000000000010 R15: ffff9e729ea2f400 [ 905.938247] FS: 0000000000000000(0000) GS:ffff9e72df940000(0000) knlGS:0000000000000000 [ 905.938249] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 905.950067] nvmet_rdma: SEND for CQE 0x00000000c7356cca failed with status transport retry counter exceeded (12). [ 905.961855] CR2: 0000000000000048 CR3: 000000678d010004 CR4: 00000000007706e0 [ 905.961855] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 905.961856] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 905.961857] PKRU: 55555554 [ 906.010315] Call Trace: [ 906.012778] __ib_process_cq+0x89/0x170 [ib_core] [ 906.017509] ib_cq_poll_work+0x26/0x80 [ib_core] [ 906.022152] process_one_work+0x1a7/0x360 [ 906.026182] ? create_worker+0x1a0/0x1a0 [ 906.030123] worker_thread+0x30/0x390 [ 906.033802] ? create_worker+0x1a0/0x1a0 [ 906.037744] kthread+0x116/0x130 [ 906.040988] ? kthread_flush_work_fn+0x10/0x10 [ 906.045456] ret_from_fork+0x1f/0x40 2024-02-28 not yet calculated CVE-2021-46983
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: kyber: fix out of bounds access when preempted __blk_mq_sched_bio_merge() gets the ctx and hctx for the current CPU and passes the hctx to ->bio_merge(). kyber_bio_merge() then gets the ctx for the current CPU again and uses that to get the corresponding Kyber context in the passed hctx. However, the thread may be preempted between the two calls to blk_mq_get_ctx(), and the ctx returned the second time may no longer correspond to the passed hctx. This “works” accidentally most of the time, but it can cause us to read garbage if the second ctx came from an hctx with more ctx’s than the first one (i.e., if ctx->index_hw[hctx->type] > hctx->nr_ctx). This manifested as this UBSAN array index out of bounds error reported by Jakub: UBSAN: array-index-out-of-bounds in ../kernel/locking/qspinlock.c:130:9 index 13106 is out of range for type ‘long unsigned int [128]’ Call Trace: dump_stack+0xa4/0xe5 ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold.13+0x2a/0x34 queued_spin_lock_slowpath+0x476/0x480 do_raw_spin_lock+0x1c2/0x1d0 kyber_bio_merge+0x112/0x180 blk_mq_submit_bio+0x1f5/0x1100 submit_bio_noacct+0x7b0/0x870 submit_bio+0xc2/0x3a0 btrfs_map_bio+0x4f0/0x9d0 btrfs_submit_data_bio+0x24e/0x310 submit_one_bio+0x7f/0xb0 submit_extent_page+0xc4/0x440 __extent_writepage_io+0x2b8/0x5e0 __extent_writepage+0x28d/0x6e0 extent_write_cache_pages+0x4d7/0x7a0 extent_writepages+0xa2/0x110 do_writepages+0x8f/0x180 __writeback_single_inode+0x99/0x7f0 writeback_sb_inodes+0x34e/0x790 __writeback_inodes_wb+0x9e/0x120 wb_writeback+0x4d2/0x660 wb_workfn+0x64d/0xa10 process_one_work+0x53a/0xa80 worker_thread+0x69/0x5b0 kthread+0x20b/0x240 ret_from_fork+0x1f/0x30 Only Kyber uses the hctx, so fix it by passing the request_queue to ->bio_merge() instead. BFQ and mq-deadline just use that, and Kyber can map the queues itself to avoid the mismatch. 2024-02-28 not yet calculated CVE-2021-46984
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ACPI: scan: Fix a memory leak in an error handling path If ‘acpi_device_set_name()’ fails, we must free ‘acpi_device_bus_id->bus_id’ or there is a (potential) memory leak. 2024-02-28 not yet calculated CVE-2021-46985
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: usb: dwc3: gadget: Free gadget structure only after freeing endpoints As part of commit e81a7018d93a (“usb: dwc3: allocate gadget structure dynamically”) the dwc3_gadget_release() was added which will free the dwc->gadget structure upon the device’s removal when usb_del_gadget_udc() is called in dwc3_gadget_exit(). However, simply freeing the gadget results a dangling pointer situation: the endpoints created in dwc3_gadget_init_endpoints() have their dep->endpoint.ep_list members chained off the list_head anchored at dwc->gadget->ep_list. Thus when dwc->gadget is freed, the first dwc3_ep in the list now has a dangling prev pointer and likewise for the next pointer of the dwc3_ep at the tail of the list. The dwc3_gadget_free_endpoints() that follows will result in a use-after-free when it calls list_del(). This was caught by enabling KASAN and performing a driver unbind. The recent commit 568262bf5492 (“usb: dwc3: core: Add shutdown callback for dwc3”) also exposes this as a panic during shutdown. There are a few possibilities to fix this. One could be to perform a list_del() of the gadget->ep_list itself which removes it from the rest of the dwc3_ep chain. Another approach is what this patch does, by splitting up the usb_del_gadget_udc() call into its separate “del” and “put” components. This allows dwc3_gadget_free_endpoints() to be called before the gadget is finally freed with usb_put_gadget(). 2024-02-28 not yet calculated CVE-2021-46986
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: btrfs: fix deadlock when cloning inline extents and using qgroups There are a few exceptional cases where cloning an inline extent needs to copy the inline extent data into a page of the destination inode. When this happens, we end up starting a transaction while having a dirty page for the destination inode and while having the range locked in the destination’s inode iotree too. Because when reserving metadata space for a transaction we may need to flush existing delalloc in case there is not enough free space, we have a mechanism in place to prevent a deadlock, which was introduced in commit 3d45f221ce627d (“btrfs: fix deadlock when cloning inline extent and low on free metadata space”). However when using qgroups, a transaction also reserves metadata qgroup space, which can also result in flushing delalloc in case there is not enough available space at the moment. When this happens we deadlock, since flushing delalloc requires locking the file range in the inode’s iotree and the range was already locked at the very beginning of the clone operation, before attempting to start the transaction. When this issue happens, stack traces like the following are reported: [72747.556262] task:kworker/u81:9 state:D stack: 0 pid: 225 ppid: 2 flags:0x00004000 [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142) [72747.556271] Call Trace: [72747.556273] __schedule+0x296/0x760 [72747.556277] schedule+0x3c/0xa0 [72747.556279] io_schedule+0x12/0x40 [72747.556284] __lock_page+0x13c/0x280 [72747.556287] ? generic_file_readonly_mmap+0x70/0x70 [72747.556325] extent_write_cache_pages+0x22a/0x440 [btrfs] [72747.556331] ? __set_page_dirty_nobuffers+0xe7/0x160 [72747.556358] ? set_extent_buffer_dirty+0x5e/0x80 [btrfs] [72747.556362] ? update_group_capacity+0x25/0x210 [72747.556366] ? cpumask_next_and+0x1a/0x20 [72747.556391] extent_writepages+0x44/0xa0 [btrfs] [72747.556394] do_writepages+0x41/0xd0 [72747.556398] __writeback_single_inode+0x39/0x2a0 [72747.556403] writeback_sb_inodes+0x1ea/0x440 [72747.556407] __writeback_inodes_wb+0x5f/0xc0 [72747.556410] wb_writeback+0x235/0x2b0 [72747.556414] ? get_nr_inodes+0x35/0x50 [72747.556417] wb_workfn+0x354/0x490 [72747.556420] ? newidle_balance+0x2c5/0x3e0 [72747.556424] process_one_work+0x1aa/0x340 [72747.556426] worker_thread+0x30/0x390 [72747.556429] ? create_worker+0x1a0/0x1a0 [72747.556432] kthread+0x116/0x130 [72747.556435] ? kthread_park+0x80/0x80 [72747.556438] ret_from_fork+0x1f/0x30 [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs] [72747.566961] Call Trace: [72747.566964] __schedule+0x296/0x760 [72747.566968] ? finish_wait+0x80/0x80 [72747.566970] schedule+0x3c/0xa0 [72747.566995] wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs] [72747.566999] ? finish_wait+0x80/0x80 [72747.567024] lock_extent_bits+0x37/0x90 [btrfs] [72747.567047] btrfs_invalidatepage+0x299/0x2c0 [btrfs] [72747.567051] ? find_get_pages_range_tag+0x2cd/0x380 [72747.567076] __extent_writepage+0x203/0x320 [btrfs] [72747.567102] extent_write_cache_pages+0x2bb/0x440 [btrfs] [72747.567106] ? update_load_avg+0x7e/0x5f0 [72747.567109] ? enqueue_entity+0xf4/0x6f0 [72747.567134] extent_writepages+0x44/0xa0 [btrfs] [72747.567137] ? enqueue_task_fair+0x93/0x6f0 [72747.567140] do_writepages+0x41/0xd0 [72747.567144] __filemap_fdatawrite_range+0xc7/0x100 [72747.567167] btrfs_run_delalloc_work+0x17/0x40 [btrfs] [72747.567195] btrfs_work_helper+0xc2/0x300 [btrfs] [72747.567200] process_one_work+0x1aa/0x340 [72747.567202] worker_thread+0x30/0x390 [72747.567205] ? create_worker+0x1a0/0x1a0 [72747.567208] kthread+0x116/0x130 [72747.567211] ? kthread_park+0x80/0x80 [72747.567214] ret_from_fork+0x1f/0x30 [72747.569686] task:fsstress state:D stack: —truncated— 2024-02-28 not yet calculated CVE-2021-46987
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: userfaultfd: release page in error path to avoid BUG_ON Consider the following sequence of events: 1. Userspace issues a UFFD ioctl, which ends up calling into shmem_mfill_atomic_pte(). We successfully account the blocks, we shmem_alloc_page(), but then the copy_from_user() fails. We return -ENOENT. We don’t release the page we allocated. 2. Our caller detects this error code, tries the copy_from_user() after dropping the mmap_lock, and retries, calling back into shmem_mfill_atomic_pte(). 3. Meanwhile, let’s say another process filled up the tmpfs being used. 4. So shmem_mfill_atomic_pte() fails to account blocks this time, and immediately returns – without releasing the page. This triggers a BUG_ON in our caller, which asserts that the page should always be consumed, unless -ENOENT is returned. To fix this, detect if we have such a “dangling” page when accounting fails, and if so, release it before returning. 2024-02-28 not yet calculated CVE-2021-46988
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: hfsplus: prevent corruption in shrinking truncate I believe there are some issues introduced by commit 31651c607151 (“hfsplus: avoid deadlock on file truncation”) HFS+ has extent records which always contains 8 extents. In case the first extent record in catalog file gets full, new ones are allocated from extents overflow file. In case shrinking truncate happens to middle of an extent record which locates in extents overflow file, the logic in hfsplus_file_truncate() was changed so that call to hfs_brec_remove() is not guarded any more. Right action would be just freeing the extents that exceed the new size inside extent record by calling hfsplus_free_extents(), and then check if the whole extent record should be removed. However since the guard (blk_cnt > start) is now after the call to hfs_brec_remove(), this has unfortunate effect that the last matching extent record is removed unconditionally. To reproduce this issue, create a file which has at least 10 extents, and then perform shrinking truncate into middle of the last extent record, so that the number of remaining extents is not under or divisible by 8. This causes the last extent record (8 extents) to be removed totally instead of truncating into middle of it. Thus this causes corruption, and lost data. Fix for this is simply checking if the new truncated end is below the start of this extent record, making it safe to remove the full extent record. However call to hfs_brec_remove() can’t be moved to it’s previous place since we’re dropping ->tree_lock and it can cause a race condition and the cached info being invalidated possibly corrupting the node data. Another issue is related to this one. When entering into the block (blk_cnt > start) we are not holding the ->tree_lock. We break out from the loop not holding the lock, but hfs_find_exit() does unlock it. Not sure if it’s possible for someone else to take the lock under our feet, but it can cause hard to debug errors and premature unlocking. Even if there’s no real risk of it, the locking should still always be kept in balance. Thus taking the lock now just before the check. 2024-02-28 not yet calculated CVE-2021-46989
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix crashes when toggling entry flush barrier The entry flush mitigation can be enabled/disabled at runtime via a debugfs file (entry_flush), which causes the kernel to patch itself to enable/disable the relevant mitigations. However depending on which mitigation we’re using, it may not be safe to do that patching while other CPUs are active. For example the following crash: sleeper[15639]: segfault (11) at c000000000004c20 nip c000000000004c20 lr c000000000004c20 Shows that we returned to userspace with a corrupted LR that points into the kernel, due to executing the partially patched call to the fallback entry flush (ie. we missed the LR restore). Fix it by doing the patching under stop machine. The CPUs that aren’t doing the patching will be spinning in the core of the stop machine logic. That is currently sufficient for our purposes, because none of the patching we do is to that code or anywhere in the vicinity. 2024-02-28 not yet calculated CVE-2021-46990
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i40e: Fix use-after-free in i40e_client_subtask() Currently the call to i40e_client_del_instance frees the object pf->cinst, however pf->cinst->lan_info is being accessed after the free. Fix this by adding the missing return. Addresses-Coverity: (“Read from pointer after free”) 2024-02-28 not yet calculated CVE-2021-46991
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: avoid overflows in nft_hash_buckets() Number of buckets being stored in 32bit variables, we have to ensure that no overflows occur in nft_hash_buckets() syzbot injected a size == 0x40000000 and reported: UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13 shift exponent 64 is too large for 64-bit type ‘long unsigned int’ CPU: 1 PID: 29539 Comm: syz-executor.4 Not tainted 5.12.0-rc7-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Call Trace: __dump_stack lib/dump_stack.c:79 [inline] dump_stack+0x141/0x1d7 lib/dump_stack.c:120 ubsan_epilogue+0xb/0x5a lib/ubsan.c:148 __ubsan_handle_shift_out_of_bounds.cold+0xb1/0x181 lib/ubsan.c:327 __roundup_pow_of_two include/linux/log2.h:57 [inline] nft_hash_buckets net/netfilter/nft_set_hash.c:411 [inline] nft_hash_estimate.cold+0x19/0x1e net/netfilter/nft_set_hash.c:652 nft_select_set_ops net/netfilter/nf_tables_api.c:3586 [inline] nf_tables_newset+0xe62/0x3110 net/netfilter/nf_tables_api.c:4322 nfnetlink_rcv_batch+0xa09/0x24b0 net/netfilter/nfnetlink.c:488 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:612 [inline] nfnetlink_rcv+0x3af/0x420 net/netfilter/nfnetlink.c:630 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46 2024-02-28 not yet calculated CVE-2021-46992
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: sched: Fix out-of-bound access in uclamp Util-clamp places tasks in different buckets based on their clamp values for performance reasons. However, the size of buckets is currently computed using a rounding division, which can lead to an off-by-one error in some configurations. For instance, with 20 buckets, the bucket size will be 1024/20=51. A task with a clamp of 1024 will be mapped to bucket id 1024/51=20. Sadly, correct indexes are in range [0,19], hence leading to an out of bound memory access. Clamp the bucket id to fix the issue. 2024-02-28 not yet calculated CVE-2021-46993
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: can: mcp251x: fix resume from sleep before interface was brought up Since 8ce8c0abcba3 the driver queues work via priv->restart_work when resuming after suspend, even when the interface was not previously enabled. This causes a null dereference error as the workqueue is only allocated and initialized in mcp251x_open(). To fix this we move the workqueue init to mcp251x_can_probe() as there is no reason to do it later and repeat it whenever mcp251x_open() is called. [mkl: fix error handling in mcp251x_stop()] 2024-02-28 not yet calculated CVE-2021-46994
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: can: mcp251xfd: mcp251xfd_probe(): fix an error pointer dereference in probe When we converted this code to use dev_err_probe() we accidentally removed a return. It means that if devm_clk_get() it will lead to an Oops when we call clk_get_rate() on the next line. 2024-02-28 not yet calculated CVE-2021-46995
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: nftables: Fix a memleak from userdata error path in new objects Release object name if userdata allocation fails. 2024-02-28 not yet calculated CVE-2021-46996
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: arm64: entry: always set GIC_PRIO_PSR_I_SET during entry Zenghui reports that booting a kernel with “irqchip.gicv3_pseudo_nmi=1” on the command line hits a warning during kernel entry, due to the way we manipulate the PMR. Early in the entry sequence, we call lockdep_hardirqs_off() to inform lockdep that interrupts have been masked (as the HW sets DAIF wqhen entering an exception). Architecturally PMR_EL1 is not affected by exception entry, and we don’t set GIC_PRIO_PSR_I_SET in the PMR early in the exception entry sequence, so early in exception entry the PMR can indicate that interrupts are unmasked even though they are masked by DAIF. If DEBUG_LOCKDEP is selected, lockdep_hardirqs_off() will check that interrupts are masked, before we set GIC_PRIO_PSR_I_SET in any of the exception entry paths, and hence lockdep_hardirqs_off() will WARN() that something is amiss. We can avoid this by consistently setting GIC_PRIO_PSR_I_SET during exception entry so that kernel code sees a consistent environment. We must also update local_daif_inherit() to undo this, as currently only touches DAIF. For other paths, local_daif_restore() will update both DAIF and the PMR. With this done, we can remove the existing special cases which set this later in the entry code. We always use (GIC_PRIO_IRQON | GIC_PRIO_PSR_I_SET) for consistency with local_daif_save(), as this will warn if it ever encounters (GIC_PRIO_IRQOFF | GIC_PRIO_PSR_I_SET), and never sets this itself. This matches the gic_prio_kentry_setup that we have to retain for ret_to_user. The original splat from Zenghui’s report was: | DEBUG_LOCKS_WARN_ON(!irqs_disabled()) | WARNING: CPU: 3 PID: 125 at kernel/locking/lockdep.c:4258 lockdep_hardirqs_off+0xd4/0xe8 | Modules linked in: | CPU: 3 PID: 125 Comm: modprobe Tainted: G W 5.12.0-rc8+ #463 | Hardware name: QEMU KVM Virtual Machine, BIOS 0.0.0 02/06/2015 | pstate: 604003c5 (nZCv DAIF +PAN -UAO -TCO BTYPE=–) | pc : lockdep_hardirqs_off+0xd4/0xe8 | lr : lockdep_hardirqs_off+0xd4/0xe8 | sp : ffff80002a39bad0 | pmr_save: 000000e0 | x29: ffff80002a39bad0 x28: ffff0000de214bc0 | x27: ffff0000de1c0400 x26: 000000000049b328 | x25: 0000000000406f30 x24: ffff0000de1c00a0 | x23: 0000000020400005 x22: ffff8000105f747c | x21: 0000000096000044 x20: 0000000000498ef9 | x19: ffff80002a39bc88 x18: ffffffffffffffff | x17: 0000000000000000 x16: ffff800011c61eb0 | x15: ffff800011700a88 x14: 0720072007200720 | x13: 0720072007200720 x12: 0720072007200720 | x11: 0720072007200720 x10: 0720072007200720 | x9 : ffff80002a39bad0 x8 : ffff80002a39bad0 | x7 : ffff8000119f0800 x6 : c0000000ffff7fff | x5 : ffff8000119f07a8 x4 : 0000000000000001 | x3 : 9bcdab23f2432800 x2 : ffff800011730538 | x1 : 9bcdab23f2432800 x0 : 0000000000000000 | Call trace: | lockdep_hardirqs_off+0xd4/0xe8 | enter_from_kernel_mode.isra.5+0x7c/0xa8 | el1_abort+0x24/0x100 | el1_sync_handler+0x80/0xd0 | el1_sync+0x6c/0x100 | __arch_clear_user+0xc/0x90 | load_elf_binary+0x9fc/0x1450 | bprm_execve+0x404/0x880 | kernel_execve+0x180/0x188 | call_usermodehelper_exec_async+0xdc/0x158 | ret_from_fork+0x10/0x18 2024-02-28 not yet calculated CVE-2021-46997
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ethernet:enic: Fix a use after free bug in enic_hard_start_xmit In enic_hard_start_xmit, it calls enic_queue_wq_skb(). Inside enic_queue_wq_skb, if some error happens, the skb will be freed by dev_kfree_skb(skb). But the freed skb is still used in skb_tx_timestamp(skb). My patch makes enic_queue_wq_skb() return error and goto spin_unlock() incase of error. The solution is provided by Govind. See https://lkml.org/lkml/2021/4/30/961. 2024-02-28 not yet calculated CVE-2021-46998
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: sctp: do asoc update earlier in sctp_sf_do_dupcook_a There’s a panic that occurs in a few of envs, the call trace is as below: [] general protection fault, … 0x29acd70f1000a: 0000 [#1] SMP PTI [] RIP: 0010:sctp_ulpevent_notify_peer_addr_change+0x4b/0x1fa [sctp] [] sctp_assoc_control_transport+0x1b9/0x210 [sctp] [] sctp_do_8_2_transport_strike.isra.16+0x15c/0x220 [sctp] [] sctp_cmd_interpreter.isra.21+0x1231/0x1a10 [sctp] [] sctp_do_sm+0xc3/0x2a0 [sctp] [] sctp_generate_timeout_event+0x81/0xf0 [sctp] This is caused by a transport use-after-free issue. When processing a duplicate COOKIE-ECHO chunk in sctp_sf_do_dupcook_a(), both COOKIE-ACK and SHUTDOWN chunks are allocated with the transort from the new asoc. However, later in the sideeffect machine, the old asoc is used to send them out and old asoc’s shutdown_last_sent_to is set to the transport that SHUTDOWN chunk attached to in sctp_cmd_setup_t2(), which actually belongs to the new asoc. After the new_asoc is freed and the old asoc T2 timeout, the old asoc’s shutdown_last_sent_to that is already freed would be accessed in sctp_sf_t2_timer_expire(). Thanks Alexander and Jere for helping dig into this issue. To fix it, this patch is to do the asoc update first, then allocate the COOKIE-ACK and SHUTDOWN chunks with the ‘updated’ old asoc. This would make more sense, as a chunk from an asoc shouldn’t be sent out with another asoc. We had fixed quite a few issues caused by this. 2024-02-28 not yet calculated CVE-2021-46999
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ceph: fix inode leak on getattr error in __fh_to_dentry 2024-02-28 not yet calculated CVE-2021-47000
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: xprtrdma: Fix cwnd update ordering After a reconnect, the reply handler is opening the cwnd (and thus enabling more RPC Calls to be sent) /before/ rpcrdma_post_recvs() can post enough Receive WRs to receive their replies. This causes an RNR and the new connection is lost immediately. The race is most clearly exposed when KASAN and disconnect injection are enabled. This slows down rpcrdma_rep_create() enough to allow the send side to post a bunch of RPC Calls before the Receive completion handler can invoke ib_post_recv(). 2024-02-28 not yet calculated CVE-2021-47001
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: SUNRPC: Fix null pointer dereference in svc_rqst_free() When alloc_pages_node() returns null in svc_rqst_alloc(), the null rq_scratch_page pointer will be dereferenced when calling put_page() in svc_rqst_free(). Fix it by adding a null check. Addresses-Coverity: (“Dereference after null check”) 2024-02-28 not yet calculated CVE-2021-47002
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dmaengine: idxd: Fix potential null dereference on pointer status There are calls to idxd_cmd_exec that pass a null status pointer however a recent commit has added an assignment to *status that can end up with a null pointer dereference. The function expects a null status pointer sometimes as there is a later assignment to *status where status is first null checked. Fix the issue by null checking status before making the assignment. Addresses-Coverity: (“Explicit null dereferenced”) 2024-02-28 not yet calculated CVE-2021-47003
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: f2fs: fix to avoid touching checkpointed data in get_victim() In CP disabling mode, there are two issues when using LFS or SSR | AT_SSR mode to select victim: 1. LFS is set to find source section during GC, the victim should have no checkpointed data, since after GC, section could not be set free for reuse. Previously, we only check valid chpt blocks in current segment rather than section, fix it. 2. SSR | AT_SSR are set to find target segment for writes which can be fully filled by checkpointed and newly written blocks, we should never select such segment, otherwise it can cause panic or data corruption during allocation, potential case is described as below: a) target segment has ‘n’ (n < 512) ckpt valid blocks b) GC migrates ‘n’ valid blocks to other segment (segment is still in dirty list) c) GC migrates ‘512 – n’ blocks to target segment (segment has ‘n’ cp_vblocks and ‘512 – n’ vblocks) d) If GC selects target segment via {AT,}SSR allocator, however there is no free space in targe segment. 2024-02-28 not yet calculated CVE-2021-47004
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: PCI: endpoint: Fix NULL pointer dereference for ->get_features() get_features ops of pci_epc_ops may return NULL, causing NULL pointer dereference in pci_epf_test_alloc_space function. Let us add a check for pci_epc_feature pointer in pci_epf_test_bind before we access it to avoid any such NULL pointer dereference and return -ENOTSUPP in case pci_epc_feature is not found. When the patch is not applied and EPC features is not implemented in the platform driver, we see the following dump due to kernel NULL pointer dereference. Call trace: pci_epf_test_bind+0xf4/0x388 pci_epf_bind+0x3c/0x80 pci_epc_epf_link+0xa8/0xcc configfs_symlink+0x1a4/0x48c vfs_symlink+0x104/0x184 do_symlinkat+0x80/0xd4 __arm64_sys_symlinkat+0x1c/0x24 el0_svc_common.constprop.3+0xb8/0x170 el0_svc_handler+0x70/0x88 el0_svc+0x8/0x640 Code: d2800581 b9403ab9 f9404ebb 8b394f60 (f9400400) —[ end trace a438e3c5a24f9df0 ]— 2024-02-28 not yet calculated CVE-2021-47005
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ARM: 9064/1: hw_breakpoint: Do not directly check the event’s overflow_handler hook The commit 1879445dfa7b (“perf/core: Set event’s default ::overflow_handler()”) set a default event->overflow_handler in perf_event_alloc(), and replace the check event->overflow_handler with is_default_overflow_handler(), but one is missing. Currently, the bp->overflow_handler can not be NULL. As a result, enable_single_step() is always not invoked. Comments from Zhen Lei: https://patchwork.kernel.org/project/linux-arm-kernel/patch/20210207105934.2001-1-thunder.leizhen@huawei.com/ 2024-02-28 not yet calculated CVE-2021-47006
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: f2fs: fix panic during f2fs_resize_fs() f2fs_resize_fs() hangs in below callstack with testcase: – mkfs 16GB image & mount image – dd 8GB fileA – dd 8GB fileB – sync – rm fileA – sync – resize filesystem to 8GB kernel BUG at segment.c:2484! Call Trace: allocate_segment_by_default+0x92/0xf0 [f2fs] f2fs_allocate_data_block+0x44b/0x7e0 [f2fs] do_write_page+0x5a/0x110 [f2fs] f2fs_outplace_write_data+0x55/0x100 [f2fs] f2fs_do_write_data_page+0x392/0x850 [f2fs] move_data_page+0x233/0x320 [f2fs] do_garbage_collect+0x14d9/0x1660 [f2fs] free_segment_range+0x1f7/0x310 [f2fs] f2fs_resize_fs+0x118/0x330 [f2fs] __f2fs_ioctl+0x487/0x3680 [f2fs] __x64_sys_ioctl+0x8e/0xd0 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xa9 The root cause is we forgot to check that whether we have enough space in resized filesystem to store all valid blocks in before-resizing filesystem, then allocator will run out-of-space during block migration in free_segment_range(). 2024-02-28 not yet calculated CVE-2021-47007
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Make sure GHCB is mapped before updating Access to the GHCB is mainly in the VMGEXIT path and it is known that the GHCB will be mapped. But there are two paths where it is possible the GHCB might not be mapped. The sev_vcpu_deliver_sipi_vector() routine will update the GHCB to inform the caller of the AP Reset Hold NAE event that a SIPI has been delivered. However, if a SIPI is performed without a corresponding AP Reset Hold, then the GHCB might not be mapped (depending on the previous VMEXIT), which will result in a NULL pointer dereference. The svm_complete_emulated_msr() routine will update the GHCB to inform the caller of a RDMSR/WRMSR operation about any errors. While it is likely that the GHCB will be mapped in this situation, add a safe guard in this path to be certain a NULL pointer dereference is not encountered. 2024-02-28 not yet calculated CVE-2021-47008
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: KEYS: trusted: Fix memory leak on object td Two error return paths are neglecting to free allocated object td, causing a memory leak. Fix this by returning via the error return path that securely kfree’s td. Fixes clang scan-build warning: security/keys/trusted-keys/trusted_tpm1.c:496:10: warning: Potential memory leak [unix.Malloc] 2024-02-28 not yet calculated CVE-2021-47009
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: Only allow init netns to set default tcp cong to a restricted algo tcp_set_default_congestion_control() is netns-safe in that it writes to &net->ipv4.tcp_congestion_control, but it also sets ca->flags |= TCP_CONG_NON_RESTRICTED which is not namespaced. This has the unintended side-effect of changing the global net.ipv4.tcp_allowed_congestion_control sysctl, despite the fact that it is read-only: 97684f0970f6 (“net: Make tcp_allowed_congestion_control readonly in non-init netns”) Resolve this netns “leak” by only allowing the init netns to set the default algorithm to one that is restricted. This restriction could be removed if tcp_allowed_congestion_control were namespace-ified in the future. This bug was uncovered with https://github.com/JonathonReinhart/linux-netns-sysctl-verify 2024-02-28 not yet calculated CVE-2021-47010
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mm: memcontrol: slab: fix obtain a reference to a freeing memcg Patch series “Use obj_cgroup APIs to charge kmem pages”, v5. Since Roman’s series “The new cgroup slab memory controller” applied. All slab objects are charged with the new APIs of obj_cgroup. The new APIs introduce a struct obj_cgroup to charge slab objects. It prevents long-living objects from pinning the original memory cgroup in the memory. But there are still some corner objects (e.g. allocations larger than order-1 page on SLUB) which are not charged with the new APIs. Those objects (include the pages which are allocated from buddy allocator directly) are charged as kmem pages which still hold a reference to the memory cgroup. E.g. We know that the kernel stack is charged as kmem pages because the size of the kernel stack can be greater than 2 pages (e.g. 16KB on x86_64 or arm64). If we create a thread (suppose the thread stack is charged to memory cgroup A) and then move it from memory cgroup A to memory cgroup B. Because the kernel stack of the thread hold a reference to the memory cgroup A. The thread can pin the memory cgroup A in the memory even if we remove the cgroup A. If we want to see this scenario by using the following script. We can see that the system has added 500 dying cgroups (This is not a real world issue, just a script to show that the large kmallocs are charged as kmem pages which can pin the memory cgroup in the memory). #!/bin/bash cat /proc/cgroups | grep memory cd /sys/fs/cgroup/memory echo 1 > memory.move_charge_at_immigrate for i in range{1..500} do mkdir kmem_test echo $$ > kmem_test/cgroup.procs sleep 3600 & echo $$ > cgroup.procs echo `cat kmem_test/cgroup.procs` > cgroup.procs rmdir kmem_test done cat /proc/cgroups | grep memory This patchset aims to make those kmem pages to drop the reference to memory cgroup by using the APIs of obj_cgroup. Finally, we can see that the number of the dying cgroups will not increase if we run the above test script. This patch (of 7): The rcu_read_lock/unlock only can guarantee that the memcg will not be freed, but it cannot guarantee the success of css_get (which is in the refill_stock when cached memcg changed) to memcg. rcu_read_lock() memcg = obj_cgroup_memcg(old) __memcg_kmem_uncharge(memcg) refill_stock(memcg) if (stock->cached != memcg) // css_get can change the ref counter from 0 back to 1. css_get(&memcg->css) rcu_read_unlock() This fix is very like the commit: eefbfa7fd678 (“mm: memcg/slab: fix use after free in obj_cgroup_charge”) Fix this by holding a reference to the memcg which is passed to the __memcg_kmem_uncharge() before calling __memcg_kmem_uncharge(). 2024-02-28 not yet calculated CVE-2021-47011
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix a use after free in siw_alloc_mr Our code analyzer reported a UAF. In siw_alloc_mr(), it calls siw_mr_add_mem(mr,..). In the implementation of siw_mr_add_mem(), mem is assigned to mr->mem and then mem is freed via kfree(mem) if xa_alloc_cyclic() failed. Here, mr->mem still point to a freed object. After, the execution continue up to the err_out branch of siw_alloc_mr, and the freed mr->mem is used in siw_mr_drop_mem(mr). My patch moves “mr->mem = mem” behind the if (xa_alloc_cyclic(..)<0) {} section, to avoid the uaf. 2024-02-28 not yet calculated CVE-2021-47012
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net:emac/emac-mac: Fix a use after free in emac_mac_tx_buf_send In emac_mac_tx_buf_send, it calls emac_tx_fill_tpd(..,skb,..). If some error happens in emac_tx_fill_tpd(), the skb will be freed via dev_kfree_skb(skb) in error branch of emac_tx_fill_tpd(). But the freed skb is still used via skb->len by netdev_sent_queue(,skb->len). As i observed that emac_tx_fill_tpd() haven’t modified the value of skb->len, thus my patch assigns skb->len to ‘len’ before the possible free and use ‘len’ instead of skb->len later. 2024-02-28 not yet calculated CVE-2021-47013
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net/sched: act_ct: fix wild memory access when clearing fragments while testing re-assembly/re-fragmentation using act_ct, it’s possible to observe a crash like the following one: KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f] CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S 5.12.0-rc7+ #424 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0 Code: 00 fc ff df 48 89 c3 31 ed 48 89 df e8 a9 7a 38 ff 4c 89 fe 48 89 df 49 89 c6 e8 5b 3a 38 ff 48 8d 7b 40 48 89 f8 48 c1 e8 03 <42> 80 3c 20 00 75 59 48 8d bb d0 00 00 00 4c 8b 6b 40 48 89 f8 48 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203 RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350 R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000 R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160 FS: 0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> inet_frag_destroy+0xa9/0x150 call_timer_fn+0x2d/0x180 run_timer_softirq+0x4fe/0xe70 __do_softirq+0x197/0x5a0 irq_exit_rcu+0x1de/0x200 sysvec_apic_timer_interrupt+0x6b/0x80 </IRQ> when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb results in putting random data in FRAG_CB(), and this causes those “wild” memory accesses later, when the rbtree is purged. Never overwrite the skb cb in case tcf_ct_handle_fragments() returns -EINPROGRESS. 2024-02-28 not yet calculated CVE-2021-47014
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: bnxt_en: Fix RX consumer index logic in the error path. In bnxt_rx_pkt(), the RX buffers are expected to complete in order. If the RX consumer index indicates an out of order buffer completion, it means we are hitting a hardware bug and the driver will abort all remaining RX packets and reset the RX ring. The RX consumer index that we pass to bnxt_discard_rx() is not correct. We should be passing the current index (tmp_raw_cons) instead of the old index (raw_cons). This bug can cause us to be at the wrong index when trying to abort the next RX packet. It can crash like this: #0 [ffff9bbcdf5c39a8] machine_kexec at ffffffff9b05e007 #1 [ffff9bbcdf5c3a00] __crash_kexec at ffffffff9b111232 #2 [ffff9bbcdf5c3ad0] panic at ffffffff9b07d61e #3 [ffff9bbcdf5c3b50] oops_end at ffffffff9b030978 #4 [ffff9bbcdf5c3b78] no_context at ffffffff9b06aaf0 #5 [ffff9bbcdf5c3bd8] __bad_area_nosemaphore at ffffffff9b06ae2e #6 [ffff9bbcdf5c3c28] bad_area_nosemaphore at ffffffff9b06af24 #7 [ffff9bbcdf5c3c38] __do_page_fault at ffffffff9b06b67e #8 [ffff9bbcdf5c3cb0] do_page_fault at ffffffff9b06bb12 #9 [ffff9bbcdf5c3ce0] page_fault at ffffffff9bc015c5 [exception RIP: bnxt_rx_pkt+237] RIP: ffffffffc0259cdd RSP: ffff9bbcdf5c3d98 RFLAGS: 00010213 RAX: 000000005dd8097f RBX: ffff9ba4cb11b7e0 RCX: ffffa923cf6e9000 RDX: 0000000000000fff RSI: 0000000000000627 RDI: 0000000000001000 RBP: ffff9bbcdf5c3e60 R8: 0000000000420003 R9: 000000000000020d R10: ffffa923cf6ec138 R11: ffff9bbcdf5c3e83 R12: ffff9ba4d6f928c0 R13: ffff9ba4cac28080 R14: ffff9ba4cb11b7f0 R15: ffff9ba4d5a30000 ORIG_RAX: ffffffffffffffff CS: 0010 SS: 0018 2024-02-28 not yet calculated CVE-2021-47015
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: m68k: mvme147,mvme16x: Don’t wipe PCC timer config bits Don’t clear the timer 1 configuration bits when clearing the interrupt flag and counter overflow. As Michael reported, “This results in no timer interrupts being delivered after the first. Initialization then hangs in calibrate_delay as the jiffies counter is not updated.” On mvme16x, enable the timer after requesting the irq, consistent with mvme147. 2024-02-29 not yet calculated CVE-2021-47016
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ath10k: Fix a use after free in ath10k_htc_send_bundle In ath10k_htc_send_bundle, the bundle_skb could be freed by dev_kfree_skb_any(bundle_skb). But the bundle_skb is used later by bundle_skb->len. As skb_len = bundle_skb->len, my patch replaces bundle_skb->len to skb_len after the bundle_skb was freed. 2024-02-28 not yet calculated CVE-2021-47017
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: powerpc/64: Fix the definition of the fixmap area At the time being, the fixmap area is defined at the top of the address space or just below KASAN. This definition is not valid for PPC64. For PPC64, use the top of the I/O space. Because of circular dependencies, it is not possible to include asm/fixmap.h in asm/book3s/64/pgtable.h , so define a fixed size AREA at the top of the I/O space for fixmap and ensure during build that the size is big enough. 2024-02-28 not yet calculated CVE-2021-47018
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix possible invalid register access Disable the interrupt and synchronze for the pending irq handlers to ensure the irq tasklet is not being scheduled after the suspend to avoid the possible invalid register access acts when the host pcie controller is suspended. [17932.910534] mt7921e 0000:01:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 21375 usecs [17932.910590] pcieport 0000:00:00.0: calling pci_pm_suspend+0x0/0x22c @ 18565, parent: pci0000:00 [17932.910602] pcieport 0000:00:00.0: pci_pm_suspend+0x0/0x22c returned 0 after 8 usecs [17932.910671] mtk-pcie 11230000.pcie: calling platform_pm_suspend+0x0/0x60 @ 22783, parent: soc [17932.910674] mtk-pcie 11230000.pcie: platform_pm_suspend+0x0/0x60 returned 0 after 0 usecs … 17933.615352] x1 : 00000000000d4200 x0 : ffffff8269ca2300 [17933.620666] Call trace: [17933.623127] mt76_mmio_rr+0x28/0xf0 [mt76] [17933.627234] mt7921_rr+0x38/0x44 [mt7921e] [17933.631339] mt7921_irq_tasklet+0x54/0x1d8 [mt7921e] [17933.636309] tasklet_action_common+0x12c/0x16c [17933.640754] tasklet_action+0x24/0x2c [17933.644418] __do_softirq+0x16c/0x344 [17933.648082] irq_exit+0xa8/0xac [17933.651224] scheduler_ipi+0xd4/0x148 [17933.654890] handle_IPI+0x164/0x2d4 [17933.658379] gic_handle_irq+0x140/0x178 [17933.662216] el1_irq+0xb8/0x180 [17933.665361] cpuidle_enter_state+0xf8/0x204 [17933.669544] cpuidle_enter+0x38/0x4c [17933.673122] do_idle+0x1a4/0x2a8 [17933.676352] cpu_startup_entry+0x24/0x28 [17933.680276] rest_init+0xd4/0xe0 [17933.683508] arch_call_rest_init+0x10/0x18 [17933.687606] start_kernel+0x340/0x3b4 [17933.691279] Code: aa0003f5 d503201f f953eaa8 8b344108 (b9400113) [17933.697373] —[ end trace a24b8e26ffbda3c5 ]— [17933.767846] Kernel panic – not syncing: Fatal exception in interrupt 2024-02-28 not yet calculated CVE-2021-47019
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: soundwire: stream: fix memory leak in stream config error path When stream config is failed, master runtime will release all slave runtime in the slave_rt_list, but slave runtime is not added to the list at this time. This patch frees slave runtime in the config error path to fix the memory leak. 2024-02-29 not yet calculated CVE-2021-47020
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix memleak when mt7915_unregister_device() mt7915_tx_token_put() should get call before mt76_free_pending_txwi(). 2024-02-28 not yet calculated CVE-2021-47021
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: fix memleak when mt7615_unregister_device() mt7615_tx_token_put() should get call before mt76_free_pending_txwi(). 2024-02-28 not yet calculated CVE-2021-47022
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: marvell: prestera: fix port event handling on init For some reason there might be a crash during ports creation if port events are handling at the same time because fw may send initial port event with down state. The crash points to cancel_delayed_work() which is called when port went is down. Currently I did not find out the real cause of the issue, so fixed it by cancel port stats work only if previous port’s state was up & runnig. The following is the crash which can be triggered: [ 28.311104] Unable to handle kernel paging request at virtual address 000071775f776600 [ 28.319097] Mem abort info: [ 28.321914] ESR = 0x96000004 [ 28.324996] EC = 0x25: DABT (current EL), IL = 32 bits [ 28.330350] SET = 0, FnV = 0 [ 28.333430] EA = 0, S1PTW = 0 [ 28.336597] Data abort info: [ 28.339499] ISV = 0, ISS = 0x00000004 [ 28.343362] CM = 0, WnR = 0 [ 28.346354] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000100bf7000 [ 28.352842] [000071775f776600] pgd=0000000000000000, p4d=0000000000000000 [ 28.359695] Internal error: Oops: 96000004 [#1] PREEMPT SMP [ 28.365310] Modules linked in: prestera_pci(+) prestera uio_pdrv_genirq [ 28.372005] CPU: 0 PID: 1291 Comm: kworker/0:1H Not tainted 5.11.0-rc4 #1 [ 28.378846] Hardware name: DNI AmazonGo1 A7040 board (DT) [ 28.384283] Workqueue: prestera_fw_wq prestera_fw_evt_work_fn [prestera_pci] [ 28.391413] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=–) [ 28.397468] pc : get_work_pool+0x48/0x60 [ 28.401442] lr : try_to_grab_pending+0x6c/0x1b0 [ 28.406018] sp : ffff80001391bc60 [ 28.409358] x29: ffff80001391bc60 x28: 0000000000000000 [ 28.414725] x27: ffff000104fc8b40 x26: ffff80001127de88 [ 28.420089] x25: 0000000000000000 x24: ffff000106119760 [ 28.425452] x23: ffff00010775dd60 x22: ffff00010567e000 [ 28.430814] x21: 0000000000000000 x20: ffff80001391bcb0 [ 28.436175] x19: ffff00010775deb8 x18: 00000000000000c0 [ 28.441537] x17: 0000000000000000 x16: 000000008d9b0e88 [ 28.446898] x15: 0000000000000001 x14: 00000000000002ba [ 28.452261] x13: 80a3002c00000002 x12: 00000000000005f4 [ 28.457622] x11: 0000000000000030 x10: 000000000000000c [ 28.462985] x9 : 000000000000000c x8 : 0000000000000030 [ 28.468346] x7 : ffff800014400000 x6 : ffff000106119758 [ 28.473708] x5 : 0000000000000003 x4 : ffff00010775dc60 [ 28.479068] x3 : 0000000000000000 x2 : 0000000000000060 [ 28.484429] x1 : 000071775f776600 x0 : ffff00010775deb8 [ 28.489791] Call trace: [ 28.492259] get_work_pool+0x48/0x60 [ 28.495874] cancel_delayed_work+0x38/0xb0 [ 28.500011] prestera_port_handle_event+0x90/0xa0 [prestera] [ 28.505743] prestera_evt_recv+0x98/0xe0 [prestera] [ 28.510683] prestera_fw_evt_work_fn+0x180/0x228 [prestera_pci] [ 28.516660] process_one_work+0x1e8/0x360 [ 28.520710] worker_thread+0x44/0x480 [ 28.524412] kthread+0x154/0x160 [ 28.527670] ret_from_fork+0x10/0x38 [ 28.531290] Code: a8c17bfd d50323bf d65f03c0 9278dc21 (f9400020) [ 28.537429] —[ end trace 5eced933df3a080b ]— 2024-02-28 not yet calculated CVE-2021-47023
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: vsock/virtio: free queued packets when closing socket As reported by syzbot [1], there is a memory leak while closing the socket. We partially solved this issue with commit ac03046ece2b (“vsock/virtio: free packets during the socket release”), but we forgot to drain the RX queue when the socket is definitely closed by the scheduled work. To avoid future issues, let’s use the new virtio_transport_remove_sock() to drain the RX queue before removing the socket from the af_vsock lists calling vsock_remove_sock(). [1] https://syzkaller.appspot.com/bug?extid=24452624fc4c571eedd9 2024-02-28 not yet calculated CVE-2021-47024
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: iommu/mediatek: Always enable the clk on resume In mtk_iommu_runtime_resume always enable the clk, even if m4u_dom is null. Otherwise the ‘suspend’ cb might disable the clk which is already disabled causing the warning: [ 1.586104] infra_m4u already disabled [ 1.586133] WARNING: CPU: 0 PID: 121 at drivers/clk/clk.c:952 clk_core_disable+0xb0/0xb8 [ 1.594391] mtk-iommu 10205000.iommu: bound 18001000.larb (ops mtk_smi_larb_component_ops) [ 1.598108] Modules linked in: [ 1.598114] CPU: 0 PID: 121 Comm: kworker/0:2 Not tainted 5.12.0-rc5 #69 [ 1.609246] mtk-iommu 10205000.iommu: bound 14027000.larb (ops mtk_smi_larb_component_ops) [ 1.617487] Hardware name: Google Elm (DT) [ 1.617491] Workqueue: pm pm_runtime_work [ 1.620545] mtk-iommu 10205000.iommu: bound 19001000.larb (ops mtk_smi_larb_component_ops) [ 1.627229] pstate: 60000085 (nZCv daIf -PAN -UAO -TCO BTYPE=–) [ 1.659297] pc : clk_core_disable+0xb0/0xb8 [ 1.663475] lr : clk_core_disable+0xb0/0xb8 [ 1.667652] sp : ffff800011b9bbe0 [ 1.670959] x29: ffff800011b9bbe0 x28: 0000000000000000 [ 1.676267] x27: ffff800011448000 x26: ffff8000100cfd98 [ 1.681574] x25: ffff800011b9bd48 x24: 0000000000000000 [ 1.686882] x23: 0000000000000000 x22: ffff8000106fad90 [ 1.692189] x21: 000000000000000a x20: ffff0000c0048500 [ 1.697496] x19: ffff0000c0048500 x18: ffffffffffffffff [ 1.702804] x17: 0000000000000000 x16: 0000000000000000 [ 1.708112] x15: ffff800011460300 x14: fffffffffffe0000 [ 1.713420] x13: ffff8000114602d8 x12: 0720072007200720 [ 1.718727] x11: 0720072007200720 x10: 0720072007200720 [ 1.724035] x9 : ffff800011b9bbe0 x8 : ffff800011b9bbe0 [ 1.729342] x7 : 0000000000000009 x6 : ffff8000114b8328 [ 1.734649] x5 : 0000000000000000 x4 : 0000000000000000 [ 1.739956] x3 : 00000000ffffffff x2 : ffff800011460298 [ 1.745263] x1 : 1af1d7de276f4500 x0 : 0000000000000000 [ 1.750572] Call trace: [ 1.753010] clk_core_disable+0xb0/0xb8 [ 1.756840] clk_core_disable_lock+0x24/0x40 [ 1.761105] clk_disable+0x20/0x30 [ 1.764501] mtk_iommu_runtime_suspend+0x88/0xa8 [ 1.769114] pm_generic_runtime_suspend+0x2c/0x48 [ 1.773815] __rpm_callback+0xe0/0x178 [ 1.777559] rpm_callback+0x24/0x88 [ 1.781041] rpm_suspend+0xdc/0x470 [ 1.784523] rpm_idle+0x12c/0x170 [ 1.787831] pm_runtime_work+0xa8/0xc0 [ 1.791573] process_one_work+0x1e8/0x360 [ 1.795580] worker_thread+0x44/0x478 [ 1.799237] kthread+0x150/0x158 [ 1.802460] ret_from_fork+0x10/0x30 [ 1.806034] —[ end trace 82402920ef64573b ]— [ 1.810728] ————[ cut here ]———— In addition, we now don’t need to enable the clock from the function mtk_iommu_hw_init since it is already enabled by the resume. 2024-02-28 not yet calculated CVE-2021-47025
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: RDMA/rtrs-clt: destroy sysfs after removing session from active list A session can be removed dynamically by sysfs interface “remove_path” that eventually calls rtrs_clt_remove_path_from_sysfs function. The current rtrs_clt_remove_path_from_sysfs first removes the sysfs interfaces and frees sess->stats object. Second it removes the session from the active list. Therefore some functions could access non-connected session and access the freed sess->stats object even-if they check the session status before accessing the session. For instance rtrs_clt_request and get_next_path_min_inflight check the session status and try to send IO to the session. The session status could be changed when they are trying to send IO but they could not catch the change and update the statistics information in sess->stats object, and generate use-after-free problem. (see: “RDMA/rtrs-clt: Check state of the rtrs_clt_sess before reading its stats”) This patch changes the rtrs_clt_remove_path_from_sysfs to remove the session from the active session list and then destroy the sysfs interfaces. Each function still should check the session status because closing or error recovery paths can change the status. 2024-02-28 not yet calculated CVE-2021-47026
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix kernel crash when the firmware fails to download Fix kernel crash when the firmware is missing or fails to download. [ 9.444758] kernel BUG at drivers/pci/msi.c:375! [ 9.449363] Internal error: Oops – BUG: 0 [#1] PREEMPT SMP [ 9.501033] pstate: a0400009 (NzCv daif +PAN -UAO) [ 9.505814] pc : free_msi_irqs+0x180/0x184 [ 9.509897] lr : free_msi_irqs+0x40/0x184 [ 9.513893] sp : ffffffc015193870 [ 9.517194] x29: ffffffc015193870 x28: 00000000f0e94fa2 [ 9.522492] x27: 0000000000000acd x26: 000000000000009a [ 9.527790] x25: ffffffc0152cee58 x24: ffffffdbb383e0d8 [ 9.533087] x23: ffffffdbb38628d0 x22: 0000000000040200 [ 9.538384] x21: ffffff8cf7de7318 x20: ffffff8cd65a2480 [ 9.543681] x19: ffffff8cf7de7000 x18: 0000000000000000 [ 9.548979] x17: ffffff8cf9ca03b4 x16: ffffffdc13ad9a34 [ 9.554277] x15: 0000000000000000 x14: 0000000000080800 [ 9.559575] x13: ffffff8cd65a2980 x12: 0000000000000000 [ 9.564873] x11: ffffff8cfa45d820 x10: ffffff8cfa45d6d0 [ 9.570171] x9 : 0000000000000040 x8 : ffffff8ccef1b780 [ 9.575469] x7 : aaaaaaaaaaaaaaaa x6 : 0000000000000000 [ 9.580766] x5 : ffffffdc13824900 x4 : ffffff8ccefe0000 [ 9.586063] x3 : 0000000000000000 x2 : 0000000000000000 [ 9.591362] x1 : 0000000000000125 x0 : ffffff8ccefe0000 [ 9.596660] Call trace: [ 9.599095] free_msi_irqs+0x180/0x184 [ 9.602831] pci_disable_msi+0x100/0x130 [ 9.606740] pci_free_irq_vectors+0x24/0x30 [ 9.610915] mt7921_pci_probe+0xbc/0x250 [mt7921e] [ 9.615693] pci_device_probe+0xd4/0x14c [ 9.619604] really_probe+0x134/0x2ec [ 9.623252] driver_probe_device+0x64/0xfc [ 9.627335] device_driver_attach+0x4c/0x6c [ 9.631506] __driver_attach+0xac/0xc0 [ 9.635243] bus_for_each_dev+0x8c/0xd4 [ 9.639066] driver_attach+0x2c/0x38 [ 9.642628] bus_add_driver+0xfc/0x1d0 [ 9.646365] driver_register+0x64/0xf8 [ 9.650101] __pci_register_driver+0x6c/0x7c [ 9.654360] init_module+0x28/0xfdc [mt7921e] [ 9.658704] do_one_initcall+0x13c/0x2d0 [ 9.662615] do_init_module+0x58/0x1e8 [ 9.666351] load_module+0xd80/0xeb4 [ 9.669912] __arm64_sys_finit_module+0xa8/0xe0 [ 9.674430] el0_svc_common+0xa4/0x16c [ 9.678168] el0_svc_compat_handler+0x2c/0x40 [ 9.682511] el0_svc_compat+0x8/0x10 [ 9.686076] Code: a94257f6 f9400bf7 a8c47bfd d65f03c0 (d4210000) [ 9.692155] —[ end trace 7621f966afbf0a29 ]— [ 9.697385] Kernel panic – not syncing: Fatal exception [ 9.702599] SMP: stopping secondary CPUs [ 9.706549] Kernel Offset: 0x1c03600000 from 0xffffffc010000000 [ 9.712456] PHYS_OFFSET: 0xfffffff440000000 [ 9.716625] CPU features: 0x080026,2a80aa18 [ 9.720795] Memory Limit: none 2024-02-28 not yet calculated CVE-2021-47027
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix txrate reporting Properly check rate_info to fix unexpected reporting. [ 1215.161863] Call trace: [ 1215.164307] cfg80211_calculate_bitrate+0x124/0x200 [cfg80211] [ 1215.170139] ieee80211s_update_metric+0x80/0xc0 [mac80211] [ 1215.175624] ieee80211_tx_status_ext+0x508/0x838 [mac80211] [ 1215.181190] mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e] [ 1215.186580] mt7915_mac_tx_free+0x324/0x7c0 [mt7915e] [ 1215.191623] mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e] [ 1215.196582] mt76_dma_cleanup+0x7b0/0x11d0 [mt76] [ 1215.201276] __napi_poll+0x38/0xf8 [ 1215.204668] napi_workfn+0x40/0x80 [ 1215.208062] process_one_work+0x1fc/0x390 [ 1215.212062] worker_thread+0x48/0x4d0 [ 1215.215715] kthread+0x120/0x128 [ 1215.218935] ret_from_fork+0x10/0x1c 2024-02-28 not yet calculated CVE-2021-47028
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: connac: fix kernel warning adding monitor interface Fix the following kernel warning adding a monitor interface in mt76_connac_mcu_uni_add_dev routine. [ 507.984882] ————[ cut here ]———— [ 507.989515] WARNING: CPU: 1 PID: 3017 at mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib] [ 508.059379] CPU: 1 PID: 3017 Comm: ifconfig Not tainted 5.4.98 #0 [ 508.065461] Hardware name: MT7622_MT7531 RFB (DT) [ 508.070156] pstate: 80000005 (Nzcv daif -PAN -UAO) [ 508.074939] pc : mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib] [ 508.081806] lr : mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e] [ 508.087367] sp : ffffffc013a33930 [ 508.090671] x29: ffffffc013a33930 x28: ffffff801e628ac0 [ 508.095973] x27: ffffff801c7f1200 x26: ffffff801c7eb008 [ 508.101275] x25: ffffff801c7eaef0 x24: ffffff801d025610 [ 508.106577] x23: ffffff801d022990 x22: ffffff801d024de8 [ 508.111879] x21: ffffff801d0226a0 x20: ffffff801c7eaee8 [ 508.117181] x19: ffffff801d0226a0 x18: 000000005d00b000 [ 508.122482] x17: 00000000ffffffff x16: 0000000000000000 [ 508.127785] x15: 0000000000000080 x14: ffffff801d704000 [ 508.133087] x13: 0000000000000040 x12: 0000000000000002 [ 508.138389] x11: 000000000000000c x10: 0000000000000000 [ 508.143691] x9 : 0000000000000020 x8 : 0000000000000001 [ 508.148992] x7 : 0000000000000000 x6 : 0000000000000000 [ 508.154294] x5 : ffffff801c7eaee8 x4 : 0000000000000006 [ 508.159596] x3 : 0000000000000001 x2 : 0000000000000000 [ 508.164898] x1 : ffffff801c7eac08 x0 : ffffff801d0226a0 [ 508.170200] Call trace: [ 508.172640] mt76_connac_mcu_uni_add_dev+0x178/0x190 [mt76_connac_lib] [ 508.179159] mt7921_eeprom_init+0x1288/0x1cb8 [mt7921e] [ 508.184394] drv_add_interface+0x34/0x88 [mac80211] [ 508.189271] ieee80211_add_virtual_monitor+0xe0/0xb48 [mac80211] [ 508.195277] ieee80211_do_open+0x86c/0x918 [mac80211] [ 508.200328] ieee80211_do_open+0x900/0x918 [mac80211] [ 508.205372] __dev_open+0xcc/0x150 [ 508.208763] __dev_change_flags+0x134/0x198 [ 508.212937] dev_change_flags+0x20/0x60 [ 508.216764] devinet_ioctl+0x3e8/0x748 [ 508.220503] inet_ioctl+0x1e4/0x350 [ 508.223983] sock_do_ioctl+0x48/0x2a0 [ 508.227635] sock_ioctl+0x310/0x4f8 [ 508.231116] do_vfs_ioctl+0xa4/0xac0 [ 508.234681] ksys_ioctl+0x44/0x90 [ 508.237985] __arm64_sys_ioctl+0x1c/0x48 [ 508.241901] el0_svc_common.constprop.1+0x7c/0x100 [ 508.246681] el0_svc_handler+0x18/0x20 [ 508.250421] el0_svc+0x8/0x1c8 [ 508.253465] —[ end trace c7b90fee13d72c39 ]— [ 508.261278] ————[ cut here ]———— 2024-02-28 not yet calculated CVE-2021-47029
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: fix memory leak in mt7615_coredump_work Similar to the issue fixed in mt7921_coredump_work, fix a possible memory leak in mt7615_coredump_work routine. 2024-02-28 not yet calculated CVE-2021-47030
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: mt7921: fix memory leak in mt7921_coredump_work Fix possible memory leak in mt7921_coredump_work. 2024-02-28 not yet calculated CVE-2021-47031
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux In the Linux kernel, the following vulnerability has been resolved: mt76: mt7915: fix tx skb dma unmap The first pointer in the txp needs to be unmapped as well, otherwise it will leak DMA mapping entries 2024-02-28 not yet calculated CVE-2021-47032
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: mt7615: fix tx skb dma unmap The first pointer in the txp needs to be unmapped as well, otherwise it will leak DMA mapping entries 2024-02-28 not yet calculated CVE-2021-47033
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: powerpc/64s: Fix pte update for kernel memory on radix When adding a PTE a ptesync is needed to order the update of the PTE with subsequent accesses otherwise a spurious fault may be raised. radix__set_pte_at() does not do this for performance gains. For non-kernel memory this is not an issue as any faults of this kind are corrected by the page fault handler. For kernel memory these faults are not handled. The current solution is that there is a ptesync in flush_cache_vmap() which should be called when mapping from the vmalloc region. However, map_kernel_page() does not call flush_cache_vmap(). This is troublesome in particular for code patching with Strict RWX on radix. In do_patch_instruction() the page frame that contains the instruction to be patched is mapped and then immediately patched. With no ordering or synchronization between setting up the PTE and writing to the page it is possible for faults. As the code patching is done using __put_user_asm_goto() the resulting fault is obscured – but using a normal store instead it can be seen: BUG: Unable to handle kernel data access on write at 0xc008000008f24a3c Faulting instruction address: 0xc00000000008bd74 Oops: Kernel access of bad area, sig: 11 [#1] LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA PowerNV Modules linked in: nop_module(PO+) [last unloaded: nop_module] CPU: 4 PID: 757 Comm: sh Tainted: P O 5.10.0-rc5-01361-ge3c1b78c8440-dirty #43 NIP: c00000000008bd74 LR: c00000000008bd50 CTR: c000000000025810 REGS: c000000016f634a0 TRAP: 0300 Tainted: P O (5.10.0-rc5-01361-ge3c1b78c8440-dirty) MSR: 9000000000009033 <SF,HV,EE,ME,IR,DR,RI,LE> CR: 44002884 XER: 00000000 CFAR: c00000000007c68c DAR: c008000008f24a3c DSISR: 42000000 IRQMASK: 1 This results in the kind of issue reported here: https://lore.kernel.org/linuxppc-dev/15AC5B0E-A221-4B8C-9039-FA96B8EF7C88@lca.pw/ Chris Riedl suggested a reliable way to reproduce the issue: $ mount -t debugfs none /sys/kernel/debug $ (while true; do echo function > /sys/kernel/debug/tracing/current_tracer ; echo nop > /sys/kernel/debug/tracing/current_tracer ; done) & Turning ftrace on and off does a large amount of code patching which in usually less then 5min will crash giving a trace like: ftrace-powerpc: (____ptrval____): replaced (4b473b11) != old (60000000) ————[ ftrace bug ]———— ftrace failed to modify [<c000000000bf8e5c>] napi_busy_loop+0xc/0x390 actual: 11:3b:47:4b Setting ftrace call site to call ftrace function ftrace record flags: 80000001 (1) expected tramp: c00000000006c96c ————[ cut here ]———— WARNING: CPU: 4 PID: 809 at kernel/trace/ftrace.c:2065 ftrace_bug+0x28c/0x2e8 Modules linked in: nop_module(PO-) [last unloaded: nop_module] CPU: 4 PID: 809 Comm: sh Tainted: P O 5.10.0-rc5-01360-gf878ccaf250a #1 NIP: c00000000024f334 LR: c00000000024f330 CTR: c0000000001a5af0 REGS: c000000004c8b760 TRAP: 0700 Tainted: P O (5.10.0-rc5-01360-gf878ccaf250a) MSR: 900000000282b033 <SF,HV,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28008848 XER: 20040000 CFAR: c0000000001a9c98 IRQMASK: 0 GPR00: c00000000024f330 c000000004c8b9f0 c000000002770600 0000000000000022 GPR04: 00000000ffff7fff c000000004c8b6d0 0000000000000027 c0000007fe9bcdd8 GPR08: 0000000000000023 ffffffffffffffd8 0000000000000027 c000000002613118 GPR12: 0000000000008000 c0000007fffdca00 0000000000000000 0000000000000000 GPR16: 0000000023ec37c5 0000000000000000 0000000000000000 0000000000000008 GPR20: c000000004c8bc90 c0000000027a2d20 c000000004c8bcd0 c000000002612fe8 GPR24: 0000000000000038 0000000000000030 0000000000000028 0000000000000020 GPR28: c000000000ff1b68 c000000000bf8e5c c00000000312f700 c000000000fbb9b0 NIP ftrace_bug+0x28c/0x2e8 LR ftrace_bug+0x288/0x2e8 Call T —truncated— 2024-02-28 not yet calculated CVE-2021-47034
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Remove WO permissions on second-level paging entries When the first level page table is used for IOVA translation, it only supports Read-Only and Read-Write permissions. The Write-Only permission is not supported as the PRESENT bit (implying Read permission) should always set. When using second level, we still give separate permissions that allows WriteOnly which seems inconsistent and awkward. We want to have consistent behavior. After moving to 1st level, we don’t want things to work sometimes, and break if we use 2nd level for the same mappings. Hence remove this configuration. 2024-02-28 not yet calculated CVE-2021-47035
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: udp: skip L4 aggregation for UDP tunnel packets If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there are UDP tunnels available in the system, udp_gro_receive() could end-up doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at the outer UDP tunnel level for packets effectively carrying and UDP tunnel header. That could cause inner protocol corruption. If e.g. the relevant packets carry a vxlan header, different vxlan ids will be ignored/ aggregated to the same GSO packet. Inner headers will be ignored, too, so that e.g. TCP over vxlan push packets will be held in the GRO engine till the next flush, etc. Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the current packet could land in a UDP tunnel, and let udp_gro_receive() do GRO via udp_sk(sk)->gro_receive. The check implemented in this patch is broader than what is strictly needed, as the existing UDP tunnel could be e.g. configured on top of a different device: we could end-up skipping GRO at-all for some packets. Anyhow, that is a very thin corner case and covering it will add quite a bit of complexity. v1 -> v2: – hopefully clarify the commit message 2024-02-28 not yet calculated CVE-2021-47036
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ASoC: q6afe-clocks: fix reprobing of the driver Q6afe-clocks driver can get reprobed. For example if the APR services are restarted after the firmware crash. However currently Q6afe-clocks driver will oops because hw.init will get cleared during first _probe call. Rewrite the driver to fill the clock data at runtime rather than using big static array of clocks. 2024-02-28 not yet calculated CVE-2021-47037
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: Bluetooth: avoid deadlock between hci_dev->lock and socket lock Commit eab2404ba798 (“Bluetooth: Add BT_PHY socket option”) added a dependency between socket lock and hci_dev->lock that could lead to deadlock. It turns out that hci_conn_get_phy() is not in any way relying on hdev being immutable during the runtime of this function, neither does it even look at any of the members of hdev, and as such there is no need to hold that lock. This fixes the lockdep splat below: ====================================================== WARNING: possible circular locking dependency detected 5.12.0-rc1-00026-g73d464503354 #10 Not tainted —————————————————— bluetoothd/1118 is trying to acquire lock: ffff8f078383c078 (&hdev->lock){+.+.}-{3:3}, at: hci_conn_get_phy+0x1c/0x150 [bluetooth] but task is already holding lock: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #3 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}: lock_sock_nested+0x72/0xa0 l2cap_sock_ready_cb+0x18/0x70 [bluetooth] l2cap_config_rsp+0x27a/0x520 [bluetooth] l2cap_sig_channel+0x658/0x1330 [bluetooth] l2cap_recv_frame+0x1ba/0x310 [bluetooth] hci_rx_work+0x1cc/0x640 [bluetooth] process_one_work+0x244/0x5f0 worker_thread+0x3c/0x380 kthread+0x13e/0x160 ret_from_fork+0x22/0x30 -> #2 (&chan->lock#2/1){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x33a/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #1 (&conn->chan_lock){+.+.}-{3:3}: __mutex_lock+0xa3/0xa10 l2cap_chan_connect+0x322/0x940 [bluetooth] l2cap_sock_connect+0x141/0x2a0 [bluetooth] __sys_connect+0x9b/0xc0 __x64_sys_connect+0x16/0x20 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae -> #0 (&hdev->lock){+.+.}-{3:3}: __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 __mutex_lock+0xa3/0xa10 hci_conn_get_phy+0x1c/0x150 [bluetooth] l2cap_sock_getsockopt+0x5a9/0x610 [bluetooth] __sys_getsockopt+0xcc/0x200 __x64_sys_getsockopt+0x20/0x30 do_syscall_64+0x33/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae other info that might help us debug this: Chain exists of: &hdev->lock –> &chan->lock#2/1 –> sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP Possible unsafe locking scenario: CPU0 CPU1 —- —- lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&chan->lock#2/1); lock(sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP); lock(&hdev->lock); *** DEADLOCK *** 1 lock held by bluetoothd/1118: #0: ffff8f07e831d920 (sk_lock-AF_BLUETOOTH-BTPROTO_L2CAP){+.+.}-{0:0}, at: l2cap_sock_getsockopt+0x8b/0x610 [bluetooth] stack backtrace: CPU: 3 PID: 1118 Comm: bluetoothd Not tainted 5.12.0-rc1-00026-g73d464503354 #10 Hardware name: LENOVO 20K5S22R00/20K5S22R00, BIOS R0IET38W (1.16 ) 05/31/2017 Call Trace: dump_stack+0x7f/0xa1 check_noncircular+0x105/0x120 ? __lock_acquire+0x147a/0x1a50 __lock_acquire+0x147a/0x1a50 lock_acquire+0x277/0x3d0 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? __lock_acquire+0x2e1/0x1a50 ? lock_is_held_type+0xb4/0x120 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] __mutex_lock+0xa3/0xa10 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] ? lock_acquire+0x277/0x3d0 ? mark_held_locks+0x49/0x70 ? mark_held_locks+0x49/0x70 ? hci_conn_get_phy+0x1c/0x150 [bluetooth] hci_conn_get_phy+0x —truncated— 2024-02-28 not yet calculated CVE-2021-47038
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ataflop: potential out of bounds in do_format() The function uses “type” as an array index: q = unit[drive].disk[type]->queue; Unfortunately the bounds check on “type” isn’t done until later in the function. Fix this by moving the bounds check to the start. 2024-02-28 not yet calculated CVE-2021-47039
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: io_uring: fix overflows checks in provide buffers Colin reported before possible overflow and sign extension problems in io_provide_buffers_prep(). As Linus pointed out previous attempt did nothing useful, see d81269fecb8ce (“io_uring: fix provide_buffers sign extension”). Do that with help of check_<op>_overflow helpers. And fix struct io_provide_buf::len type, as it doesn’t make much sense to keep it signed. 2024-02-28 not yet calculated CVE-2021-47040
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: fix incorrect locking in state_change sk callback We are not changing anything in the TCP connection state so we should not take a write_lock but rather a read lock. This caused a deadlock when running nvmet-tcp and nvme-tcp on the same system, where state_change callbacks on the host and on the controller side have causal relationship and made lockdep report on this with blktests: ================================ WARNING: inconsistent lock state 5.12.0-rc3 #1 Tainted: G I ——————————– inconsistent {IN-SOFTIRQ-W} -> {SOFTIRQ-ON-R} usage. nvme/1324 [HC0[0]:SC0[0]:HE1:SE1] takes: ffff888363151000 (clock-AF_INET){++-?}-{2:2}, at: nvme_tcp_state_change+0x21/0x150 [nvme_tcp] {IN-SOFTIRQ-W} state was registered at: __lock_acquire+0x79b/0x18d0 lock_acquire+0x1ca/0x480 _raw_write_lock_bh+0x39/0x80 nvmet_tcp_state_change+0x21/0x170 [nvmet_tcp] tcp_fin+0x2a8/0x780 tcp_data_queue+0xf94/0x1f20 tcp_rcv_established+0x6ba/0x1f00 tcp_v4_do_rcv+0x502/0x760 tcp_v4_rcv+0x257e/0x3430 ip_protocol_deliver_rcu+0x69/0x6a0 ip_local_deliver_finish+0x1e2/0x2f0 ip_local_deliver+0x1a2/0x420 ip_rcv+0x4fb/0x6b0 __netif_receive_skb_one_core+0x162/0x1b0 process_backlog+0x1ff/0x770 __napi_poll.constprop.0+0xa9/0x5c0 net_rx_action+0x7b3/0xb30 __do_softirq+0x1f0/0x940 do_softirq+0xa1/0xd0 __local_bh_enable_ip+0xd8/0x100 ip_finish_output2+0x6b7/0x18a0 __ip_queue_xmit+0x706/0x1aa0 __tcp_transmit_skb+0x2068/0x2e20 tcp_write_xmit+0xc9e/0x2bb0 __tcp_push_pending_frames+0x92/0x310 inet_shutdown+0x158/0x300 __nvme_tcp_stop_queue+0x36/0x270 [nvme_tcp] nvme_tcp_stop_queue+0x87/0xb0 [nvme_tcp] nvme_tcp_teardown_admin_queue+0x69/0xe0 [nvme_tcp] nvme_do_delete_ctrl+0x100/0x10c [nvme_core] nvme_sysfs_delete.cold+0x8/0xd [nvme_core] kernfs_fop_write_iter+0x2c7/0x460 new_sync_write+0x36c/0x610 vfs_write+0x5c0/0x870 ksys_write+0xf9/0x1d0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae irq event stamp: 10687 hardirqs last enabled at (10687): [<ffffffff9ec376bd>] _raw_spin_unlock_irqrestore+0x2d/0x40 hardirqs last disabled at (10686): [<ffffffff9ec374d8>] _raw_spin_lock_irqsave+0x68/0x90 softirqs last enabled at (10684): [<ffffffff9f000608>] __do_softirq+0x608/0x940 softirqs last disabled at (10649): [<ffffffff9cdedd31>] do_softirq+0xa1/0xd0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 —- lock(clock-AF_INET); <Interrupt> lock(clock-AF_INET); *** DEADLOCK *** 5 locks held by nvme/1324: #0: ffff8884a01fe470 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0xf9/0x1d0 #1: ffff8886e435c090 (&of->mutex){+.+.}-{3:3}, at: kernfs_fop_write_iter+0x216/0x460 #2: ffff888104d90c38 (kn->active#255){++++}-{0:0}, at: kernfs_remove_self+0x22d/0x330 #3: ffff8884634538d0 (&queue->queue_lock){+.+.}-{3:3}, at: nvme_tcp_stop_queue+0x52/0xb0 [nvme_tcp] #4: ffff888363150d30 (sk_lock-AF_INET){+.+.}-{0:0}, at: inet_shutdown+0x59/0x300 stack backtrace: CPU: 26 PID: 1324 Comm: nvme Tainted: G I 5.12.0-rc3 #1 Hardware name: Dell Inc. PowerEdge R640/06NR82, BIOS 2.10.0 11/12/2020 Call Trace: dump_stack+0x93/0xc2 mark_lock_irq.cold+0x2c/0xb3 ? verify_lock_unused+0x390/0x390 ? stack_trace_consume_entry+0x160/0x160 ? lock_downgrade+0x100/0x100 ? save_trace+0x88/0x5e0 ? _raw_spin_unlock_irqrestore+0x2d/0x40 mark_lock+0x530/0x1470 ? mark_lock_irq+0x1d10/0x1d10 ? enqueue_timer+0x660/0x660 mark_usage+0x215/0x2a0 __lock_acquire+0x79b/0x18d0 ? tcp_schedule_loss_probe.part.0+0x38c/0x520 lock_acquire+0x1ca/0x480 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? rcu_read_unlock+0x40/0x40 ? tcp_mtu_probe+0x1ae0/0x1ae0 ? kmalloc_reserve+0xa0/0xa0 ? sysfs_file_ops+0x170/0x170 _raw_read_lock+0x3d/0xa0 ? nvme_tcp_state_change+0x21/0x150 [nvme_tcp] nvme_tcp_state_change+0x21/0x150 [nvme_tcp] ? sysfs_file_ops —truncated— 2024-02-28 not yet calculated CVE-2021-47041
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Free local data after use Fixes the following memory leak in dc_link_construct(): unreferenced object 0xffffa03e81471400 (size 1024): comm “amd_module_load”, pid 2486, jiffies 4294946026 (age 10.544s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<000000000bdf5c4a>] kmem_cache_alloc_trace+0x30a/0x4a0 [<00000000e7c59f0e>] link_create+0xce/0xac0 [amdgpu] [<000000002fb6c072>] dc_create+0x370/0x720 [amdgpu] [<000000000094d1f3>] amdgpu_dm_init+0x18e/0x17a0 [amdgpu] [<00000000bec048fd>] dm_hw_init+0x12/0x20 [amdgpu] [<00000000a2bb7cf6>] amdgpu_device_init+0x1463/0x1e60 [amdgpu] [<0000000032d3bb13>] amdgpu_driver_load_kms+0x5b/0x330 [amdgpu] [<00000000a27834f9>] amdgpu_pci_probe+0x192/0x280 [amdgpu] [<00000000fec7d291>] local_pci_probe+0x47/0xa0 [<0000000055dbbfa7>] pci_device_probe+0xe3/0x180 [<00000000815da970>] really_probe+0x1c4/0x4e0 [<00000000b4b6974b>] driver_probe_device+0x62/0x150 [<000000000f9ecc61>] device_driver_attach+0x58/0x60 [<000000000f65c843>] __driver_attach+0xd6/0x150 [<000000002f5e3683>] bus_for_each_dev+0x6a/0xc0 [<00000000a1cfc897>] driver_attach+0x1e/0x20 2024-02-28 not yet calculated CVE-2021-47042
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: media: venus: core: Fix some resource leaks in the error path of ‘venus_probe()’ If an error occurs after a successful ‘of_icc_get()’ call, it must be undone. Use ‘devm_of_icc_get()’ instead of ‘of_icc_get()’ to avoid the leak. Update the remove function accordingly and axe the now unneeded ‘icc_put()’ calls. 2024-02-28 not yet calculated CVE-2021-47043
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: sched/fair: Fix shift-out-of-bounds in load_balance() Syzbot reported a handful of occurrences where an sd->nr_balance_failed can grow to much higher values than one would expect. A successful load_balance() resets it to 0; a failed one increments it. Once it gets to sd->cache_nice_tries + 3, this *should* trigger an active balance, which will either set it to sd->cache_nice_tries+1 or reset it to 0. However, in case the to-be-active-balanced task is not allowed to run on env->dst_cpu, then the increment is done without any further modification. This could then be repeated ad nauseam, and would explain the absurdly high values reported by syzbot (86, 149). VincentG noted there is value in letting sd->cache_nice_tries grow, so the shift itself should be fixed. That means preventing: “”” If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined. “”” Thus we need to cap the shift exponent to BITS_PER_TYPE(typeof(lefthand)) – 1. I had a look around for other similar cases via coccinelle: @expr@ position pos; expression E1; expression E2; @@ ( E1 >> E2@pos | E1 >> E2@pos ) @cst depends on expr@ position pos; expression expr.E1; constant cst; @@ ( E1 >> cst@pos | E1 << cst@pos ) @script:python depends on !cst@ pos << expr.pos; exp << expr.E2; @@ # Dirty hack to ignore constexpr if exp.upper() != exp: coccilib.report.print_report(pos[0], “Possible UB shift here”) The only other match in kernel/sched is rq_clock_thermal() which employs sched_thermal_decay_shift, and that exponent is already capped to 10, so that one is fine. 2024-02-28 not yet calculated CVE-2021-47044
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: scsi: lpfc: Fix null pointer dereference in lpfc_prep_els_iocb() It is possible to call lpfc_issue_els_plogi() passing a did for which no matching ndlp is found. A call is then made to lpfc_prep_els_iocb() with a null pointer to a lpfc_nodelist structure resulting in a null pointer dereference. Fix by returning an error status if no valid ndlp is found. Fix up comments regarding ndlp reference counting. 2024-02-28 not yet calculated CVE-2021-47045
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix off by one in hdmi_14_process_transaction() The hdcp_i2c_offsets[] array did not have an entry for HDCP_MESSAGE_ID_WRITE_CONTENT_STREAM_TYPE so it led to an off by one read overflow. I added an entry and copied the 0x0 value for the offset from similar code in drivers/gpu/drm/amd/display/modules/hdcp/hdcp_ddc.c. I also declared several of these arrays as having HDCP_MESSAGE_ID_MAX entries. This doesn’t change the code, but it’s just a belt and suspenders approach to try future proof the code. 2024-02-28 not yet calculated CVE-2021-47046
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynqmp-gqspi: return -ENOMEM if dma_map_single fails The spi controller supports 44-bit address space on AXI in DMA mode, so set dma_addr_t width to 44-bit to avoid using a swiotlb mapping. In addition, if dma_map_single fails, it should return immediately instead of continuing doing the DMA operation which bases on invalid address. This fixes the following crash which occurs in reading a big block from flash: [ 123.633577] zynqmp-qspi ff0f0000.spi: swiotlb buffer is full (sz: 4194304 bytes), total 32768 (slots), used 0 (slots) [ 123.644230] zynqmp-qspi ff0f0000.spi: ERR:rxdma:memory not mapped [ 123.784625] Unable to handle kernel paging request at virtual address 00000000003fffc0 [ 123.792536] Mem abort info: [ 123.795313] ESR = 0x96000145 [ 123.798351] EC = 0x25: DABT (current EL), IL = 32 bits [ 123.803655] SET = 0, FnV = 0 [ 123.806693] EA = 0, S1PTW = 0 [ 123.809818] Data abort info: [ 123.812683] ISV = 0, ISS = 0x00000145 [ 123.816503] CM = 1, WnR = 1 [ 123.819455] user pgtable: 4k pages, 48-bit VAs, pgdp=0000000805047000 [ 123.825887] [00000000003fffc0] pgd=0000000803b45003, p4d=0000000803b45003, pud=0000000000000000 [ 123.834586] Internal error: Oops: 96000145 [#1] PREEMPT SMP 2024-02-28 not yet calculated CVE-2021-47047
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: spi: spi-zynqmp-gqspi: fix use-after-free in zynqmp_qspi_exec_op When handling op->addr, it is using the buffer “tmpbuf” which has been freed. This will trigger a use-after-free KASAN warning. Let’s use temporary variables to store op->addr.val and op->cmd.opcode to fix this issue. 2024-02-28 not yet calculated CVE-2021-47048
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: Drivers: hv: vmbus: Use after free in __vmbus_open() The “open_info” variable is added to the &vmbus_connection.chn_msg_list, but the error handling frees “open_info” without removing it from the list. This will result in a use after free. First remove it from the list, and then free it. 2024-02-28 not yet calculated CVE-2021-47049
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: memory: renesas-rpc-if: fix possible NULL pointer dereference of resource The platform_get_resource_byname() can return NULL which would be immediately dereferenced by resource_size(). Instead dereference it after validating the resource. Addresses-Coverity: Dereference null return value 2024-02-28 not yet calculated CVE-2021-47050
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: spi: fsl-lpspi: Fix PM reference leak in lpspi_prepare_xfer_hardware() pm_runtime_get_sync will increment pm usage counter even it failed. Forgetting to putting operation will result in reference leak here. Fix it by replacing it with pm_runtime_resume_and_get to keep usage counter balanced. 2024-02-28 not yet calculated CVE-2021-47051
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: crypto: sa2ul – Fix memory leak of rxd There are two error return paths that are not freeing rxd and causing memory leaks. Fix these. Addresses-Coverity: (“Resource leak”) 2024-02-28 not yet calculated CVE-2021-47052
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss – Fix memory leak of pad It appears there are several failure return paths that don’t seem to be free’ing pad. Fix these. Addresses-Coverity: (“Resource leak”) 2024-02-28 not yet calculated CVE-2021-47053
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: bus: qcom: Put child node before return Put child node before return to fix potential reference count leak. Generally, the reference count of child is incremented and decremented automatically in the macro for_each_available_child_of_node() and should be decremented manually if the loop is broken in loop body. 2024-02-29 not yet calculated CVE-2021-47054
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mtd: require write permissions for locking and badblock ioctls MEMLOCK, MEMUNLOCK and OTPLOCK modify protection bits. Thus require write permission. Depending on the hardware MEMLOCK might even be write-once, e.g. for SPI-NOR flashes with their WP# tied to GND. OTPLOCK is always write-once. MEMSETBADBLOCK modifies the bad block table. 2024-02-29 not yet calculated CVE-2021-47055
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: crypto: qat – ADF_STATUS_PF_RUNNING should be set after adf_dev_init ADF_STATUS_PF_RUNNING is (only) used and checked by adf_vf2pf_shutdown() before calling adf_iov_putmsg()->mutex_lock(vf2pf_lock), however the vf2pf_lock is initialized in adf_dev_init(), which can fail and when it fail, the vf2pf_lock is either not initialized or destroyed, a subsequent use of vf2pf_lock will cause issue. To fix this issue, only set this flag if adf_dev_init() returns 0. [ 7.178404] BUG: KASAN: user-memory-access in __mutex_lock.isra.0+0x1ac/0x7c0 [ 7.180345] Call Trace: [ 7.182576] mutex_lock+0xc9/0xd0 [ 7.183257] adf_iov_putmsg+0x118/0x1a0 [intel_qat] [ 7.183541] adf_vf2pf_shutdown+0x4d/0x7b [intel_qat] [ 7.183834] adf_dev_shutdown+0x172/0x2b0 [intel_qat] [ 7.184127] adf_probe+0x5e9/0x600 [qat_dh895xccvf] 2024-02-29 not yet calculated CVE-2021-47056
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss – Fix memory leak of object d when dma_iv fails to map In the case where the dma_iv mapping fails, the return error path leaks the memory allocated to object d. Fix this by adding a new error return label and jumping to this to ensure d is free’d before the return. Addresses-Coverity: (“Resource leak”) 2024-02-29 not yet calculated CVE-2021-47057
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: regmap: set debugfs_name to NULL after it is freed There is a upstream commit cffa4b2122f5(“regmap:debugfs: Fix a memory leak when calling regmap_attach_dev”) that adds a if condition when create name for debugfs_name. With below function invoking logical, debugfs_name is freed in regmap_debugfs_exit(), but it is not created again because of the if condition introduced by above commit. regmap_reinit_cache() regmap_debugfs_exit() … regmap_debugfs_init() So, set debugfs_name to NULL after it is freed. 2024-02-29 not yet calculated CVE-2021-47058
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: crypto: sun8i-ss – fix result memory leak on error path This patch fixes a memory leak on an error path. 2024-02-29 not yet calculated CVE-2021-47059
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: KVM: Stop looking for coalesced MMIO zones if the bus is destroyed Abort the walk of coalesced MMIO zones if kvm_io_bus_unregister_dev() fails to allocate memory for the new instance of the bus. If it can’t instantiate a new bus, unregister_dev() destroys all devices _except_ the target device. But, it doesn’t tell the caller that it obliterated the bus and invoked the destructor for all devices that were on the bus. In the coalesced MMIO case, this can result in a deleted list entry dereference due to attempting to continue iterating on coalesced_zones after future entries (in the walk) have been deleted. Opportunistically add curly braces to the for-loop, which encompasses many lines but sneaks by without braces due to the guts being a single if statement. 2024-02-29 not yet calculated CVE-2021-47060
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: KVM: Destroy I/O bus devices on unregister failure _after_ sync’ing SRCU If allocating a new instance of an I/O bus fails when unregistering a device, wait to destroy the device until after all readers are guaranteed to see the new null bus. Destroying devices before the bus is nullified could lead to use-after-free since readers expect the devices on their reference of the bus to remain valid. 2024-02-29 not yet calculated CVE-2021-47061
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: KVM: SVM: Use online_vcpus, not created_vcpus, to iterate over vCPUs Use the kvm_for_each_vcpu() helper to iterate over vCPUs when encrypting VMSAs for SEV, which effectively switches to use online_vcpus instead of created_vcpus. This fixes a possible null-pointer dereference as created_vcpus does not guarantee a vCPU exists, since it is updated at the very beginning of KVM_CREATE_VCPU. created_vcpus exists to allow the bulk of vCPU creation to run in parallel, while still correctly restricting the max number of max vCPUs. 2024-02-29 not yet calculated CVE-2021-47062
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm: bridge/panel: Cleanup connector on bridge detach If we don’t call drm_connector_cleanup() manually in panel_bridge_detach(), the connector will be cleaned up with the other DRM objects in the call to drm_mode_config_cleanup(). However, since our drm_connector is devm-allocated, by the time drm_mode_config_cleanup() will be called, our connector will be long gone. Therefore, the connector must be cleaned up when the bridge is detached to avoid use-after-free conditions. v2: Cleanup connector only if it was created v3: Add FIXME v4: (Use connector->dev) directly in if() block 2024-02-29 not yet calculated CVE-2021-47063
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mt76: fix potential DMA mapping leak With buf uninitialized in mt76_dma_tx_queue_skb_raw, its field skip_unmap could potentially inherit a non-zero value from stack garbage. If this happens, it will cause DMA mappings for MCU command frames to not be unmapped after completion 2024-02-29 not yet calculated CVE-2021-47064
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: rtw88: Fix array overrun in rtw_get_tx_power_params() Using a kernel with the Undefined Behaviour Sanity Checker (UBSAN) enabled, the following array overrun is logged: ================================================================================ UBSAN: array-index-out-of-bounds in /home/finger/wireless-drivers-next/drivers/net/wireless/realtek/rtw88/phy.c:1789:34 index 5 is out of range for type ‘u8 [5]’ CPU: 2 PID: 84 Comm: kworker/u16:3 Tainted: G O 5.12.0-rc5-00086-gd88bba47038e-dirty #651 Hardware name: TOSHIBA TECRA A50-A/TECRA A50-A, BIOS Version 4.50 09/29/2014 Workqueue: phy0 ieee80211_scan_work [mac80211] Call Trace: dump_stack+0x64/0x7c ubsan_epilogue+0x5/0x40 __ubsan_handle_out_of_bounds.cold+0x43/0x48 rtw_get_tx_power_params+0x83a/drivers/net/wireless/realtek/rtw88/0xad0 [rtw_core] ? rtw_pci_read16+0x20/0x20 [rtw_pci] ? check_hw_ready+0x50/0x90 [rtw_core] rtw_phy_get_tx_power_index+0x4d/0xd0 [rtw_core] rtw_phy_set_tx_power_level+0xee/0x1b0 [rtw_core] rtw_set_channel+0xab/0x110 [rtw_core] rtw_ops_config+0x87/0xc0 [rtw_core] ieee80211_hw_config+0x9d/0x130 [mac80211] ieee80211_scan_state_set_channel+0x81/0x170 [mac80211] ieee80211_scan_work+0x19f/0x2a0 [mac80211] process_one_work+0x1dd/0x3a0 worker_thread+0x49/0x330 ? rescuer_thread+0x3a0/0x3a0 kthread+0x134/0x150 ? kthread_create_worker_on_cpu+0x70/0x70 ret_from_fork+0x22/0x30 ================================================================================ The statement where an array is being overrun is shown in the following snippet: if (rate <= DESC_RATE11M) tx_power = pwr_idx_2g->cck_base[group]; else ====> tx_power = pwr_idx_2g->bw40_base[group]; The associated arrays are defined in main.h as follows: struct rtw_2g_txpwr_idx { u8 cck_base[6]; u8 bw40_base[5]; struct rtw_2g_1s_pwr_idx_diff ht_1s_diff; struct rtw_2g_ns_pwr_idx_diff ht_2s_diff; struct rtw_2g_ns_pwr_idx_diff ht_3s_diff; struct rtw_2g_ns_pwr_idx_diff ht_4s_diff; }; The problem arises because the value of group is 5 for channel 14. The trivial increase in the dimension of bw40_base fails as this struct must match the layout of efuse. The fix is to add the rate as an argument to rtw_get_channel_group() and set the group for channel 14 to 4 if rate <= DESC_RATE11M. This patch fixes commit fa6dfe6bff24 (“rtw88: resolve order of tx power setting routines”) 2024-02-29 not yet calculated CVE-2021-47065
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: async_xor: increase src_offs when dropping destination page Now we support sharing one page if PAGE_SIZE is not equal stripe size. To support this, it needs to support calculating xor value with different offsets for each r5dev. One offset array is used to record those offsets. In RMW mode, parity page is used as a source page. It sets ASYNC_TX_XOR_DROP_DST before calculating xor value in ops_run_prexor5. So it needs to add src_list and src_offs at the same time. Now it only needs src_list. So the xor value which is calculated is wrong. It can cause data corruption problem. I can reproduce this problem 100% on a POWER8 machine. The steps are: mdadm -CR /dev/md0 -l5 -n3 /dev/sdb1 /dev/sdc1 /dev/sdd1 –size=3G mkfs.xfs /dev/md0 mount /dev/md0 /mnt/test mount: /mnt/test: mount(2) system call failed: Structure needs cleaning. 2024-02-29 not yet calculated CVE-2021-47066
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: soc/tegra: regulators: Fix locking up when voltage-spread is out of range Fix voltage coupler lockup which happens when voltage-spread is out of range due to a bug in the code. The max-spread requirement shall be accounted when CPU regulator doesn’t have consumers. This problem is observed on Tegra30 Ouya game console once system-wide DVFS is enabled in a device-tree. 2024-02-29 not yet calculated CVE-2021-47067
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net/nfc: fix use-after-free llcp_sock_bind/connect Commits 8a4cd82d (“nfc: fix refcount leak in llcp_sock_connect()”) and c33b1cc62 (“nfc: fix refcount leak in llcp_sock_bind()”) fixed a refcount leak bug in bind/connect but introduced a use-after-free if the same local is assigned to 2 different sockets. This can be triggered by the following simple program: int sock1 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); int sock2 = socket( AF_NFC, SOCK_STREAM, NFC_SOCKPROTO_LLCP ); memset( &addr, 0, sizeof(struct sockaddr_nfc_llcp) ); addr.sa_family = AF_NFC; addr.nfc_protocol = NFC_PROTO_NFC_DEP; bind( sock1, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) bind( sock2, (struct sockaddr*) &addr, sizeof(struct sockaddr_nfc_llcp) ) close(sock1); close(sock2); Fix this by assigning NULL to llcp_sock->local after calling nfc_llcp_local_put. This addresses CVE-2021-23134. 2024-02-29 not yet calculated CVE-2021-47068
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ipc/mqueue, msg, sem: avoid relying on a stack reference past its expiry do_mq_timedreceive calls wq_sleep with a stack local address. The sender (do_mq_timedsend) uses this address to later call pipelined_send. This leads to a very hard to trigger race where a do_mq_timedreceive call might return and leave do_mq_timedsend to rely on an invalid address, causing the following crash: RIP: 0010:wake_q_add_safe+0x13/0x60 Call Trace: __x64_sys_mq_timedsend+0x2a9/0x490 do_syscall_64+0x80/0x680 entry_SYSCALL_64_after_hwframe+0x44/0xa9 RIP: 0033:0x7f5928e40343 The race occurs as: 1. do_mq_timedreceive calls wq_sleep with the address of `struct ext_wait_queue` on function stack (aliased as `ewq_addr` here) – it holds a valid `struct ext_wait_queue *` as long as the stack has not been overwritten. 2. `ewq_addr` gets added to info->e_wait_q[RECV].list in wq_add, and do_mq_timedsend receives it via wq_get_first_waiter(info, RECV) to call __pipelined_op. 3. Sender calls __pipelined_op::smp_store_release(&this->state, STATE_READY). Here is where the race window begins. (`this` is `ewq_addr`.) 4. If the receiver wakes up now in do_mq_timedreceive::wq_sleep, it will see `state == STATE_READY` and break. 5. do_mq_timedreceive returns, and `ewq_addr` is no longer guaranteed to be a `struct ext_wait_queue *` since it was on do_mq_timedreceive’s stack. (Although the address may not get overwritten until another function happens to touch it, which means it can persist around for an indefinite time.) 6. do_mq_timedsend::__pipelined_op() still believes `ewq_addr` is a `struct ext_wait_queue *`, and uses it to find a task_struct to pass to the wake_q_add_safe call. In the lucky case where nothing has overwritten `ewq_addr` yet, `ewq_addr->task` is the right task_struct. In the unlucky case, __pipelined_op::wake_q_add_safe gets handed a bogus address as the receiver’s task_struct causing the crash. do_mq_timedsend::__pipelined_op() should not dereference `this` after setting STATE_READY, as the receiver counterpart is now free to return. Change __pipelined_op to call wake_q_add_safe on the receiver’s task_struct returned by get_task_struct, instead of dereferencing `this` which sits on the receiver’s stack. As Manfred pointed out, the race potentially also exists in ipc/msg.c::expunge_all and ipc/sem.c::wake_up_sem_queue_prepare. Fix those in the same way. 2024-03-01 not yet calculated CVE-2021-47069
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix another memory leak in error handling paths Memory allocated by ‘vmbus_alloc_ring()’ at the beginning of the probe function is never freed in the error handling path. Add the missing ‘vmbus_free_ring()’ call. Note that it is already freed in the .remove function. 2024-03-01 not yet calculated CVE-2021-47070
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: uio_hv_generic: Fix a memory leak in error handling paths If ‘vmbus_establish_gpadl()’ fails, the (recv|send)_gpadl will not be updated and ‘hv_uio_cleanup()’ in the error handling path will not be able to free the corresponding buffer. In such a case, we need to free the buffer explicitly. 2024-03-01 not yet calculated CVE-2021-47071
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: btrfs: fix removed dentries still existing after log is synced When we move one inode from one directory to another and both the inode and its previous parent directory were logged before, we are not supposed to have the dentry for the old parent if we have a power failure after the log is synced. Only the new dentry is supposed to exist. Generally this works correctly, however there is a scenario where this is not currently working, because the old parent of the file/directory that was moved is not authoritative for a range that includes the dir index and dir item keys of the old dentry. This case is better explained with the following example and reproducer: # The test requires a very specific layout of keys and items in the # fs/subvolume btree to trigger the bug. So we want to make sure that # on whatever platform we are, we have the same leaf/node size. # # Currently in btrfs the node/leaf size can not be smaller than the page # size (but it can be greater than the page size). So use the largest # supported node/leaf size (64K). $ mkfs.btrfs -f -n 65536 /dev/sdc $ mount /dev/sdc /mnt # “testdir” is inode 257. $ mkdir /mnt/testdir $ chmod 755 /mnt/testdir # Create several empty files to have the directory “testdir” with its # items spread over several leaves (7 in this case). $ for ((i = 1; i <= 1200; i++)); do echo -n > /mnt/testdir/file$i done # Create our test directory “dira”, inode number 1458, which gets all # its items in leaf 7. # # The BTRFS_DIR_ITEM_KEY item for inode 257 (“testdir”) that points to # the entry named “dira” is in leaf 2, while the BTRFS_DIR_INDEX_KEY # item that points to that entry is in leaf 3. # # For this particular filesystem node size (64K), file count and file # names, we endup with the directory entry items from inode 257 in # leaves 2 and 3, as previously mentioned – what matters for triggering # the bug exercised by this test case is that those items are not placed # in leaf 1, they must be placed in a leaf different from the one # containing the inode item for inode 257. # # The corresponding BTRFS_DIR_ITEM_KEY and BTRFS_DIR_INDEX_KEY items for # the parent inode (257) are the following: # # item 460 key (257 DIR_ITEM 3724298081) itemoff 48344 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira # # and: # # item 771 key (257 DIR_INDEX 1202) itemoff 36673 itemsize 34 # location key (1458 INODE_ITEM 0) type DIR # transid 6 data_len 0 name_len 4 # name: dira $ mkdir /mnt/testdir/dira # Make sure everything done so far is durably persisted. $ sync # Now do a change to inode 257 (“testdir”) that does not result in # COWing leaves 2 and 3 – the leaves that contain the directory items # pointing to inode 1458 (directory “dira”). # # Changing permissions, the owner/group, updating or adding a xattr, # etc, will not change (COW) leaves 2 and 3. So for the sake of # simplicity change the permissions of inode 257, which results in # updating its inode item and therefore change (COW) only leaf 1. $ chmod 700 /mnt/testdir # Now fsync directory inode 257. # # Since only the first leaf was changed/COWed, we log the inode item of # inode 257 and only the dentries found in the first leaf, all have a # key type of BTRFS_DIR_ITEM_KEY, and no keys of type # BTRFS_DIR_INDEX_KEY, because they sort after the former type and none # exist in the first leaf. # # We also log 3 items that represent ranges for dir items and dir # indexes for which the log is authoritative: # # 1) a key of type BTRFS_DIR_LOG_ITEM_KEY, which indicates the log is # authoritative for all BTRFS_DIR_ITEM_KEY keys that have an offset # in the range [0, 2285968570] (the offset here is th —truncated— 2024-03-01 not yet calculated CVE-2021-47072
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: platform/x86: dell-smbios-wmi: Fix oops on rmmod dell_smbios init_dell_smbios_wmi() only registers the dell_smbios_wmi_driver on systems where the Dell WMI interface is supported. While exit_dell_smbios_wmi() unregisters it unconditionally, this leads to the following oops: [ 175.722921] ————[ cut here ]———— [ 175.722925] Unexpected driver unregister! [ 175.722939] WARNING: CPU: 1 PID: 3630 at drivers/base/driver.c:194 driver_unregister+0x38/0x40 … [ 175.723089] Call Trace: [ 175.723094] cleanup_module+0x5/0xedd [dell_smbios] … [ 175.723148] —[ end trace 064c34e1ad49509d ]— Make the unregister happen on the same condition the register happens to fix this. 2024-03-01 not yet calculated CVE-2021-47073
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nvme-loop: fix memory leak in nvme_loop_create_ctrl() When creating loop ctrl in nvme_loop_create_ctrl(), if nvme_init_ctrl() fails, the loop ctrl should be freed before jumping to the “out” label. 2024-03-01 not yet calculated CVE-2021-47074
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nvmet: fix memory leak in nvmet_alloc_ctrl() When creating ctrl in nvmet_alloc_ctrl(), if the cntlid_min is larger than cntlid_max of the subsystem, and jumps to the “out_free_changed_ns_list” label, but the ctrl->sqs lack of be freed. Fix this by jumping to the “out_free_sqs” label. 2024-03-01 not yet calculated CVE-2021-47075
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Return CQE error if invalid lkey was supplied RXE is missing update of WQE status in LOCAL_WRITE failures. This caused the following kernel panic if someone sent an atomic operation with an explicitly wrong lkey. [leonro@vm ~]$ mkt test test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) … WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Modules linked in: crc32_generic rdma_rxe ip6_udp_tunnel udp_tunnel rdma_ucm rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core mlx5_core ptp pps_core CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe] Code: 03 0f 8e 65 0e 00 00 3b 93 10 06 00 00 0f 84 82 0a 00 00 4c 89 ff 4c 89 44 24 38 e8 2d 74 a9 e1 4c 8b 44 24 38 e9 1c f5 ff ff <0f> 0b e9 0c e8 ff ff b8 05 00 00 00 41 bf 05 00 00 00 e9 ab e7 ff RSP: 0018:ffff8880158af090 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652 RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210 RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8 R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c FS: 00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0xb11/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_responder+0x5532/0x7620 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_rcv+0x9c8/0x1df0 [rdma_rxe] rxe_loopback+0x157/0x1e0 [rdma_rxe] rxe_requester+0x1efd/0x58c0 [rdma_rxe] rxe_do_task+0x130/0x230 [rdma_rxe] rxe_post_send+0x998/0x1860 [rdma_rxe] ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs] ib_uverbs_write+0x847/0xc80 [ib_uverbs] vfs_write+0x1c5/0x840 ksys_write+0x176/0x1d0 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae 2024-03-01 not yet calculated CVE-2021-47076
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: scsi: qedf: Add pointer checks in qedf_update_link_speed() The following trace was observed: [ 14.042059] Call Trace: [ 14.042061] <IRQ> [ 14.042068] qedf_link_update+0x144/0x1f0 [qedf] [ 14.042117] qed_link_update+0x5c/0x80 [qed] [ 14.042135] qed_mcp_handle_link_change+0x2d2/0x410 [qed] [ 14.042155] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042170] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042186] ? qed_rd+0x13/0x40 [qed] [ 14.042205] qed_mcp_handle_events+0x437/0x690 [qed] [ 14.042221] ? qed_set_ptt+0x70/0x80 [qed] [ 14.042239] qed_int_sp_dpc+0x3a6/0x3e0 [qed] [ 14.042245] tasklet_action_common.isra.14+0x5a/0x100 [ 14.042250] __do_softirq+0xe4/0x2f8 [ 14.042253] irq_exit+0xf7/0x100 [ 14.042255] do_IRQ+0x7f/0xd0 [ 14.042257] common_interrupt+0xf/0xf [ 14.042259] </IRQ> API qedf_link_update() is getting called from QED but by that time shost_data is not initialised. This results in a NULL pointer dereference when we try to dereference shost_data while updating supported_speeds. Add a NULL pointer check before dereferencing shost_data. 2024-03-01 not yet calculated CVE-2021-47077
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: RDMA/rxe: Clear all QP fields if creation failed rxe_qp_do_cleanup() relies on valid pointer values in QP for the properly created ones, but in case rxe_qp_from_init() failed it was filled with garbage and caused tot the following error. refcount_t: underflow; use-after-free. WARNING: CPU: 1 PID: 12560 at lib/refcount.c:28 refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Modules linked in: CPU: 1 PID: 12560 Comm: syz-executor.4 Not tainted 5.12.0-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:refcount_warn_saturate+0x1d1/0x1e0 lib/refcount.c:28 Code: e9 db fe ff ff 48 89 df e8 2c c2 ea fd e9 8a fe ff ff e8 72 6a a7 fd 48 c7 c7 e0 b2 c1 89 c6 05 dc 3a e6 09 01 e8 ee 74 fb 04 <0f> 0b e9 af fe ff ff 0f 1f 84 00 00 00 00 00 41 56 41 55 41 54 55 RSP: 0018:ffffc900097ceba8 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000040000 RSI: ffffffff815bb075 RDI: fffff520012f9d67 RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000000 R10: ffffffff815b4eae R11: 0000000000000000 R12: ffff8880322a4800 R13: ffff8880322a4940 R14: ffff888033044e00 R15: 0000000000000000 FS: 00007f6eb2be3700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fdbe5d41000 CR3: 000000001d181000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: __refcount_sub_and_test include/linux/refcount.h:283 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] kref_put include/linux/kref.h:64 [inline] rxe_qp_do_cleanup+0x96f/0xaf0 drivers/infiniband/sw/rxe/rxe_qp.c:805 execute_in_process_context+0x37/0x150 kernel/workqueue.c:3327 rxe_elem_release+0x9f/0x180 drivers/infiniband/sw/rxe/rxe_pool.c:391 kref_put include/linux/kref.h:65 [inline] rxe_create_qp+0x2cd/0x310 drivers/infiniband/sw/rxe/rxe_verbs.c:425 _ib_create_qp drivers/infiniband/core/core_priv.h:331 [inline] ib_create_named_qp+0x2ad/0x1370 drivers/infiniband/core/verbs.c:1231 ib_create_qp include/rdma/ib_verbs.h:3644 [inline] create_mad_qp+0x177/0x2d0 drivers/infiniband/core/mad.c:2920 ib_mad_port_open drivers/infiniband/core/mad.c:3001 [inline] ib_mad_init_device+0xd6f/0x1400 drivers/infiniband/core/mad.c:3092 add_client_context+0x405/0x5e0 drivers/infiniband/core/device.c:717 enable_device_and_get+0x1cd/0x3b0 drivers/infiniband/core/device.c:1331 ib_register_device drivers/infiniband/core/device.c:1413 [inline] ib_register_device+0x7c7/0xa50 drivers/infiniband/core/device.c:1365 rxe_register_device+0x3d5/0x4a0 drivers/infiniband/sw/rxe/rxe_verbs.c:1147 rxe_add+0x12fe/0x16d0 drivers/infiniband/sw/rxe/rxe.c:247 rxe_net_add+0x8c/0xe0 drivers/infiniband/sw/rxe/rxe_net.c:503 rxe_newlink drivers/infiniband/sw/rxe/rxe.c:269 [inline] rxe_newlink+0xb7/0xe0 drivers/infiniband/sw/rxe/rxe.c:250 nldev_newlink+0x30e/0x550 drivers/infiniband/core/nldev.c:1555 rdma_nl_rcv_msg+0x36d/0x690 drivers/infiniband/core/netlink.c:195 rdma_nl_rcv_skb drivers/infiniband/core/netlink.c:239 [inline] rdma_nl_rcv+0x2ee/0x430 drivers/infiniband/core/netlink.c:259 netlink_unicast_kernel net/netlink/af_netlink.c:1312 [inline] netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1338 netlink_sendmsg+0x856/0xd90 net/netlink/af_netlink.c:1927 sock_sendmsg_nosec net/socket.c:654 [inline] sock_sendmsg+0xcf/0x120 net/socket.c:674 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2350 ___sys_sendmsg+0xf3/0x170 net/socket.c:2404 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2433 do_syscall_64+0x3a/0xb0 arch/x86/entry/common.c:47 entry_SYSCALL_64_after_hwframe+0 —truncated— 2024-03-01 not yet calculated CVE-2021-47078
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: platform/x86: ideapad-laptop: fix a NULL pointer dereference The third parameter of dytc_cql_command should not be NULL since it will be dereferenced immediately. 2024-03-01 not yet calculated CVE-2021-47079
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: RDMA/core: Prevent divide-by-zero error triggered by the user The user_entry_size is supplied by the user and later used as a denominator to calculate number of entries. The zero supplied by the user will trigger the following divide-by-zero error: divide error: 0000 [#1] SMP KASAN PTI CPU: 4 PID: 497 Comm: c_repro Not tainted 5.13.0-rc1+ #281 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:ib_uverbs_handler_UVERBS_METHOD_QUERY_GID_TABLE+0x1b1/0x510 Code: 87 59 03 00 00 e8 9f ab 1e ff 48 8d bd a8 00 00 00 e8 d3 70 41 ff 44 0f b7 b5 a8 00 00 00 e8 86 ab 1e ff 31 d2 4c 89 f0 31 ff <49> f7 f5 48 89 d6 48 89 54 24 10 48 89 04 24 e8 1b ad 1e ff 48 8b RSP: 0018:ffff88810416f828 EFLAGS: 00010246 RAX: 0000000000000008 RBX: 1ffff1102082df09 RCX: ffffffff82183f3d RDX: 0000000000000000 RSI: ffff888105f2da00 RDI: 0000000000000000 RBP: ffff88810416fa98 R08: 0000000000000001 R09: ffffed102082df5f R10: ffff88810416faf7 R11: ffffed102082df5e R12: 0000000000000000 R13: 0000000000000000 R14: 0000000000000008 R15: ffff88810416faf0 FS: 00007f5715efa740(0000) GS:ffff88811a700000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000840 CR3: 000000010c2e0001 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ? ib_uverbs_handler_UVERBS_METHOD_INFO_HANDLES+0x4b0/0x4b0 ib_uverbs_cmd_verbs+0x1546/0x1940 ib_uverbs_ioctl+0x186/0x240 __x64_sys_ioctl+0x38a/0x1220 do_syscall_64+0x3f/0x80 entry_SYSCALL_64_after_hwframe+0x44/0xae 2024-03-01 not yet calculated CVE-2021-47080
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: habanalabs/gaudi: Fix a potential use after free in gaudi_memset_device_memory Our code analyzer reported a uaf. In gaudi_memset_device_memory, cb is get via hl_cb_kernel_create() with 2 refcount. If hl_cs_allocate_job() failed, the execution runs into release_cb branch. One ref of cb is dropped by hl_cb_put(cb) and could be freed if other thread also drops one ref. Then cb is used by cb->id later, which is a potential uaf. My patch add a variable ‘id’ to accept the value of cb->id before the hl_cb_put(cb) is called, to avoid the potential uaf. 2024-03-01 not yet calculated CVE-2021-47081
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 N/A — N/A
  An issue was discovered in RWS WorldServer before 11.7.3. An authenticated, remote attacker can perform a ws-legacy/load_dtd?system_id= blind SSRF attack to deploy JSP code to the Apache Axis service running on the localhost interface, leading to command execution. 2024-02-29 not yet calculated CVE-2022-34269
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered in RWS WorldServer before 11.7.3. Regular users can create users with the Administrator role via UserWSUserManager. 2024-02-29 not yet calculated CVE-2022-34270
cve@mitre.org
cve@mitre.org N/A — N/A
  Obsidian Mind Map v1.1.0 allows attackers to execute arbitrary code via a crafted payload injected into an uploaded document. 2024-02-29 not yet calculated CVE-2022-36677
cve@mitre.org
cve@mitre.org linux — linux
  In the Linux kernel, the following vulnerability has been resolved: moxart: fix potential use-after-free on remove path It was reported that the mmc host structure could be accessed after it was freed in moxart_remove(), so fix this by saving the base register of the device and using it instead of the pointer dereference. 2024-02-26 not yet calculated CVE-2022-48626
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: vt: fix memory overlapping when deleting chars in the buffer A memory overlapping copy occurs when deleting a long line. This memory overlapping copy can cause data corruption when scr_memcpyw is optimized to memcpy because memcpy does not ensure its behavior if the destination buffer overlaps with the source buffer. The line buffer is not always broken, because the memcpy utilizes the hardware acceleration, whose result is not deterministic. Fix this problem by using replacing the scr_memcpyw with scr_memmovew. 2024-03-02 not yet calculated CVE-2022-48627
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ceph: drop messages from MDS when unmounting When unmounting all the dirty buffers will be flushed and after the last osd request is finished the last reference of the i_count will be released. Then it will flush the dirty cap/snap to MDSs, and the unmounting won’t wait the possible acks, which will ihold the inodes when updating the metadata locally but makes no sense any more, of this. This will make the evict_inodes() to skip these inodes. If encrypt is enabled the kernel generate a warning when removing the encrypt keys when the skipped inodes still hold the keyring: WARNING: CPU: 4 PID: 168846 at fs/crypto/keyring.c:242 fscrypt_destroy_keyring+0x7e/0xd0 CPU: 4 PID: 168846 Comm: umount Tainted: G S 6.1.0-rc5-ceph-g72ead199864c #1 Hardware name: Supermicro SYS-5018R-WR/X10SRW-F, BIOS 2.0 12/17/2015 RIP: 0010:fscrypt_destroy_keyring+0x7e/0xd0 RSP: 0018:ffffc9000b277e28 EFLAGS: 00010202 RAX: 0000000000000002 RBX: ffff88810d52ac00 RCX: ffff88810b56aa00 RDX: 0000000080000000 RSI: ffffffff822f3a09 RDI: ffff888108f59000 RBP: ffff8881d394fb88 R08: 0000000000000028 R09: 0000000000000000 R10: 0000000000000001 R11: 11ff4fe6834fcd91 R12: ffff8881d394fc40 R13: ffff888108f59000 R14: ffff8881d394f800 R15: 0000000000000000 FS: 00007fd83f6f1080(0000) GS:ffff88885fd00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f918d417000 CR3: 000000017f89a005 CR4: 00000000003706e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <TASK> generic_shutdown_super+0x47/0x120 kill_anon_super+0x14/0x30 ceph_kill_sb+0x36/0x90 [ceph] deactivate_locked_super+0x29/0x60 cleanup_mnt+0xb8/0x140 task_work_run+0x67/0xb0 exit_to_user_mode_prepare+0x23d/0x240 syscall_exit_to_user_mode+0x25/0x60 do_syscall_64+0x40/0x80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fd83dc39e9b Later the kernel will crash when iput() the inodes and dereferencing the “sb->s_master_keys”, which has been released by the generic_shutdown_super(). 2024-03-02 not yet calculated CVE-2022-48628
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 N/A — N/A
  openCRX 5.2.0 was discovered to contain an HTML injection vulnerability for Search Criteria-Activity Number (in the Saved Search Activity) via the Name, Description, or Activity Number field. 2024-02-29 not yet calculated CVE-2023-27151
cve@mitre.org
cve@mitre.org N/A — N/A
  In Stormshield Network Security (SNS) 1.0.0 through 3.7.36 before 3.7.37, 3.8.0 through 3.11.24 before 3.11.25, 4.0.0 through 4.3.18 before 4.3.19, 4.4.0 through 4.6.5 before 4.6.6, and 4.7.0 before 4.7.1, the usage of a Network object created from an inactive DHCP interface in the filtering slot results in the usage of an object of the :any” type, which may have unexpected results for access control. 2024-02-29 not yet calculated CVE-2023-34198
cve@mitre.org N/A — N/A
  Cross Site Request Forgery vulnerability in Bagisto before v.1.5.1 allows an attacker to execute arbitrary code via a crafted HTML script. 2024-02-26 not yet calculated CVE-2023-36237
cve@mitre.org N/A — N/A
  An issue was discovered in Stormshield Network Security (SNS) 3.7.0 through 3.7.38 before 3.7.39, 3.10.0 through 3.11.26 before 3.11.27, 4.0 through 4.3.21 before 4.3.22, and 4.4.0 through 4.6.8 before 4.6.9. An administrator with write access to the SNS firewall can configure a login disclaimer with malicious JavaScript elements that can result in data theft. 2024-02-29 not yet calculated CVE-2023-41165
cve@mitre.org N/A — N/A
  An arbitrary file upload vulnerability in the Update/Edit Student’s Profile Picture function of Student Enrollment In PHP v1.0 allows attackers to execute arbitrary code via uploading a crafted PHP file. 2024-02-27 not yet calculated CVE-2023-41506
cve@mitre.org N/A — N/A
  An issue was discovered in Couchbase Server through 7.1.4 before 7.1.5 and before 7.2.1. There are Unauthenticated RMI Service Ports Exposed in Analytics. 2024-02-29 not yet calculated CVE-2023-43769
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  In Hazelcast through 4.1.10, 4.2 through 4.2.8, 5.0 through 5.0.5, 5.1 through 5.1.7, 5.2 through 5.2.4, and 5.3 through 5.3.2, some client operations don’t check permissions properly, allowing authenticated users to access data stored in the cluster. 2024-02-28 not yet calculated CVE-2023-45859
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered in Couchbase Server through 7.2.2. A data reader may cause a denial of service (application exist) because of the OOM killer. 2024-02-28 not yet calculated CVE-2023-45873
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered in Couchbase Server through 7.2.2. A data reader may cause a denial of service (outage of reader threads). 2024-02-29 not yet calculated CVE-2023-45874
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in Contribsys Sidekiq v.6.5.8 allows a remote attacker to obtain sensitive information via a crafted URL to the filter functions. 2024-03-01 not yet calculated CVE-2023-46950
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in Contribsys Sidekiq v.6.5.8 allows a remote attacker to obtain sensitive information via a crafted payload to the uniquejobs function. 2024-03-01 not yet calculated CVE-2023-46951
cve@mitre.org
cve@mitre.org
cve@mitre.org unknown — socialdriver
  The SocialDriver WordPress theme before version 2024 has a prototype pollution vulnerability that could allow an attacker to inject arbitrary properties resulting in a cross-site scripting (XSS) attack. 2024-02-23 not yet calculated CVE-2023-4826
contact@wpscan.com
contact@wpscan.com N/A — N/A
  Concrete CMS before 8.5.14 and 9 before 9.2.3 is vulnerable to an admin adding a stored XSS payload via the Layout Preset name. 2024-02-29 not yet calculated CVE-2023-48650
cve@mitre.org
cve@mitre.org N/A — N/A
  Concrete CMS 9 before 9.2.3 is vulnerable to Cross Site Request Forgery (CSRF) at /ccm/system/dialogs/file/delete/1/submit. 2024-02-29 not yet calculated CVE-2023-48651
cve@mitre.org
cve@mitre.org N/A — N/A
  Concrete CMS before 8.5.14 and 9 before 9.2.3 allows Cross Site Request Forgery (CSRF) via ccm/calendar/dialogs/event/delete/submit. An attacker can force an admin to delete events on the site because the event ID is numeric and sequential. 2024-02-29 not yet calculated CVE-2023-48653
cve@mitre.org
cve@mitre.org acronis — acronis_cyber_protect_16
  Sensitive information disclosure due to insecure folder permissions. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 37391. 2024-02-27 not yet calculated CVE-2023-48678
security@acronis.com acronis — acronis_cyber_protect_16
  Stored cross-site scripting (XSS) vulnerability due to missing origin validation in postMessage. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 37391. 2024-02-27 not yet calculated CVE-2023-48679
security@acronis.com acronis — acronis_cyber_protect_16
  Sensitive information disclosure due to excessive collection of system information. The following products are affected: Acronis Cyber Protect 16 (macOS, Windows) before build 37391. 2024-02-27 not yet calculated CVE-2023-48680
security@acronis.com acronis — acronis_cyber_protect_16
  Self cross-site scripting (XSS) vulnerability in storage nodes search field. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 37391. 2024-02-27 not yet calculated CVE-2023-48681
security@acronis.com acronis — acronis_cyber_protect_16
  Stored cross-site scripting (XSS) vulnerability in unit name. The following products are affected: Acronis Cyber Protect 16 (Linux, Windows) before build 37391. 2024-02-27 not yet calculated CVE-2023-48682
security@acronis.com qognify — vms_client_viewer A DLL hijacking vulnerability was identified in the Qognify VMS Client Viewer version 7.1 or higher, which allows local users to execute arbitrary code and obtain higher privileges via careful placement of a malicious DLL, if some specific pre-conditions are met. 2024-02-26 not yet calculated CVE-2023-49114
551230f0-3615-47bd-b7cc-93e92e730bbf
551230f0-3615-47bd-b7cc-93e92e730bbf N/A — N/A
  Couchbase Server 7.1.x and 7.2.x before 7.2.4 does not require authentication for the /admin/stats and /admin/vitals endpoints on TCP port 8093 of localhost. 2024-02-28 not yet calculated CVE-2023-49338
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  Book Store Management System v1.0 was discovered to contain a cross-site scripting (XSS) vulnerability in /bsms_ci/index.php/category. This vulnerability allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the category parameter. 2024-03-01 not yet calculated CVE-2023-49539
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  Book Store Management System v1.0 was discovered to contain a cross-site scripting (XSS) vulnerability in /bsms_ci/index.php/history. This vulnerability allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the history parameter. 2024-03-01 not yet calculated CVE-2023-49540
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  Incorrect access control in Book Store Management System v1 allows attackers to access unauthorized pages and execute administrative functions without authenticating. 2024-03-01 not yet calculated CVE-2023-49543
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  A local file inclusion (LFI) in Customer Support System v1 allows attackers to include internal PHP files and gain unauthorized acces via manipulation of the page= parameter at /customer_support/index.php. 2024-03-01 not yet calculated CVE-2023-49544
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  A directory listing vulnerability in Customer Support System v1 allows attackers to list directories and sensitive files within the application without requiring authorization. 2024-03-01 not yet calculated CVE-2023-49545
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered in Couchbase Server before 7.2.4. cURL calls to /diag/eval are not sufficiently restricted. 2024-02-29 not yet calculated CVE-2023-49930
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered in Couchbase Server before 7.2.4. SQL++ cURL calls to /diag/eval are not sufficiently restricted. 2024-02-29 not yet calculated CVE-2023-49931
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered in Couchbase Server before 7.2.4. An attacker can bypass SQL++ N1QL cURL host restrictions. 2024-02-29 not yet calculated CVE-2023-49932
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  In Indo-Sol PROFINET-INspektor NT through 2.4.0, a command injection vulnerability in the gedtupdater service of the firmware allows remote attackers to execute arbitrary system commands with root privileges via a crafted filename parameter in POST requests to the /api/updater/ctrl/start_update endpoint. 2024-02-26 not yet calculated CVE-2023-49959
cve@mitre.org
cve@mitre.org N/A — N/A
  In Indo-Sol PROFINET-INspektor NT through 2.4.0, a path traversal vulnerability in the httpuploadd service of the firmware allows remote attackers to write to arbitrary files via a crafted filename parameter in requests to the /upload endpoint. 2024-02-26 not yet calculated CVE-2023-49960
cve@mitre.org
cve@mitre.org N/A — N/A
  Lack of proper input validation and constraint enforcement in Apache Ambari prior to 2.7.8    Impact : As it will be stored XSS, Could be exploited to perform unauthorized actions, varying from data access to session hijacking and delivering malicious payloads. Users are recommended to upgrade to version 2.7.8 which fixes this issue. 2024-03-01 not yet calculated CVE-2023-50378
security@apache.org apache_software_foundation — apache_ambari
  Malicious code injection in Apache Ambari in prior to 2.7.8. Users are recommended to upgrade to version 2.7.8, which fixes this issue. Impact: A Cluster Operator can manipulate the request by adding a malicious code injection and gain a root over the cluster main host. 2024-02-27 not yet calculated CVE-2023-50379
security@apache.org
security@apache.org apache_software_foundation — apache_ambari
  XML External Entity injection in apache ambari versions <= 2.7.7, Users are recommended to upgrade to version 2.7.8, which fixes this issue. More Details: Oozie Workflow Scheduler had a vulnerability that allowed for root-level file reading and privilege escalation from low-privilege users. The vulnerability was caused through lack of proper user input validation. This vulnerability is known as an XML External Entity (XXE) injection attack. Attackers can exploit XXE vulnerabilities to read arbitrary files on the server, including sensitive system files. In theory, it might be possible to use this to escalate privileges. 2024-02-27 not yet calculated CVE-2023-50380
security@apache.org
security@apache.org N/A — N/A
  An issue was discovered in Couchbase Server before 7.2.4. ns_server admin credentials are leaked in encoded form in the diag.log file. The earliest affected version is 7.1.5. 2024-02-29 not yet calculated CVE-2023-50436
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered in Couchbase Server before 7.2.x before 7.2.4. otpCookie is shown with full admin on pools/default/serverGroups and engageCluster2. 2024-02-29 not yet calculated CVE-2023-50437
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  The jose2go component before 1.6.0 for Go allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value. 2024-02-29 not yet calculated CVE-2023-50658
cve@mitre.org
cve@mitre.org apache_software_foundation — apache_james_server
  Apache James prior to version 3.7.5 and 3.8.0 exposes a JMX endpoint on localhost subject to pre-authentication deserialisation of untrusted data. Given a deserialisation gadjet, this could be leveraged as part of an exploit chain that could result in privilege escalation. Note that by default JMX endpoint is only bound locally. We recommend users to:  – Upgrade to a non-vulnerable Apache James version  – Run Apache James isolated from other processes (docker – dedicated virtual machine)  – If possible turn off JMX 2024-02-27 not yet calculated CVE-2023-51518
security@apache.org apache_software_foundation — apache_james_server
  Apache James prior to versions 3.8.1 and 3.7.5 is vulnerable to SMTP smuggling. A lenient behaviour in line delimiter handling might create a difference of interpretation between the sender and the receiver which can be exploited by an attacker to forge an SMTP envelop, allowing for instance to bypass SPF checks. The patch implies enforcement of CRLF as a line delimiter as part of the DATA transaction. We recommend James users to upgrade to non vulnerable versions. 2024-02-27 not yet calculated CVE-2023-51747
security@apache.org
security@apache.org
security@apache.org
security@apache.org N/A — N/A
  BACnet Stack before 1.3.2 has a decode function APDU buffer over-read in bacapp_decode_application_data in bacapp.c. 2024-02-29 not yet calculated CVE-2023-51773
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  The json-jwt (aka JSON::JWT) gem 1.16.3 for Ruby sometimes allows bypass of identity checks via a sign/encryption confusion attack. For example, JWE can sometimes be used to bypass JSON::JWT.decode. 2024-02-29 not yet calculated CVE-2023-51774
cve@mitre.org N/A — N/A
  The jose4j component before 0.9.4 for Java allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value. 2024-02-29 not yet calculated CVE-2023-51775
cve@mitre.org N/A — N/A
  bt_sock_recvmsg in net/bluetooth/af_bluetooth.c in the Linux kernel through 6.6.8 has a use-after-free because of a bt_sock_ioctl race condition. 2024-02-29 not yet calculated CVE-2023-51779
cve@mitre.org N/A — N/A
  Cross Site Scripting (XSS) vulnerability in School Fees Management System v.1.0 allows a remote attacker to execute arbitrary code via a crafted payload to the main_settings component in the phone, address, bank, acc_name, acc_number parameters, new_class and cname parameter, add_new_parent function in the name email parameters, new_term function in the tname parameter, and the edit_student function in the name parameter. 2024-02-29 not yet calculated CVE-2023-51800
cve@mitre.org N/A — N/A
  SQL Injection vulnerability in the Simple Student Attendance System v.1.0 allows a remote attacker to execute arbitrary code via a crafted payload to the id parameter in the student_form.php and the class_form.php pages. 2024-02-29 not yet calculated CVE-2023-51801
cve@mitre.org N/A — N/A
  Cross Site Scripting (XSS) vulnerability in the Simple Student Attendance System v.1.0 allows a remote attacker to execute arbitrary code via a crafted payload to the page or class_month parameter in the /php-attendance/attendance_report component. 2024-02-29 not yet calculated CVE-2023-51802
cve@mitre.org N/A — N/A
  An issue in TRENDnet TEW-822DRE v.1.03B02 allows a local attacker to execute arbitrary code via the parameters ipv4_ping in the /boafrm/formSystemCheck. 2024-02-29 not yet calculated CVE-2023-51835
cve@mitre.org
cve@mitre.org N/A — N/A
  Dedecms v5.7.112 was discovered to contain a Cross-Site Request Forgery (CSRF) in the file manager. 2024-02-28 not yet calculated CVE-2023-52047
cve@mitre.org N/A — N/A
  RuoYi v4.7.8 was discovered to contain a cross-site scripting (XSS) vulnerability via the component /system/notice/. 2024-02-28 not yet calculated CVE-2023-52048
cve@mitre.org linux — linux
  In the Linux kernel, the following vulnerability has been resolved: hisi_acc_vfio_pci: Update migration data pointer correctly on saving/resume When the optional PRE_COPY support was added to speed up the device compatibility check, it failed to update the saving/resuming data pointers based on the fd offset. This results in migration data corruption and when the device gets started on the destination the following error is reported in some cases, [ 478.907684] arm-smmu-v3 arm-smmu-v3.2.auto: event 0x10 received: [ 478.913691] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000310200000010 [ 478.919603] arm-smmu-v3 arm-smmu-v3.2.auto: 0x000002088000007f [ 478.925515] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 [ 478.931425] arm-smmu-v3 arm-smmu-v3.2.auto: 0x0000000000000000 [ 478.947552] hisi_zip 0000:31:00.0: qm_axi_rresp [error status=0x1] found [ 478.955930] hisi_zip 0000:31:00.0: qm_db_timeout [error status=0x400] found [ 478.955944] hisi_zip 0000:31:00.0: qm sq doorbell timeout in function 2 2024-02-23 not yet calculated CVE-2023-52453
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length If the host sends an H2CData command with an invalid DATAL, the kernel may crash in nvmet_tcp_build_pdu_iovec(). Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp] Call trace: process_one_work+0x174/0x3c8 worker_thread+0x2d0/0x3e8 kthread+0x104/0x110 Fix the bug by raising a fatal error if DATAL isn’t coherent with the packet size. Also, the PDU length should never exceed the MAXH2CDATA parameter which has been communicated to the host in nvmet_tcp_handle_icreq(). 2024-02-23 not yet calculated CVE-2023-52454
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: iommu: Don’t reserve 0-length IOVA region When the bootloader/firmware doesn’t setup the framebuffers, their address and size are 0 in “iommu-addresses” property. If IOVA region is reserved with 0 length, then it ends up corrupting the IOVA rbtree with an entry which has pfn_hi < pfn_lo. If we intend to use display driver in kernel without framebuffer then it’s causing the display IOMMU mappings to fail as entire valid IOVA space is reserved when address and length are passed as 0. An ideal solution would be firmware removing the “iommu-addresses” property and corresponding “memory-region” if display is not present. But the kernel should be able to handle this by checking for size of IOVA region and skipping the IOVA reservation if size is 0. Also, add a warning if firmware is requesting 0-length IOVA region reservation. 2024-02-23 not yet calculated CVE-2023-52455
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: serial: imx: fix tx statemachine deadlock When using the serial port as RS485 port, the tx statemachine is used to control the RTS pin to drive the RS485 transceiver TX_EN pin. When the TTY port is closed in the middle of a transmission (for instance during userland application crash), imx_uart_shutdown disables the interface and disables the Transmission Complete interrupt. afer that, imx_uart_stop_tx bails on an incomplete transmission, to be retriggered by the TC interrupt. This interrupt is disabled and therefore the tx statemachine never transitions out of SEND. The statemachine is in deadlock now, and the TX_EN remains low, making the interface useless. imx_uart_stop_tx now checks for incomplete transmission AND whether TC interrupts are enabled before bailing to be retriggered. This makes sure the state machine handling is reached, and is properly set to WAIT_AFTER_SEND. 2024-02-23 not yet calculated CVE-2023-52456
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: serial: 8250: omap: Don’t skip resource freeing if pm_runtime_resume_and_get() failed Returning an error code from .remove() makes the driver core emit the little helpful error message: remove callback returned a non-zero value. This will be ignored. and then remove the device anyhow. So all resources that were not freed are leaked in this case. Skipping serial8250_unregister_port() has the potential to keep enough of the UART around to trigger a use-after-free. So replace the error return (and with it the little helpful error message) by a more useful error message and continue to cleanup. 2024-02-23 not yet calculated CVE-2023-52457
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: block: add check that partition length needs to be aligned with block size Before calling add partition or resize partition, there is no check on whether the length is aligned with the logical block size. If the logical block size of the disk is larger than 512 bytes, then the partition size maybe not the multiple of the logical block size, and when the last sector is read, bio_truncate() will adjust the bio size, resulting in an IO error if the size of the read command is smaller than the logical block size.If integrity data is supported, this will also result in a null pointer dereference when calling bio_integrity_free. 2024-02-23 not yet calculated CVE-2023-52458
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: media: v4l: async: Fix duplicated list deletion The list deletion call dropped here is already called from the helper function in the line before. Having a second list_del() call results in either a warning (with CONFIG_DEBUG_LIST=y): list_del corruption, c46c8198->next is LIST_POISON1 (00000100) If CONFIG_DEBUG_LIST is disabled the operation results in a kernel error due to NULL pointer dereference. 2024-02-23 not yet calculated CVE-2023-52459
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Fix NULL pointer dereference at hibernate During hibernate sequence the source context might not have a clk_mgr. So don’t use it to look for DML2 support. 2024-02-23 not yet calculated CVE-2023-52460
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm/sched: Fix bounds limiting when given a malformed entity If we’re given a malformed entity in drm_sched_entity_init()–shouldn’t happen, but we verify–with out-of-bounds priority value, we set it to an allowed value. Fix the expression which sets this limit. 2024-02-23 not yet calculated CVE-2023-52461
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: bpf: fix check for attempt to corrupt spilled pointer When register is spilled onto a stack as a 1/2/4-byte register, we set slot_type[BPF_REG_SIZE – 1] (plus potentially few more below it, depending on actual spill size). So to check if some stack slot has spilled register we need to consult slot_type[7], not slot_type[0]. To avoid the need to remember and double-check this in the future, just use is_spilled_reg() helper. 2024-02-23 not yet calculated CVE-2023-52462
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: efivarfs: force RO when remounting if SetVariable is not supported If SetVariable at runtime is not supported by the firmware we never assign a callback for that function. At the same time mount the efivarfs as RO so no one can call that. However, we never check the permission flags when someone remounts the filesystem as RW. As a result this leads to a crash looking like this: $ mount -o remount,rw /sys/firmware/efi/efivars $ efi-updatevar -f PK.auth PK [ 303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 303.280482] Mem abort info: [ 303.280854] ESR = 0x0000000086000004 [ 303.281338] EC = 0x21: IABT (current EL), IL = 32 bits [ 303.282016] SET = 0, FnV = 0 [ 303.282414] EA = 0, S1PTW = 0 [ 303.282821] FSC = 0x04: level 0 translation fault [ 303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000 [ 303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000 [ 303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP [ 303.286936] Modules linked in: qrtr tpm_tis tpm_tis_core crct10dif_ce arm_smccc_trng rng_core drm fuse ip_tables x_tables ipv6 [ 303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1 [ 303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023 [ 303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=–) [ 303.292123] pc : 0x0 [ 303.292443] lr : efivar_set_variable_locked+0x74/0xec [ 303.293156] sp : ffff800008673c10 [ 303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000 [ 303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027 [ 303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000 [ 303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000 [ 303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54 [ 303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4 [ 303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002 [ 303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201 [ 303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc [ 303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000 [ 303.303341] Call trace: [ 303.303679] 0x0 [ 303.303938] efivar_entry_set_get_size+0x98/0x16c [ 303.304585] efivarfs_file_write+0xd0/0x1a4 [ 303.305148] vfs_write+0xc4/0x2e4 [ 303.305601] ksys_write+0x70/0x104 [ 303.306073] __arm64_sys_write+0x1c/0x28 [ 303.306622] invoke_syscall+0x48/0x114 [ 303.307156] el0_svc_common.constprop.0+0x44/0xec [ 303.307803] do_el0_svc+0x38/0x98 [ 303.308268] el0_svc+0x2c/0x84 [ 303.308702] el0t_64_sync_handler+0xf4/0x120 [ 303.309293] el0t_64_sync+0x190/0x194 [ 303.309794] Code: ???????? ???????? ???????? ???????? (????????) [ 303.310612] —[ end trace 0000000000000000 ]— Fix this by adding a .reconfigure() function to the fs operations which we can use to check the requested flags and deny anything that’s not RO if the firmware doesn’t implement SetVariable at runtime. 2024-02-23 not yet calculated CVE-2023-52463
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: EDAC/thunderx: Fix possible out-of-bounds string access Enabling -Wstringop-overflow globally exposes a warning for a common bug in the usage of strncat(): drivers/edac/thunderx_edac.c: In function ‘thunderx_ocx_com_threaded_isr’: drivers/edac/thunderx_edac.c:1136:17: error: ‘strncat’ specified bound 1024 equals destination size [-Werror=stringop-overflow=] 1136 | strncat(msg, other, OCX_MESSAGE_SIZE); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ … 1145 | strncat(msg, other, OCX_MESSAGE_SIZE); … 1150 | strncat(msg, other, OCX_MESSAGE_SIZE); … Apparently the author of this driver expected strncat() to behave the way that strlcat() does, which uses the size of the destination buffer as its third argument rather than the length of the source buffer. The result is that there is no check on the size of the allocated buffer. Change it to strlcat(). [ bp: Trim compiler output, fixup commit message. ] 2024-02-23 not yet calculated CVE-2023-52464
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: power: supply: Fix null pointer dereference in smb2_probe devm_kasprintf and devm_kzalloc return a pointer to dynamically allocated memory which can be NULL upon failure. 2024-02-26 not yet calculated CVE-2023-52465
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mfd: syscon: Fix null pointer dereference in of_syscon_register() kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. 2024-02-26 not yet calculated CVE-2023-52467
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: class: fix use-after-free in class_register() The lock_class_key is still registered and can be found in lock_keys_hash hlist after subsys_private is freed in error handler path.A task who iterate over the lock_keys_hash later may cause use-after-free.So fix that up and unregister the lock_class_key before kfree(cp). On our platform, a driver fails to kset_register because of creating duplicate filename ‘/class/xxx’.With Kasan enabled, it prints a invalid-access bug report. KASAN bug report: BUG: KASAN: invalid-access in lockdep_register_key+0x19c/0x1bc Write of size 8 at addr 15ffff808b8c0368 by task modprobe/252 Pointer tag: [15], memory tag: [fe] CPU: 7 PID: 252 Comm: modprobe Tainted: G W 6.6.0-mainline-maybe-dirty #1 Call trace: dump_backtrace+0x1b0/0x1e4 show_stack+0x2c/0x40 dump_stack_lvl+0xac/0xe0 print_report+0x18c/0x4d8 kasan_report+0xe8/0x148 __hwasan_store8_noabort+0x88/0x98 lockdep_register_key+0x19c/0x1bc class_register+0x94/0x1ec init_module+0xbc/0xf48 [rfkill] do_one_initcall+0x17c/0x72c do_init_module+0x19c/0x3f8 … Memory state around the buggy address: ffffff808b8c0100: 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a 8a ffffff808b8c0200: 8a 8a 8a 8a 8a 8a 8a 8a fe fe fe fe fe fe fe fe >ffffff808b8c0300: fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe fe ^ ffffff808b8c0400: 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 03 As CONFIG_KASAN_GENERIC is not set, Kasan reports invalid-access not use-after-free here.In this case, modprobe is manipulating the corrupted lock_keys_hash hlish where lock_class_key is already freed before. It’s worth noting that this only can happen if lockdep is enabled, which is not true for normal system. 2024-02-26 not yet calculated CVE-2023-52468
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drivers/amd/pm: fix a use-after-free in kv_parse_power_table When ps allocated by kzalloc equals to NULL, kv_parse_power_table frees adev->pm.dpm.ps that allocated before. However, after the control flow goes through the following call chains: kv_parse_power_table |-> kv_dpm_init |-> kv_dpm_sw_init |-> kv_dpm_fini The adev->pm.dpm.ps is used in the for loop of kv_dpm_fini after its first free in kv_parse_power_table and causes a use-after-free bug. 2024-02-26 not yet calculated CVE-2023-52469
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm/radeon: check the alloc_workqueue return value in radeon_crtc_init() check the alloc_workqueue return value in radeon_crtc_init() to avoid null-ptr-deref. 2024-02-26 not yet calculated CVE-2023-52470
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ice: Fix some null pointer dereference issues in ice_ptp.c devm_kasprintf() returns a pointer to dynamically allocated memory which can be NULL upon failure. 2024-02-26 not yet calculated CVE-2023-52471
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: crypto: rsa – add a check for allocation failure Static checkers insist that the mpi_alloc() allocation can fail so add a check to prevent a NULL dereference. Small allocations like this can’t actually fail in current kernels, but adding a check is very simple and makes the static checkers happy. 2024-02-26 not yet calculated CVE-2023-52472
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: thermal: core: Fix NULL pointer dereference in zone registration error path If device_register() in thermal_zone_device_register_with_trips() returns an error, the tz variable is set to NULL and subsequently dereferenced in kfree(tz->tzp). Commit adc8749b150c (“thermal/drivers/core: Use put_device() if device_register() fails”) added the tz = NULL assignment in question to avoid a possible double-free after dropping the reference to the zone device. However, after commit 4649620d9404 (“thermal: core: Make thermal_zone_device_unregister() return after freeing the zone”), that assignment has become redundant, because dropping the reference to the zone device does not cause the zone object to be freed any more. Drop it to address the NULL pointer dereference. 2024-02-26 not yet calculated CVE-2023-52473
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: IB/hfi1: Fix bugs with non-PAGE_SIZE-end multi-iovec user SDMA requests hfi1 user SDMA request processing has two bugs that can cause data corruption for user SDMA requests that have multiple payload iovecs where an iovec other than the tail iovec does not run up to the page boundary for the buffer pointed to by that iovec.a Here are the specific bugs: 1. user_sdma_txadd() does not use struct user_sdma_iovec->iov.iov_len. Rather, user_sdma_txadd() will add up to PAGE_SIZE bytes from iovec to the packet, even if some of those bytes are past iovec->iov.iov_len and are thus not intended to be in the packet. 2. user_sdma_txadd() and user_sdma_send_pkts() fail to advance to the next iovec in user_sdma_request->iovs when the current iovec is not PAGE_SIZE and does not contain enough data to complete the packet. The transmitted packet will contain the wrong data from the iovec pages. This has not been an issue with SDMA packets from hfi1 Verbs or PSM2 because they only produce iovecs that end short of PAGE_SIZE as the tail iovec of an SDMA request. Fixing these bugs exposes other bugs with the SDMA pin cache (struct mmu_rb_handler) that get in way of supporting user SDMA requests with multiple payload iovecs whose buffers do not end at PAGE_SIZE. So this commit fixes those issues as well. Here are the mmu_rb_handler bugs that non-PAGE_SIZE-end multi-iovec payload user SDMA requests can hit: 1. Overlapping memory ranges in mmu_rb_handler will result in duplicate pinnings. 2. When extending an existing mmu_rb_handler entry (struct mmu_rb_node), the mmu_rb code (1) removes the existing entry under a lock, (2) releases that lock, pins the new pages, (3) then reacquires the lock to insert the extended mmu_rb_node. If someone else comes in and inserts an overlapping entry between (2) and (3), insert in (3) will fail. The failure path code in this case unpins _all_ pages in either the original mmu_rb_node or the new mmu_rb_node that was inserted between (2) and (3). 3. In hfi1_mmu_rb_remove_unless_exact(), mmu_rb_node->refcount is incremented outside of mmu_rb_handler->lock. As a result, mmu_rb_node could be evicted by another thread that gets mmu_rb_handler->lock and checks mmu_rb_node->refcount before mmu_rb_node->refcount is incremented. 4. Related to #2 above, SDMA request submission failure path does not check mmu_rb_node->refcount before freeing mmu_rb_node object. If there are other SDMA requests in progress whose iovecs have pointers to the now-freed mmu_rb_node(s), those pointers to the now-freed mmu_rb nodes will be dereferenced when those SDMA requests complete. 2024-02-26 not yet calculated CVE-2023-52474
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: Input: powermate – fix use-after-free in powermate_config_complete syzbot has found a use-after-free bug [1] in the powermate driver. This happens when the device is disconnected, which leads to a memory free from the powermate_device struct. When an asynchronous control message completes after the kfree and its callback is invoked, the lock does not exist anymore and hence the bug. Use usb_kill_urb() on pm->config to cancel any in-progress requests upon device disconnection. [1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e 2024-02-29 not yet calculated CVE-2023-52475
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: perf/x86/lbr: Filter vsyscall addresses We found that a panic can occur when a vsyscall is made while LBR sampling is active. If the vsyscall is interrupted (NMI) for perf sampling, this call sequence can occur (most recent at top): __insn_get_emulate_prefix() insn_get_emulate_prefix() insn_get_prefixes() insn_get_opcode() decode_branch_type() get_branch_type() intel_pmu_lbr_filter() intel_pmu_handle_irq() perf_event_nmi_handler() Within __insn_get_emulate_prefix() at frame 0, a macro is called: peek_nbyte_next(insn_byte_t, insn, i) Within this macro, this dereference occurs: (insn)->next_byte Inspecting registers at this point, the value of the next_byte field is the address of the vsyscall made, for example the location of the vsyscall version of gettimeofday() at 0xffffffffff600000. The access to an address in the vsyscall region will trigger an oops due to an unhandled page fault. To fix the bug, filtering for vsyscalls can be done when determining the branch type. This patch will return a “none” branch if a kernel address if found to lie in the vsyscall region. 2024-02-29 not yet calculated CVE-2023-52476
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: usb: hub: Guard against accesses to uninitialized BOS descriptors Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h access fields inside udev->bos without checking if it was allocated and initialized. If usb_get_bos_descriptor() fails for whatever reason, udev->bos will be NULL and those accesses will result in a crash: BUG: kernel NULL pointer dereference, address: 0000000000000018 PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP NOPTI CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 <HASH:1f9e 1> Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021 Workqueue: usb_hub_wq hub_event RIP: 0010:hub_port_reset+0x193/0x788 Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 <48> 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9 RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310 RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840 RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060 R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000 R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000 FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0 Call Trace: hub_event+0x73f/0x156e ? hub_activate+0x5b7/0x68f process_one_work+0x1a2/0x487 worker_thread+0x11a/0x288 kthread+0x13a/0x152 ? process_one_work+0x487/0x487 ? kthread_associate_blkcg+0x70/0x70 ret_from_fork+0x1f/0x30 Fall back to a default behavior if the BOS descriptor isn’t accessible and skip all the functionalities that depend on it: LPM support checks, Super Speed capabilitiy checks, U1/U2 states setup. 2024-02-29 not yet calculated CVE-2023-52477
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: HID: logitech-hidpp: Fix kernel crash on receiver USB disconnect hidpp_connect_event() has *four* time-of-check vs time-of-use (TOCTOU) races when it races with itself. hidpp_connect_event() primarily runs from a workqueue but it also runs on probe() and if a “device-connected” packet is received by the hw when the thread running hidpp_connect_event() from probe() is waiting on the hw, then a second thread running hidpp_connect_event() will be started from the workqueue. This opens the following races (note the below code is simplified): 1. Retrieving + printing the protocol (harmless race): if (!hidpp->protocol_major) { hidpp_root_get_protocol_version() hidpp->protocol_major = response.rap.params[0]; } We can actually see this race hit in the dmesg in the abrt output attached to rhbz#2227968: [ 3064.624215] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. [ 3064.658184] logitech-hidpp-device 0003:046D:4071.0049: HID++ 4.5 device connected. Testing with extra logging added has shown that after this the 2 threads take turn grabbing the hw access mutex (send_mutex) so they ping-pong through all the other TOCTOU cases managing to hit all of them: 2. Updating the name to the HIDPP name (harmless race): if (hidpp->name == hdev->name) { … hidpp->name = new_name; } 3. Initializing the power_supply class for the battery (problematic!): hidpp_initialize_battery() { if (hidpp->battery.ps) return 0; probe_battery(); /* Blocks, threads take turns executing this */ hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); } 4. Creating delayed input_device (potentially problematic): if (hidpp->delayed_input) return; hidpp->delayed_input = hidpp_allocate_input(hdev); The really big problem here is 3. Hitting the race leads to the following sequence: hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); … hidpp->battery.desc.properties = devm_kmemdup(dev, hidpp_battery_props, cnt, GFP_KERNEL); hidpp->battery.ps = devm_power_supply_register(&hidpp->hid_dev->dev, &hidpp->battery.desc, cfg); So now we have registered 2 power supplies for the same battery, which looks a bit weird from userspace’s pov but this is not even the really big problem. Notice how: 1. This is all devm-maganaged 2. The hidpp->battery.desc struct is shared between the 2 power supplies 3. hidpp->battery.desc.properties points to the result from the second devm_kmemdup() This causes a use after free scenario on USB disconnect of the receiver: 1. The last registered power supply class device gets unregistered 2. The memory from the last devm_kmemdup() call gets freed, hidpp->battery.desc.properties now points to freed memory 3. The first registered power supply class device gets unregistered, this involves sending a remove uevent to userspace which invokes power_supply_uevent() to fill the uevent data 4. power_supply_uevent() uses hidpp->battery.desc.properties which now points to freed memory leading to backtraces like this one: Sep 22 20:01:35 eric kernel: BUG: unable to handle page fault for address: ffffb2140e017f08 … Sep 22 20:01:35 eric kernel: Workqueue: usb_hub_wq hub_event Sep 22 20:01:35 eric kernel: RIP: 0010:power_supply_uevent+0xee/0x1d0 … Sep 22 20:01:35 eric kernel: ? asm_exc_page_fault+0x26/0x30 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0xee/0x1d0 Sep 22 20:01:35 eric kernel: ? power_supply_uevent+0x10d/0x1d0 Sep 22 20:01:35 eric kernel: dev_uevent+0x10f/0x2d0 Sep 22 20:01:35 eric kernel: kobject_uevent_env+0x291/0x680 Sep 22 20:01:35 eric kernel: —truncated— 2024-02-29 not yet calculated CVE-2023-52478
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix uaf in smb20_oplock_break_ack drop reference after use opinfo. 2024-02-29 not yet calculated CVE-2023-52479
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ksmbd: fix race condition between session lookup and expire Thread A + Thread B ksmbd_session_lookup | smb2_sess_setup sess = xa_load | | | xa_erase(&conn->sessions, sess->id); | | ksmbd_session_destroy(sess) –> kfree(sess) | // UAF! | sess->last_active = jiffies | + This patch add rwsem to fix race condition between ksmbd_session_lookup and ksmbd_expire_session. 2024-02-29 not yet calculated CVE-2023-52480
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: arm64: errata: Add Cortex-A520 speculative unprivileged load workaround Implement the workaround for ARM Cortex-A520 erratum 2966298. On an affected Cortex-A520 core, a speculatively executed unprivileged load might leak data from a privileged load via a cache side channel. The issue only exists for loads within a translation regime with the same translation (e.g. same ASID and VMID). Therefore, the issue only affects the return to EL0. The workaround is to execute a TLBI before returning to EL0 after all loads of privileged data. A non-shareable TLBI to any address is sufficient. The workaround isn’t necessary if page table isolation (KPTI) is enabled, but for simplicity it will be. Page table isolation should normally be disabled for Cortex-A520 as it supports the CSV3 feature and the E0PD feature (used when KASLR is enabled). 2024-02-29 not yet calculated CVE-2023-52481
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: x86/srso: Add SRSO mitigation for Hygon processors Add mitigation for the speculative return stack overflow vulnerability which exists on Hygon processors too. 2024-02-29 not yet calculated CVE-2023-52482
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mctp: perform route lookups under a RCU read-side lock Our current route lookups (mctp_route_lookup and mctp_route_lookup_null) traverse the net’s route list without the RCU read lock held. This means the route lookup is subject to preemption, resulting in an potential grace period expiry, and so an eventual kfree() while we still have the route pointer. Add the proper read-side critical section locks around the route lookups, preventing premption and a possible parallel kfree. The remaining net->mctp.routes accesses are already under a rcu_read_lock, or protected by the RTNL for updates. Based on an analysis from Sili Luo <rootlab@huawei.com>, where introducing a delay in the route lookup could cause a UAF on simultaneous sendmsg() and route deletion. 2024-02-29 not yet calculated CVE-2023-52483
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range When running an SVA case, the following soft lockup is triggered: ——————————————————————– watchdog: BUG: soft lockup – CPU#244 stuck for 26s! pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=–) pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50 sp : ffff8000d83ef290 x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000 x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000 x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0 x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0 x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000 x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001 Call trace: arm_smmu_cmdq_issue_cmdlist+0x178/0xa50 __arm_smmu_tlb_inv_range+0x118/0x254 arm_smmu_tlb_inv_range_asid+0x6c/0x130 arm_smmu_mm_invalidate_range+0xa0/0xa4 __mmu_notifier_invalidate_range_end+0x88/0x120 unmap_vmas+0x194/0x1e0 unmap_region+0xb4/0x144 do_mas_align_munmap+0x290/0x490 do_mas_munmap+0xbc/0x124 __vm_munmap+0xa8/0x19c __arm64_sys_munmap+0x28/0x50 invoke_syscall+0x78/0x11c el0_svc_common.constprop.0+0x58/0x1c0 do_el0_svc+0x34/0x60 el0_svc+0x2c/0xd4 el0t_64_sync_handler+0x114/0x140 el0t_64_sync+0x1a4/0x1a8 ——————————————————————– Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed to “arm_smmu_mm_arch_invalidate_secondary_tlbs”, yet the problem remains. The commit 06ff87bae8d3 (“arm64: mm: remove unused functions and variable protoypes”) fixed a similar lockup on the CPU MMU side. Yet, it can occur to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called typically next to MMU tlb flush function, e.g. tlb_flush_mmu_tlbonly { tlb_flush { __flush_tlb_range { // check MAX_TLBI_OPS } } mmu_notifier_arch_invalidate_secondary_tlbs { arm_smmu_mm_arch_invalidate_secondary_tlbs { // does not check MAX_TLBI_OPS } } } Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an SVA case SMMU uses the CPU page table, so it makes sense to align with the tlbflush code. Then, replace per-page TLBI commands with a single per-asid TLBI command, if the request size hits this threshold. 2024-02-29 not yet calculated CVE-2023-52484
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm/amd/display: Wake DMCUB before sending a command [Why] We can hang in place trying to send commands when the DMCUB isn’t powered on. [How] For functions that execute within a DC context or DC lock we can wrap the direct calls to dm_execute_dmub_cmd/list with code that exits idle power optimizations and reallows once we’re done with the command submission on success. For DM direct submissions the DM will need to manage the enter/exit sequencing manually. We cannot invoke a DMCUB command directly within the DM execution helper or we can deadlock. 2024-02-29 not yet calculated CVE-2023-52485
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: erofs: fix lz4 inplace decompression Currently EROFS can map another compressed buffer for inplace decompression, that was used to handle the cases that some pages of compressed data are actually not in-place I/O. However, like most simple LZ77 algorithms, LZ4 expects the compressed data is arranged at the end of the decompressed buffer and it explicitly uses memmove() to handle overlapping: __________________________________________________________ |_ direction of decompression –> ____ |_ compressed data _| Although EROFS arranges compressed data like this, it typically maps two individual virtual buffers so the relative order is uncertain. Previously, it was hardly observed since LZ4 only uses memmove() for short overlapped literals and x86/arm64 memmove implementations seem to completely cover it up and they don’t have this issue. Juhyung reported that EROFS data corruption can be found on a new Intel x86 processor. After some analysis, it seems that recent x86 processors with the new FSRM feature expose this issue with “rep movsb”. Let’s strictly use the decompressed buffer for lz4 inplace decompression for now. Later, as an useful improvement, we could try to tie up these two buffers together in the correct order. 2024-03-01 not yet calculated CVE-2023-52497
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: powerpc/47x: Fix 47x syscall return crash Eddie reported that newer kernels were crashing during boot on his 476 FSP2 system: kernel tried to execute user page (b7ee2000) – exploit attempt? (uid: 0) BUG: Unable to handle kernel instruction fetch Faulting instruction address: 0xb7ee2000 Oops: Kernel access of bad area, sig: 11 [#1] BE PAGE_SIZE=4K FSP-2 Modules linked in: CPU: 0 PID: 61 Comm: mount Not tainted 6.1.55-d23900f.ppcnf-fsp2 #1 Hardware name: ibm,fsp2 476fpe 0x7ff520c0 FSP-2 NIP:  b7ee2000 LR: 8c008000 CTR: 00000000 REGS: bffebd83 TRAP: 0400   Not tainted (6.1.55-d23900f.ppcnf-fs p2) MSR:  00000030 <IR,DR>  CR: 00001000  XER: 20000000 GPR00: c00110ac bffebe63 bffebe7e bffebe88 8c008000 00001000 00000d12 b7ee2000 GPR08: 00000033 00000000 00000000 c139df10 48224824 1016c314 10160000 00000000 GPR16: 10160000 10160000 00000008 00000000 10160000 00000000 10160000 1017f5b0 GPR24: 1017fa50 1017f4f0 1017fa50 1017f740 1017f630 00000000 00000000 1017f4f0 NIP [b7ee2000] 0xb7ee2000 LR [8c008000] 0x8c008000 Call Trace: Instruction dump: XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX —[ end trace 0000000000000000 ]— The problem is in ret_from_syscall where the check for icache_44x_need_flush is done. When the flush is needed the code jumps out-of-line to do the flush, and then intends to jump back to continue the syscall return. However the branch back to label 1b doesn’t return to the correct location, instead branching back just prior to the return to userspace, causing bogus register values to be used by the rfi. The breakage was introduced by commit 6f76a01173cc (“powerpc/syscall: implement system call entry/exit logic in C for PPC32”) which inadvertently removed the “https://www.cisa.gov/news-events/bulletins/1” label and reused it elsewhere. Fix it by adding named local labels in the correct locations. Note that the return label needs to be outside the ifdef so that CONFIG_PPC_47x=n compiles. 2024-03-02 not yet calculated CVE-2023-52499
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed when we receive the response. 2024-03-02 not yet calculated CVE-2023-52500
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ring-buffer: Do not attempt to read past “commit” When iterating over the ring buffer while the ring buffer is active, the writer can corrupt the reader. There’s barriers to help detect this and handle it, but that code missed the case where the last event was at the very end of the page and has only 4 bytes left. The checks to detect the corruption by the writer to reads needs to see the length of the event. If the length in the first 4 bytes is zero then the length is stored in the second 4 bytes. But if the writer is in the process of updating that code, there’s a small window where the length in the first 4 bytes could be zero even though the length is only 4 bytes. That will cause rb_event_length() to read the next 4 bytes which could happen to be off the allocated page. To protect against this, fail immediately if the next event pointer is less than 8 bytes from the end of the commit (last byte of data), as all events must be a minimum of 8 bytes anyway. 2024-03-02 not yet calculated CVE-2023-52501
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn() Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF. Getting a reference on the socket found in a lookup while holding a lock should happen before releasing the lock. nfc_llcp_sock_get_sn() has a similar problem. Finally nfc_llcp_recv_snl() needs to make sure the socket found by nfc_llcp_sock_from_sn() does not disappear. 2024-03-02 not yet calculated CVE-2023-52502
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: tee: amdtee: fix use-after-free vulnerability in amdtee_close_session There is a potential race condition in amdtee_close_session that may cause use-after-free in amdtee_open_session. For instance, if a session has refcount == 1, and one thread tries to free this session via: kref_put(&sess->refcount, destroy_session); the reference count will get decremented, and the next step would be to call destroy_session(). However, if in another thread, amdtee_open_session() is called before destroy_session() has completed execution, alloc_session() may return ‘sess’ that will be freed up later in destroy_session() leading to use-after-free in amdtee_open_session. To fix this issue, treat decrement of sess->refcount and removal of ‘sess’ from session list in destroy_session() as a critical section, so that it is executed atomically. 2024-03-02 not yet calculated CVE-2023-52503
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: x86/alternatives: Disable KASAN in apply_alternatives() Fei has reported that KASAN triggers during apply_alternatives() on a 5-level paging machine: BUG: KASAN: out-of-bounds in rcu_is_watching() Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0 … __asan_load4() rcu_is_watching() trace_hardirqs_on() text_poke_early() apply_alternatives() … On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57) gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on __VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled(). KASAN gets confused when apply_alternatives() patches the KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue. Fix it for real by disabling KASAN while the kernel is patching alternatives. [ mingo: updated the changelog ] 2024-03-02 not yet calculated CVE-2023-52504
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: phy: lynx-28g: serialize concurrent phy_set_mode_ext() calls to shared registers The protocol converter configuration registers PCC8, PCCC, PCCD (implemented by the driver), as well as others, control protocol converters from multiple lanes (each represented as a different struct phy). So, if there are simultaneous calls to phy_set_mode_ext() to lanes sharing the same PCC register (either for the “old” or for the “new” protocol), corruption of the values programmed to hardware is possible, because lynx_28g_rmw() has no locking. Add a spinlock in the struct lynx_28g_priv shared by all lanes, and take the global spinlock from the phy_ops :: set_mode() implementation. There are no other callers which modify PCC registers. 2024-03-02 not yet calculated CVE-2023-52505
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: LoongArch: Set all reserved memblocks on Node#0 at initialization After commit 61167ad5fecdea (“mm: pass nid to reserve_bootmem_region()”) we get a panic if DEFERRED_STRUCT_PAGE_INIT is enabled: [ 0.000000] CPU 0 Unable to handle kernel paging request at virtual address 0000000000002b82, era == 90000000040e3f28, ra == 90000000040e3f18 [ 0.000000] Oops[#1]: [ 0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 6.5.0+ #733 [ 0.000000] pc 90000000040e3f28 ra 90000000040e3f18 tp 90000000046f4000 sp 90000000046f7c90 [ 0.000000] a0 0000000000000001 a1 0000000000200000 a2 0000000000000040 a3 90000000046f7ca0 [ 0.000000] a4 90000000046f7ca4 a5 0000000000000000 a6 90000000046f7c38 a7 0000000000000000 [ 0.000000] t0 0000000000000002 t1 9000000004b00ac8 t2 90000000040e3f18 t3 90000000040f0800 [ 0.000000] t4 00000000000f0000 t5 80000000ffffe07e t6 0000000000000003 t7 900000047fff5e20 [ 0.000000] t8 aaaaaaaaaaaaaaab u0 0000000000000018 s9 0000000000000000 s0 fffffefffe000000 [ 0.000000] s1 0000000000000000 s2 0000000000000080 s3 0000000000000040 s4 0000000000000000 [ 0.000000] s5 0000000000000000 s6 fffffefffe000000 s7 900000000470b740 s8 9000000004ad4000 [ 0.000000] ra: 90000000040e3f18 reserve_bootmem_region+0xec/0x21c [ 0.000000] ERA: 90000000040e3f28 reserve_bootmem_region+0xfc/0x21c [ 0.000000] CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE) [ 0.000000] PRMD: 00000000 (PPLV0 -PIE -PWE) [ 0.000000] EUEN: 00000000 (-FPE -SXE -ASXE -BTE) [ 0.000000] ECFG: 00070800 (LIE=11 VS=7) [ 0.000000] ESTAT: 00010800 [PIL] (IS=11 ECode=1 EsubCode=0) [ 0.000000] BADV: 0000000000002b82 [ 0.000000] PRID: 0014d000 (Loongson-64bit, Loongson-3A6000) [ 0.000000] Modules linked in: [ 0.000000] Process swapper (pid: 0, threadinfo=(____ptrval____), task=(____ptrval____)) [ 0.000000] Stack : 0000000000000000 9000000002eb5430 0000003a00000020 90000000045ccd00 [ 0.000000] 900000000470e000 90000000002c1918 0000000000000000 9000000004110780 [ 0.000000] 00000000fe6c0000 0000000480000000 9000000004b4e368 9000000004110748 [ 0.000000] 0000000000000000 900000000421ca84 9000000004620000 9000000004564970 [ 0.000000] 90000000046f7d78 9000000002cc9f70 90000000002c1918 900000000470e000 [ 0.000000] 9000000004564970 90000000040bc0e0 90000000046f7d78 0000000000000000 [ 0.000000] 0000000000004000 90000000045ccd00 0000000000000000 90000000002c1918 [ 0.000000] 90000000002c1900 900000000470b700 9000000004b4df78 9000000004620000 [ 0.000000] 90000000046200a8 90000000046200a8 0000000000000000 9000000004218b2c [ 0.000000] 9000000004270008 0000000000000001 0000000000000000 90000000045ccd00 [ 0.000000] … [ 0.000000] Call Trace: [ 0.000000] [<90000000040e3f28>] reserve_bootmem_region+0xfc/0x21c [ 0.000000] [<900000000421ca84>] memblock_free_all+0x114/0x350 [ 0.000000] [<9000000004218b2c>] mm_core_init+0x138/0x3cc [ 0.000000] [<9000000004200e38>] start_kernel+0x488/0x7a4 [ 0.000000] [<90000000040df0d8>] kernel_entry+0xd8/0xdc [ 0.000000] [ 0.000000] Code: 02eb21ad 00410f4c 380c31ac <262b818d> 6800b70d 02c1c196 0015001c 57fe4bb1 260002cd The reason is early memblock_reserve() in memblock_init() set node id to MAX_NUMNODES, making NODE_DATA(nid) a NULL dereference in the call chain reserve_bootmem_region() -> init_reserved_page(). After memblock_init(), those late calls of memblock_reserve() operate on subregions of memblock .memory regions. As a result, these reserved regions will be set to the correct node at the first iteration of memmap_init_reserved_pages(). So set all reserved memblocks on Node#0 at initialization can avoid this panic. 2024-03-02 not yet calculated CVE-2023-52506
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nfc: nci: assert requested protocol is valid The protocol is used in a bit mask to determine if the protocol is supported. Assert the provided protocol is less than the maximum defined so it doesn’t potentially perform a shift-out-of-bounds and provide a clearer error for undefined protocols vs unsupported ones. 2024-03-02 not yet calculated CVE-2023-52507
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nvme-fc: Prevent null pointer dereference in nvme_fc_io_getuuid() The nvme_fc_fcp_op structure describing an AEN operation is initialized with a null request structure pointer. An FC LLDD may make a call to nvme_fc_io_getuuid passing a pointer to an nvmefc_fcp_req for an AEN operation. Add validation of the request structure pointer before dereference. 2024-03-02 not yet calculated CVE-2023-52508
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ravb: Fix use-after-free issue in ravb_tx_timeout_work() The ravb_stop() should call cancel_work_sync(). Otherwise, ravb_tx_timeout_work() is possible to use the freed priv after ravb_remove() was called like below: CPU0 CPU1 ravb_tx_timeout() ravb_remove() unregister_netdev() free_netdev(ndev) // free priv ravb_tx_timeout_work() // use priv unregister_netdev() will call .ndo_stop() so that ravb_stop() is called. And, after phy_stop() is called, netif_carrier_off() is also called. So that .ndo_tx_timeout() will not be called after phy_stop(). 2024-03-02 not yet calculated CVE-2023-52509
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ieee802154: ca8210: Fix a potential UAF in ca8210_probe If of_clk_add_provider() fails in ca8210_register_ext_clock(), it calls clk_unregister() to release priv->clk and returns an error. However, the caller ca8210_probe() then calls ca8210_remove(), where priv->clk is freed again in ca8210_unregister_ext_clock(). In this case, a use-after-free may happen in the second time we call clk_unregister(). Fix this by removing the first clk_unregister(). Also, priv->clk could be an error code on failure of clk_register_fixed_rate(). Use IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock(). 2024-03-02 not yet calculated CVE-2023-52510
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: reduce DMA RX transfer width to single byte Through empirical testing it has been determined that sometimes RX SPI transfers with DMA enabled return corrupted data. This is down to single or even multiple bytes lost during DMA transfer from SPI peripheral to memory. It seems the RX FIFO within the SPI peripheral can become confused when performing bus read accesses wider than a single byte to it during an active SPI transfer. This patch reduces the width of individual DMA read accesses to the RX FIFO to a single byte to mitigate that issue. 2024-03-02 not yet calculated CVE-2023-52511
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: pinctrl: nuvoton: wpcm450: fix out of bounds write Write into ‘pctrl->gpio_bank’ happens before the check for GPIO index validity, so out of bounds write may happen. Found by Linux Verification Center (linuxtesting.org) with SVACE. 2024-03-02 not yet calculated CVE-2023-52512
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: RDMA/siw: Fix connection failure handling In case immediate MPA request processing fails, the newly created endpoint unlinks the listening endpoint and is ready to be dropped. This special case was not handled correctly by the code handling the later TCP socket close, causing a NULL dereference crash in siw_cm_work_handler() when dereferencing a NULL listener. We now also cancel the useless MPA timeout, if immediate MPA request processing fails. This patch furthermore simplifies MPA processing in general: Scheduling a useless TCP socket read in sk_data_ready() upcall is now surpressed, if the socket is already moved out of TCP_ESTABLISHED state. 2024-03-02 not yet calculated CVE-2023-52513
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: x86/reboot: VMCLEAR active VMCSes before emergency reboot VMCLEAR active VMCSes before any emergency reboot, not just if the kernel may kexec into a new kernel after a crash. Per Intel’s SDM, the VMX architecture doesn’t require the CPU to flush the VMCS cache on INIT. If an emergency reboot doesn’t RESET CPUs, cached VMCSes could theoretically be kept and only be written back to memory after the new kernel is booted, i.e. could effectively corrupt memory after reboot. Opportunistically remove the setting of the global pointer to NULL to make checkpatch happy. 2024-03-02 not yet calculated CVE-2023-52514
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: RDMA/srp: Do not call scsi_done() from srp_abort() After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler callback, it performs one of the following actions: * Call scsi_queue_insert(). * Call scsi_finish_command(). * Call scsi_eh_scmd_add(). Hence, SCSI abort handlers must not call scsi_done(). Otherwise all the above actions would trigger a use-after-free. Hence remove the scsi_done() call from srp_abort(). Keep the srp_free_req() call before returning SUCCESS because we may not see the command again if SUCCESS is returned. 2024-03-02 not yet calculated CVE-2023-52515
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dma-debug: don’t call __dma_entry_alloc_check_leak() under free_entries_lock __dma_entry_alloc_check_leak() calls into printk -> serial console output (qcom geni) and grabs port->lock under free_entries_lock spin lock, which is a reverse locking dependency chain as qcom_geni IRQ handler can call into dma-debug code and grab free_entries_lock under port->lock. Move __dma_entry_alloc_check_leak() call out of free_entries_lock scope so that we don’t acquire serial console’s port->lock under it. Trimmed-down lockdep splat: The existing dependency chain (in reverse order) is: -> #2 (free_entries_lock){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 dma_entry_alloc+0x38/0x110 debug_dma_map_page+0x60/0xf8 dma_map_page_attrs+0x1e0/0x230 dma_map_single_attrs.constprop.0+0x6c/0xc8 geni_se_rx_dma_prep+0x40/0xcc qcom_geni_serial_isr+0x310/0x510 __handle_irq_event_percpu+0x110/0x244 handle_irq_event_percpu+0x20/0x54 handle_irq_event+0x50/0x88 handle_fasteoi_irq+0xa4/0xcc handle_irq_desc+0x28/0x40 generic_handle_domain_irq+0x24/0x30 gic_handle_irq+0xc4/0x148 do_interrupt_handler+0xa4/0xb0 el1_interrupt+0x34/0x64 el1h_64_irq_handler+0x18/0x24 el1h_64_irq+0x64/0x68 arch_local_irq_enable+0x4/0x8 ____do_softirq+0x18/0x24 … -> #1 (&port_lock_key){-.-.}-{2:2}: _raw_spin_lock_irqsave+0x60/0x80 qcom_geni_serial_console_write+0x184/0x1dc console_flush_all+0x344/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 register_console+0x230/0x38c uart_add_one_port+0x338/0x494 qcom_geni_serial_probe+0x390/0x424 platform_probe+0x70/0xc0 really_probe+0x148/0x280 __driver_probe_device+0xfc/0x114 driver_probe_device+0x44/0x100 __device_attach_driver+0x64/0xdc bus_for_each_drv+0xb0/0xd8 __device_attach+0xe4/0x140 device_initial_probe+0x1c/0x28 bus_probe_device+0x44/0xb0 device_add+0x538/0x668 of_device_add+0x44/0x50 of_platform_device_create_pdata+0x94/0xc8 of_platform_bus_create+0x270/0x304 of_platform_populate+0xac/0xc4 devm_of_platform_populate+0x60/0xac geni_se_probe+0x154/0x160 platform_probe+0x70/0xc0 … -> #0 (console_owner){-…}-{0:0}: __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 console_unlock+0x94/0xf0 vprintk_emit+0x238/0x24c vprintk_default+0x3c/0x48 vprintk+0xb4/0xbc _printk+0x68/0x90 dma_entry_alloc+0xb4/0x110 debug_dma_map_sg+0xdc/0x2f8 __dma_map_sg_attrs+0xac/0xe4 dma_map_sgtable+0x30/0x4c get_pages+0x1d4/0x1e4 [msm] msm_gem_pin_pages_locked+0x38/0xac [msm] msm_gem_pin_vma_locked+0x58/0x88 [msm] msm_ioctl_gem_submit+0xde4/0x13ac [msm] drm_ioctl_kernel+0xe0/0x15c drm_ioctl+0x2e8/0x3f4 vfs_ioctl+0x30/0x50 … Chain exists of: console_owner –> &port_lock_key –> free_entries_lock Possible unsafe locking scenario: CPU0 CPU1 —- —- lock(free_entries_lock); lock(&port_lock_key); lock(free_entries_lock); lock(console_owner); *** DEADLOCK *** Call trace: dump_backtrace+0xb4/0xf0 show_stack+0x20/0x30 dump_stack_lvl+0x60/0x84 dump_stack+0x18/0x24 print_circular_bug+0x1cc/0x234 check_noncircular+0x78/0xac __lock_acquire+0xdf8/0x109c lock_acquire+0x234/0x284 console_flush_all+0x330/0x454 consol —truncated— 2024-03-02 not yet calculated CVE-2023-52516
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: spi: sun6i: fix race between DMA RX transfer completion and RX FIFO drain Previously the transfer complete IRQ immediately drained to RX FIFO to read any data remaining in FIFO to the RX buffer. This behaviour is correct when dealing with SPI in interrupt mode. However in DMA mode the transfer complete interrupt still fires as soon as all bytes to be transferred have been stored in the FIFO. At that point data in the FIFO still needs to be picked up by the DMA engine. Thus the drain procedure and DMA engine end up racing to read from RX FIFO, corrupting any data read. Additionally the RX buffer pointer is never adjusted according to DMA progress in DMA mode, thus calling the RX FIFO drain procedure in DMA mode is a bug. Fix corruptions in DMA RX mode by draining RX FIFO only in interrupt mode. Also wait for completion of RX DMA when in DMA mode before returning to ensure all data has been copied to the supplied memory buffer. 2024-03-02 not yet calculated CVE-2023-52517
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_codec: Fix leaking content of local_codecs The following memory leak can be observed when the controller supports codecs which are stored in local_codecs list but the elements are never freed: unreferenced object 0xffff88800221d840 (size 32): comm “kworker/u3:0”, pid 36, jiffies 4294898739 (age 127.060s) hex dump (first 32 bytes): f8 d3 02 03 80 88 ff ff 80 d8 21 02 80 88 ff ff ……….!….. 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ……………. backtrace: [<ffffffffb324f557>] __kmalloc+0x47/0x120 [<ffffffffb39ef37d>] hci_codec_list_add.isra.0+0x2d/0x160 [<ffffffffb39ef643>] hci_read_codec_capabilities+0x183/0x270 [<ffffffffb39ef9ab>] hci_read_supported_codecs+0x1bb/0x2d0 [<ffffffffb39f162e>] hci_read_local_codecs_sync+0x3e/0x60 [<ffffffffb39ff1b3>] hci_dev_open_sync+0x943/0x11e0 [<ffffffffb396d55d>] hci_power_on+0x10d/0x3f0 [<ffffffffb30c99b4>] process_one_work+0x404/0x800 [<ffffffffb30ca134>] worker_thread+0x374/0x670 [<ffffffffb30d9108>] kthread+0x188/0x1c0 [<ffffffffb304db6b>] ret_from_fork+0x2b/0x50 [<ffffffffb300206a>] ret_from_fork_asm+0x1a/0x30 2024-03-02 not yet calculated CVE-2023-52518
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: HID: intel-ish-hid: ipc: Disable and reenable ACPI GPE bit The EHL (Elkhart Lake) based platforms provide a OOB (Out of band) service, which allows to wakup device when the system is in S5 (Soft-Off state). This OOB service can be enabled/disabled from BIOS settings. When enabled, the ISH device gets PME wake capability. To enable PME wakeup, driver also needs to enable ACPI GPE bit. On resume, BIOS will clear the wakeup bit. So driver need to re-enable it in resume function to keep the next wakeup capability. But this BIOS clearing of wakeup bit doesn’t decrement internal OS GPE reference count, so this reenabling on every resume will cause reference count to overflow. So first disable and reenable ACPI GPE bit using acpi_disable_gpe(). 2024-03-02 not yet calculated CVE-2023-52519
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: platform/x86: think-lmi: Fix reference leak If a duplicate attribute is found using kset_find_obj(), a reference to that attribute is returned which needs to be disposed accordingly using kobject_put(). Move the setting name validation into a separate function to allow for this change without having to duplicate the cleanup code for this setting. As a side note, a very similar bug was fixed in commit 7295a996fdab (“platform/x86: dell-sysman: Fix reference leak”), so it seems that the bug was copied from that driver. Compile-tested only. 2024-03-02 not yet calculated CVE-2023-52520
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: bpf: Annotate bpf_long_memcpy with data_race syzbot reported a data race splat between two processes trying to update the same BPF map value via syscall on different CPUs: BUG: KCSAN: data-race in bpf_percpu_array_update / bpf_percpu_array_update write to 0xffffe8fffe7425d8 of 8 bytes by task 8257 on cpu 1: bpf_long_memcpy include/linux/bpf.h:428 [inline] bpf_obj_memcpy include/linux/bpf.h:441 [inline] copy_map_value_long include/linux/bpf.h:464 [inline] bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380 bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175 generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749 bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648 __sys_bpf+0x28a/0x780 __do_sys_bpf kernel/bpf/syscall.c:5241 [inline] __se_sys_bpf kernel/bpf/syscall.c:5239 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd write to 0xffffe8fffe7425d8 of 8 bytes by task 8268 on cpu 0: bpf_long_memcpy include/linux/bpf.h:428 [inline] bpf_obj_memcpy include/linux/bpf.h:441 [inline] copy_map_value_long include/linux/bpf.h:464 [inline] bpf_percpu_array_update+0x3bb/0x500 kernel/bpf/arraymap.c:380 bpf_map_update_value+0x190/0x370 kernel/bpf/syscall.c:175 generic_map_update_batch+0x3ae/0x4f0 kernel/bpf/syscall.c:1749 bpf_map_do_batch+0x2df/0x3d0 kernel/bpf/syscall.c:4648 __sys_bpf+0x28a/0x780 __do_sys_bpf kernel/bpf/syscall.c:5241 [inline] __se_sys_bpf kernel/bpf/syscall.c:5239 [inline] __x64_sys_bpf+0x43/0x50 kernel/bpf/syscall.c:5239 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd value changed: 0x0000000000000000 -> 0xfffffff000002788 The bpf_long_memcpy is used with 8-byte aligned pointers, power-of-8 size and forced to use long read/writes to try to atomically copy long counters. It is best-effort only and no barriers are here since it _will_ race with concurrent updates from BPF programs. The bpf_long_memcpy() is called from bpf(2) syscall. Marco suggested that the best way to make this known to KCSAN would be to use data_race() annotation. 2024-03-02 not yet calculated CVE-2023-52521
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: fix possible store tearing in neigh_periodic_work() While looking at a related syzbot report involving neigh_periodic_work(), I found that I forgot to add an annotation when deleting an RCU protected item from a list. Readers use rcu_deference(*np), we need to use either rcu_assign_pointer() or WRITE_ONCE() on writer side to prevent store tearing. I use rcu_assign_pointer() to have lockdep support, this was the choice made in neigh_flush_dev(). 2024-03-02 not yet calculated CVE-2023-52522
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: bpf, sockmap: Reject sk_msg egress redirects to non-TCP sockets With a SOCKMAP/SOCKHASH map and an sk_msg program user can steer messages sent from one TCP socket (s1) to actually egress from another TCP socket (s2): tcp_bpf_sendmsg(s1) // = sk_prot->sendmsg tcp_bpf_send_verdict(s1) // __SK_REDIRECT case tcp_bpf_sendmsg_redir(s2) tcp_bpf_push_locked(s2) tcp_bpf_push(s2) tcp_rate_check_app_limited(s2) // expects tcp_sock tcp_sendmsg_locked(s2) // ditto There is a hard-coded assumption in the call-chain, that the egress socket (s2) is a TCP socket. However in commit 122e6c79efe1 (“sock_map: Update sock type checks for UDP”) we have enabled redirects to non-TCP sockets. This was done for the sake of BPF sk_skb programs. There was no indention to support sk_msg send-to-egress use case. As a result, attempts to send-to-egress through a non-TCP socket lead to a crash due to invalid downcast from sock to tcp_sock: BUG: kernel NULL pointer dereference, address: 000000000000002f … Call Trace: <TASK> ? show_regs+0x60/0x70 ? __die+0x1f/0x70 ? page_fault_oops+0x80/0x160 ? do_user_addr_fault+0x2d7/0x800 ? rcu_is_watching+0x11/0x50 ? exc_page_fault+0x70/0x1c0 ? asm_exc_page_fault+0x27/0x30 ? tcp_tso_segs+0x14/0xa0 tcp_write_xmit+0x67/0xce0 __tcp_push_pending_frames+0x32/0xf0 tcp_push+0x107/0x140 tcp_sendmsg_locked+0x99f/0xbb0 tcp_bpf_push+0x19d/0x3a0 tcp_bpf_sendmsg_redir+0x55/0xd0 tcp_bpf_send_verdict+0x407/0x550 tcp_bpf_sendmsg+0x1a1/0x390 inet_sendmsg+0x6a/0x70 sock_sendmsg+0x9d/0xc0 ? sockfd_lookup_light+0x12/0x80 __sys_sendto+0x10e/0x160 ? syscall_enter_from_user_mode+0x20/0x60 ? __this_cpu_preempt_check+0x13/0x20 ? lockdep_hardirqs_on+0x82/0x110 __x64_sys_sendto+0x1f/0x30 do_syscall_64+0x38/0x90 entry_SYSCALL_64_after_hwframe+0x63/0xcd Reject selecting a non-TCP sockets as redirect target from a BPF sk_msg program to prevent the crash. When attempted, user will receive an EACCES error from send/sendto/sendmsg() syscall. 2024-03-02 not yet calculated CVE-2023-52523
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: nfc: llcp: Add lock when modifying device list The device list needs its associated lock held when modifying it, or the list could become corrupted, as syzbot discovered. 2024-03-02 not yet calculated CVE-2023-52524
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: wifi: mwifiex: Fix oob check condition in mwifiex_process_rx_packet Only skip the code path trying to access the rfc1042 headers when the buffer is too small, so the driver can still process packets without rfc1042 headers. 2024-03-02 not yet calculated CVE-2023-52525
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: erofs: fix memory leak of LZMA global compressed deduplication When stressing microLZMA EROFS images with the new global compressed deduplication feature enabled (`-Ededupe`), I found some short-lived temporary pages weren’t properly released, which could slowly cause unexpected OOMs hours later. Let’s fix it now (LZ4 and DEFLATE don’t have this issue.) 2024-03-02 not yet calculated CVE-2023-52526
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data() Including the transhdrlen in length is a problem when the packet is partially filled (e.g. something like send(MSG_MORE) happened previously) when appending to an IPv4 or IPv6 packet as we don’t want to repeat the transport header or account for it twice. This can happen under some circumstances, such as splicing into an L2TP socket. The symptom observed is a warning in __ip6_append_data(): WARNING: CPU: 1 PID: 5042 at net/ipv6/ip6_output.c:1800 __ip6_append_data.isra.0+0x1be8/0x47f0 net/ipv6/ip6_output.c:1800 that occurs when MSG_SPLICE_PAGES is used to append more data to an already partially occupied skbuff. The warning occurs when ‘copy’ is larger than the amount of data in the message iterator. This is because the requested length includes the transport header length when it shouldn’t. This can be triggered by, for example: sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP); bind(sfd, …); // ::1 connect(sfd, …); // ::1 port 7 send(sfd, buffer, 4100, MSG_MORE); sendfile(sfd, dfd, NULL, 1024); Fix this by only adding transhdrlen into the length if the write queue is empty in l2tp_ip6_sendmsg(), analogously to how UDP does things. l2tp_ip_sendmsg() looks like it won’t suffer from this problem as it builds the UDP packet itself. 2024-03-02 not yet calculated CVE-2023-52527
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg syzbot reported the following uninit-value access issue: ===================================================== BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event Call Trace: __dump_stack lib/dump_stack.c:77 [inline] dump_stack+0x21c/0x280 lib/dump_stack.c:118 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline] smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272 really_probe+0xf20/0x20b0 drivers/base/dd.c:529 driver_probe_device+0x293/0x390 drivers/base/dd.c:701 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554 hub_port_connect drivers/usb/core/hub.c:5208 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415 kthread+0x551/0x590 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293 Local variable —-buf.i87@smsc75xx_bind created at: __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline] smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline] smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482 This issue is caused because usbnet_read_cmd() reads less bytes than requested (zero byte in the reproducer). In this case, ‘buf’ is not properly filled. This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads less bytes than requested. 2024-03-02 not yet calculated CVE-2023-52528
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: HID: sony: Fix a potential memory leak in sony_probe() If an error occurs after a successful usb_alloc_urb() call, usb_free_urb() should be called. 2024-03-02 not yet calculated CVE-2023-52529
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: fix potential key use-after-free When ieee80211_key_link() is called by ieee80211_gtk_rekey_add() but returns 0 due to KRACK protection (identical key reinstall), ieee80211_gtk_rekey_add() will still return a pointer into the key, in a potential use-after-free. This normally doesn’t happen since it’s only called by iwlwifi in case of WoWLAN rekey offload which has its own KRACK protection, but still better to fix, do that by returning an error code and converting that to success on the cfg80211 boundary only, leaving the error for bad callers of ieee80211_gtk_rekey_add(). 2024-03-02 not yet calculated CVE-2023-52530
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: Fix a memory corruption issue A few lines above, space is kzalloc()’ed for: sizeof(struct iwl_nvm_data) + sizeof(struct ieee80211_channel) + sizeof(struct ieee80211_rate) ‘mvm->nvm_data’ is a ‘struct iwl_nvm_data’, so it is fine. At the end of this structure, there is the ‘channels’ flex array. Each element is of type ‘struct ieee80211_channel’. So only 1 element is allocated in this array. When doing: mvm->nvm_data->bands[0].channels = mvm->nvm_data->channels; We point at the first element of the ‘channels’ flex array. So this is fine. However, when doing: mvm->nvm_data->bands[0].bitrates = (void *)((u8 *)mvm->nvm_data->channels + 1); because of the “(u8 *)” cast, we add only 1 to the address of the beginning of the flex array. It is likely that we want point at the ‘struct ieee80211_rate’ allocated just after. Remove the spurious casting so that the pointer arithmetic works as expected. 2024-03-02 not yet calculated CVE-2023-52531
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: mana: Fix TX CQE error handling For an unknown TX CQE error type (probably from a newer hardware), still free the SKB, update the queue tail, etc., otherwise the accounting will be wrong. Also, TX errors can be triggered by injecting corrupted packets, so replace the WARN_ONCE to ratelimited error logging. 2024-03-02 not yet calculated CVE-2023-52532
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 N/A — N/A
  In mongo-express 1.0.2, /admin allows CSRF, as demonstrated by deletion of a Collection. 2024-03-01 not yet calculated CVE-2023-52555
cve@mitre.org openbsd — openbsd
  In OpenBSD 7.4 before errata 009, a race condition between pf(4)’s processing of packets and expiration of packet states may cause a kernel panic. 2024-03-01 not yet calculated CVE-2023-52556
9119a7d8-5eab-497f-8521-727c672e3725
9119a7d8-5eab-497f-8521-727c672e3725 openbsd — openbsd
  In OpenBSD 7.3 before errata 016, npppd(8) could crash by a l2tp message which has an AVP (Attribute-Value Pair) with wrong length. 2024-03-01 not yet calculated CVE-2023-52557
9119a7d8-5eab-497f-8521-727c672e3725
9119a7d8-5eab-497f-8521-727c672e3725 openbsd — openbsd
  In OpenBSD 7.4 before errata 002 and OpenBSD 7.3 before errata 019, a network buffer that had to be split at certain length that could crash the kernel after receiving specially crafted escape sequences. 2024-03-01 not yet calculated CVE-2023-52558
9119a7d8-5eab-497f-8521-727c672e3725
9119a7d8-5eab-497f-8521-727c672e3725
9119a7d8-5eab-497f-8521-727c672e3725 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: iommu/vt-d: Avoid memory allocation in iommu_suspend() The iommu_suspend() syscore suspend callback is invoked with IRQ disabled. Allocating memory with the GFP_KERNEL flag may re-enable IRQs during the suspend callback, which can cause intermittent suspend/hibernation problems with the following kernel traces: Calling iommu_suspend+0x0/0x1d0 ————[ cut here ]———— WARNING: CPU: 0 PID: 15 at kernel/time/timekeeping.c:868 ktime_get+0x9b/0xb0 … CPU: 0 PID: 15 Comm: rcu_preempt Tainted: G U E 6.3-intel #r1 RIP: 0010:ktime_get+0x9b/0xb0 … Call Trace: <IRQ> tick_sched_timer+0x22/0x90 ? __pfx_tick_sched_timer+0x10/0x10 __hrtimer_run_queues+0x111/0x2b0 hrtimer_interrupt+0xfa/0x230 __sysvec_apic_timer_interrupt+0x63/0x140 sysvec_apic_timer_interrupt+0x7b/0xa0 </IRQ> <TASK> asm_sysvec_apic_timer_interrupt+0x1f/0x30 … ————[ cut here ]———— Interrupts enabled after iommu_suspend+0x0/0x1d0 WARNING: CPU: 0 PID: 27420 at drivers/base/syscore.c:68 syscore_suspend+0x147/0x270 CPU: 0 PID: 27420 Comm: rtcwake Tainted: G U W E 6.3-intel #r1 RIP: 0010:syscore_suspend+0x147/0x270 … Call Trace: <TASK> hibernation_snapshot+0x25b/0x670 hibernate+0xcd/0x390 state_store+0xcf/0xe0 kobj_attr_store+0x13/0x30 sysfs_kf_write+0x3f/0x50 kernfs_fop_write_iter+0x128/0x200 vfs_write+0x1fd/0x3c0 ksys_write+0x6f/0xf0 __x64_sys_write+0x1d/0x30 do_syscall_64+0x3b/0x90 entry_SYSCALL_64_after_hwframe+0x72/0xdc Given that only 4 words memory is needed, avoid the memory allocation in iommu_suspend(). 2024-03-02 not yet calculated CVE-2023-52559
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions() When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected. Since commit 9f86d624292c (“mm/damon/vaddr-test: remove unnecessary variables”), the damon_destroy_ctx() is removed, but still call damon_new_target() and damon_new_region(), the damon_region which is allocated by kmem_cache_alloc() in damon_new_region() and the damon_target which is allocated by kmalloc in damon_new_target() are not freed. And the damon_region which is allocated in damon_new_region() in damon_set_regions() is also not freed. So use damon_destroy_target to free all the damon_regions and damon_target. unreferenced object 0xffff888107c9a940 (size 64): comm “kunit_try_catch”, pid 1069, jiffies 4294670592 (age 732.761s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b …………kkkk 60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff `…………… backtrace: [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0 [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0 [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 [<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260 [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81237cf6>] kthread+0x2b6/0x380 [<ffffffff81097add>] ret_from_fork+0x2d/0x70 [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff8881079cc740 (size 56): comm “kunit_try_catch”, pid 1069, jiffies 4294670592 (age 732.761s) hex dump (first 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ……………. 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk….kkkk backtrace: [<ffffffff819bc492>] damon_new_region+0x22/0x1c0 [<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0 [<ffffffff819c82be>] damon_test_apply_three_regions1+0x21e/0x260 [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81237cf6>] kthread+0x2b6/0x380 [<ffffffff81097add>] ret_from_fork+0x2d/0x70 [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff888107c9ac40 (size 64): comm “kunit_try_catch”, pid 1071, jiffies 4294670595 (age 732.843s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b …………kkkk a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff ……..x.v….. backtrace: [<ffffffff817e0167>] kmalloc_trace+0x27/0xa0 [<ffffffff819c11cf>] damon_new_target+0x3f/0x1b0 [<ffffffff819c7d55>] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0 [<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260 [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81237cf6>] kthread+0x2b6/0x380 [<ffffffff81097add>] ret_from_fork+0x2d/0x70 [<ffffffff81003791>] ret_from_fork_asm+0x11/0x20 unreferenced object 0xffff8881079ccc80 (size 56): comm “kunit_try_catch”, pid 1071, jiffies 4294670595 (age 732.843s) hex dump (first 32 bytes): 05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00 ……………. 6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b kkkkkkkk….kkkk backtrace: [<ffffffff819bc492>] damon_new_region+0x22/0x1c0 [<ffffffff819c7d91>] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0 [<ffffffff819c851e>] damon_test_apply_three_regions2+0x21e/0x260 [<ffffffff829fce6a>] kunit_generic_run_threadfn_adapter+0x4a/0x90 [<ffffffff81237cf6>] kthread+0x2b6/0x380 [<ffffffff81097add>] ret_from_fork+0x2d/0x70 [<ffff —truncated— 2024-03-02 not yet calculated CVE-2023-52560
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved Adding a reserved memory region for the framebuffer memory (the splash memory region set up by the bootloader). It fixes a kernel panic (arm-smmu: Unhandled context fault at this particular memory region) reported on DB845c running v5.10.y. 2024-03-02 not yet calculated CVE-2023-52561
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mm/slab_common: fix slab_caches list corruption after kmem_cache_destroy() After the commit in Fixes:, if a module that created a slab cache does not release all of its allocated objects before destroying the cache (at rmmod time), we might end up releasing the kmem_cache object without removing it from the slab_caches list thus corrupting the list as kmem_cache_destroy() ignores the return value from shutdown_cache(), which in turn never removes the kmem_cache object from slabs_list in case __kmem_cache_shutdown() fails to release all of the cache’s slabs. This is easily observable on a kernel built with CONFIG_DEBUG_LIST=y as after that ill release the system will immediately trip on list_add, or list_del, assertions similar to the one shown below as soon as another kmem_cache gets created, or destroyed: [ 1041.213632] list_del corruption. next->prev should be ffff89f596fb5768, but was 52f1e5016aeee75d. (next=ffff89f595a1b268) [ 1041.219165] ————[ cut here ]———— [ 1041.221517] kernel BUG at lib/list_debug.c:62! [ 1041.223452] invalid opcode: 0000 [#1] PREEMPT SMP PTI [ 1041.225408] CPU: 2 PID: 1852 Comm: rmmod Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 1041.228244] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 1041.231212] RIP: 0010:__list_del_entry_valid+0xae/0xb0 Another quick way to trigger this issue, in a kernel with CONFIG_SLUB=y, is to set slub_debug to poison the released objects and then just run cat /proc/slabinfo after removing the module that leaks slab objects, in which case the kernel will panic: [ 50.954843] general protection fault, probably for non-canonical address 0xa56b6b6b6b6b6b8b: 0000 [#1] PREEMPT SMP PTI [ 50.961545] CPU: 2 PID: 1495 Comm: cat Kdump: loaded Tainted: G B W OE 6.5.0 #15 [ 50.966808] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS edk2-20230524-3.fc37 05/24/2023 [ 50.972663] RIP: 0010:get_slabinfo+0x42/0xf0 This patch fixes this issue by properly checking shutdown_cache()’s return value before taking the kmem_cache_release() branch. 2024-03-02 not yet calculated CVE-2023-52562
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm/meson: fix memory leak on ->hpd_notify callback The EDID returned by drm_bridge_get_edid() needs to be freed. 2024-03-02 not yet calculated CVE-2023-52563
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: Revert “tty: n_gsm: fix UAF in gsm_cleanup_mux” This reverts commit 9b9c8195f3f0d74a826077fc1c01b9ee74907239. The commit above is reverted as it did not solve the original issue. gsm_cleanup_mux() tries to free up the virtual ttys by calling gsm_dlci_release() for each available DLCI. There, dlci_put() is called to decrease the reference counter for the DLCI via tty_port_put() which finally calls gsm_dlci_free(). This already clears the pointer which is being checked in gsm_cleanup_mux() before calling gsm_dlci_release(). Therefore, it is not necessary to clear this pointer in gsm_cleanup_mux() as done in the reverted commit. The commit introduces a null pointer dereference: <TASK> ? __die+0x1f/0x70 ? page_fault_oops+0x156/0x420 ? search_exception_tables+0x37/0x50 ? fixup_exception+0x21/0x310 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x26/0x30 ? tty_port_put+0x19/0xa0 gsmtty_cleanup+0x29/0x80 [n_gsm] release_one_tty+0x37/0xe0 process_one_work+0x1e6/0x3e0 worker_thread+0x4c/0x3d0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe1/0x110 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x2f/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 </TASK> The actual issue is that nothing guards dlci_put() from being called multiple times while the tty driver was triggered but did not yet finished calling gsm_dlci_free(). 2024-03-02 not yet calculated CVE-2023-52564
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: media: uvcvideo: Fix OOB read If the index provided by the user is bigger than the mask size, we might do an out of bound read. 2024-03-02 not yet calculated CVE-2023-52565
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: nilfs2: fix potential use after free in nilfs_gccache_submit_read_data() In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the reference count of bh when the call to nilfs_dat_translate() fails. If the reference count hits 0 and its owner page gets unlocked, bh may be freed. However, bh->b_page is dereferenced to put the page after that, which may result in a use-after-free bug. This patch moves the release operation after unlocking and putting the page. NOTE: The function in question is only called in GC, and in combination with current userland tools, address translation using DAT does not occur in that function, so the code path that causes this issue will not be executed. However, it is possible to run that code path by intentionally modifying the userland GC library or by calling the GC ioctl directly. [konishi.ryusuke@gmail.com: NOTE added to the commit log] 2024-03-02 not yet calculated CVE-2023-52566
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: serial: 8250_port: Check IRQ data before use In case the leaf driver wants to use IRQ polling (irq = 0) and IIR register shows that an interrupt happened in the 8250 hardware the IRQ data can be NULL. In such a case we need to skip the wake event as we came to this path from the timer interrupt and quite likely system is already awake. Without this fix we have got an Oops: serial8250: ttyS0 at I/O 0x3f8 (irq = 0, base_baud = 115200) is a 16550A … BUG: kernel NULL pointer dereference, address: 0000000000000010 RIP: 0010:serial8250_handle_irq+0x7c/0x240 Call Trace: ? serial8250_handle_irq+0x7c/0x240 ? __pfx_serial8250_timeout+0x10/0x10 2024-03-02 not yet calculated CVE-2023-52567
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an enclave and set secs.epc_page to NULL. The SECS page is used for EAUG and ELDU in the SGX page fault handler. However, the NULL check for secs.epc_page is only done for ELDU, not EAUG before being used. Fix this by doing the same NULL check and reloading of the SECS page as needed for both EAUG and ELDU. The SECS page holds global enclave metadata. It can only be reclaimed when there are no other enclave pages remaining. At that point, virtually nothing can be done with the enclave until the SECS page is paged back in. An enclave can not run nor generate page faults without a resident SECS page. But it is still possible for a #PF for a non-SECS page to race with paging out the SECS page: when the last resident non-SECS page A triggers a #PF in a non-resident page B, and then page A and the SECS both are paged out before the #PF on B is handled. Hitting this bug requires that race triggered with a #PF for EAUG. Following is a trace when it happens. BUG: kernel NULL pointer dereference, address: 0000000000000000 RIP: 0010:sgx_encl_eaug_page+0xc7/0x210 Call Trace: ? __kmem_cache_alloc_node+0x16a/0x440 ? xa_load+0x6e/0xa0 sgx_vma_fault+0x119/0x230 __do_fault+0x36/0x140 do_fault+0x12f/0x400 __handle_mm_fault+0x728/0x1110 handle_mm_fault+0x105/0x310 do_user_addr_fault+0x1ee/0x750 ? __this_cpu_preempt_check+0x13/0x20 exc_page_fault+0x76/0x180 asm_exc_page_fault+0x27/0x30 2024-03-02 not yet calculated CVE-2023-52568
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: btrfs: remove BUG() after failure to insert delayed dir index item Instead of calling BUG() when we fail to insert a delayed dir index item into the delayed node’s tree, we can just release all the resources we have allocated/acquired before and return the error to the caller. This is fine because all existing call chains undo anything they have done before calling btrfs_insert_delayed_dir_index() or BUG_ON (when creating pending snapshots in the transaction commit path). So remove the BUG() call and do proper error handling. This relates to a syzbot report linked below, but does not fix it because it only prevents hitting a BUG(), it does not fix the issue where somehow we attempt to use twice the same index number for different index items. 2024-03-02 not yet calculated CVE-2023-52569
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: vfio/mdev: Fix a null-ptr-deref bug for mdev_unregister_parent() Inject fault while probing mdpy.ko, if kstrdup() of create_dir() fails in kobject_add_internal() in kobject_init_and_add() in mdev_type_add() in parent_create_sysfs_files(), it will return 0 and probe successfully. And when rmmod mdpy.ko, the mdpy_dev_exit() will call mdev_unregister_parent(), the mdev_type_remove() may traverse uninitialized parent->types[i] in parent_remove_sysfs_files(), and it will cause below null-ptr-deref. If mdev_type_add() fails, return the error code and kset_unregister() to fix the issue. general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017] CPU: 2 PID: 10215 Comm: rmmod Tainted: G W N 6.6.0-rc2+ #20 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014 RIP: 0010:__kobject_del+0x62/0x1c0 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 24 01 00 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8 RSP: 0018:ffff88810695fd30 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffffa0270268 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000004 RDI: 0000000000000010 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10233a4ef1 R10: ffff888119d2778b R11: 0000000063666572 R12: 0000000000000000 R13: fffffbfff404e2d4 R14: dffffc0000000000 R15: ffffffffa0271660 FS: 00007fbc81981540(0000) GS:ffff888119d00000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007fc14a142dc0 CR3: 0000000110a62003 CR4: 0000000000770ee0 DR0: ffffffff8fb0bce8 DR1: ffffffff8fb0bce9 DR2: ffffffff8fb0bcea DR3: ffffffff8fb0bceb DR6: 00000000fffe0ff0 DR7: 0000000000000600 PKRU: 55555554 Call Trace: <TASK> ? die_addr+0x3d/0xa0 ? exc_general_protection+0x144/0x220 ? asm_exc_general_protection+0x22/0x30 ? __kobject_del+0x62/0x1c0 kobject_del+0x32/0x50 parent_remove_sysfs_files+0xd6/0x170 [mdev] mdev_unregister_parent+0xfb/0x190 [mdev] ? mdev_register_parent+0x270/0x270 [mdev] ? find_module_all+0x9d/0xe0 mdpy_dev_exit+0x17/0x63 [mdpy] __do_sys_delete_module.constprop.0+0x2fa/0x4b0 ? module_flags+0x300/0x300 ? __fput+0x4e7/0xa00 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 RIP: 0033:0x7fbc813221b7 Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 RSP: 002b:00007ffe780e0648 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 RAX: ffffffffffffffda RBX: 00007ffe780e06a8 RCX: 00007fbc813221b7 RDX: 000000000000000a RSI: 0000000000000800 RDI: 000055e214df9b58 RBP: 000055e214df9af0 R08: 00007ffe780df5c1 R09: 0000000000000000 R10: 00007fbc8139ecc0 R11: 0000000000000206 R12: 00007ffe780e0870 R13: 00007ffe780e0ed0 R14: 000055e214df9260 R15: 000055e214df9af0 </TASK> Modules linked in: mdpy(-) mdev vfio_iommu_type1 vfio [last unloaded: mdpy] Dumping ftrace buffer: (ftrace buffer empty) —[ end trace 0000000000000000 ]— RIP: 0010:__kobject_del+0x62/0x1c0 Code: 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 51 01 00 00 48 b8 00 00 00 00 00 fc ff df 48 8b 6b 28 48 8d 7d 10 48 89 fa 48 c1 ea 03 <80> 3c 02 00 0f 85 24 01 00 00 48 8b 75 10 48 89 df 48 8d 6b 3c e8 RSP: 0018:ffff88810695fd30 EFLAGS: 00010202 RAX: dffffc0000000000 RBX: ffffffffa0270268 RCX: 0000000000000000 RDX: 0000000000000002 RSI: 0000000000000004 RDI: 0000000000000010 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffed10233a4ef1 R10: ffff888119d2778b R11: 0000000063666572 R12: 0000000000000000 R13: fffffbfff404e2d4 R14: dffffc0000000000 R15: ffffffffa0271660 FS: 00007fbc81981540(0000) GS:ffff888119d00000(000 —truncated— 2024-03-02 not yet calculated CVE-2023-52570
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: power: supply: rk817: Fix node refcount leak Dan Carpenter reports that the Smatch static checker warning has found that there is another refcount leak in the probe function. While of_node_put() was added in one of the return paths, it should in fact be added for ALL return paths that return an error and at driver removal time. 2024-03-02 not yet calculated CVE-2023-52571
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: cifs: Fix UAF in cifs_demultiplex_thread() There is a UAF when xfstests on cifs: BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160 Read of size 4 at addr ffff88810103fc08 by task cifsd/923 CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45 … Call Trace: <TASK> dump_stack_lvl+0x34/0x44 print_report+0x171/0x472 kasan_report+0xad/0x130 kasan_check_range+0x145/0x1a0 smb2_is_network_name_deleted+0x27/0x160 cifs_demultiplex_thread.cold+0x172/0x5a4 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 </TASK> Allocated by task 923: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 __kasan_slab_alloc+0x54/0x60 kmem_cache_alloc+0x147/0x320 mempool_alloc+0xe1/0x260 cifs_small_buf_get+0x24/0x60 allocate_buffers+0xa1/0x1c0 cifs_demultiplex_thread+0x199/0x10d0 kthread+0x165/0x1a0 ret_from_fork+0x1f/0x30 Freed by task 921: kasan_save_stack+0x1e/0x40 kasan_set_track+0x21/0x30 kasan_save_free_info+0x2a/0x40 ____kasan_slab_free+0x143/0x1b0 kmem_cache_free+0xe3/0x4d0 cifs_small_buf_release+0x29/0x90 SMB2_negotiate+0x8b7/0x1c60 smb2_negotiate+0x51/0x70 cifs_negotiate_protocol+0xf0/0x160 cifs_get_smb_ses+0x5fa/0x13c0 mount_get_conns+0x7a/0x750 cifs_mount+0x103/0xd00 cifs_smb3_do_mount+0x1dd/0xcb0 smb3_get_tree+0x1d5/0x300 vfs_get_tree+0x41/0xf0 path_mount+0x9b3/0xdd0 __x64_sys_mount+0x190/0x1d0 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 The UAF is because: mount(pid: 921) | cifsd(pid: 923) ——————————-|——————————- | cifs_demultiplex_thread SMB2_negotiate | cifs_send_recv | compound_send_recv | smb_send_rqst | wait_for_response | wait_event_state [1] | | standard_receive3 | cifs_handle_standard | handle_mid | mid->resp_buf = buf; [2] | dequeue_mid [3] KILL the process [4] | resp_iov[i].iov_base = buf | free_rsp_buf [5] | | is_network_name_deleted [6] | callback 1. After send request to server, wait the response until mid->mid_state != SUBMITTED; 2. Receive response from server, and set it to mid; 3. Set the mid state to RECEIVED; 4. Kill the process, the mid state already RECEIVED, get 0; 5. Handle and release the negotiate response; 6. UAF. It can be easily reproduce with add some delay in [3] – [6]. Only sync call has the problem since async call’s callback is executed in cifsd process. Add an extra state to mark the mid state to READY before wakeup the waitter, then it can get the resp safely. 2024-03-02 not yet calculated CVE-2023-52572
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: rds: Fix possible NULL-pointer dereference In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists before dereferencing it as rdma_set_service_type() argument Found by Linux Verification Center (linuxtesting.org) with SVACE. 2024-03-02 not yet calculated CVE-2023-52573
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: team: fix null-ptr-deref when team device type is changed Get a null-ptr-deref bug as follows with reproducer [1]. BUG: kernel NULL pointer dereference, address: 0000000000000228 … RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q] … Call Trace: <TASK> ? __die+0x24/0x70 ? page_fault_oops+0x82/0x150 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x26/0x30 ? vlan_dev_hard_header+0x35/0x140 [8021q] ? vlan_dev_hard_header+0x8e/0x140 [8021q] neigh_connected_output+0xb2/0x100 ip6_finish_output2+0x1cb/0x520 ? nf_hook_slow+0x43/0xc0 ? ip6_mtu+0x46/0x80 ip6_finish_output+0x2a/0xb0 mld_sendpack+0x18f/0x250 mld_ifc_work+0x39/0x160 process_one_work+0x1e6/0x3f0 worker_thread+0x4d/0x2f0 ? __pfx_worker_thread+0x10/0x10 kthread+0xe5/0x120 ? __pfx_kthread+0x10/0x10 ret_from_fork+0x34/0x50 ? __pfx_kthread+0x10/0x10 ret_from_fork_asm+0x1b/0x30 [1] $ teamd -t team0 -d -c ‘{“runner”: {“name”: “loadbalance”}}’ $ ip link add name t-dummy type dummy $ ip link add link t-dummy name t-dummy.100 type vlan id 100 $ ip link add name t-nlmon type nlmon $ ip link set t-nlmon master team0 $ ip link set t-nlmon nomaster $ ip link set t-dummy up $ ip link set team0 up $ ip link set t-dummy.100 down $ ip link set t-dummy.100 master team0 When enslave a vlan device to team device and team device type is changed from non-ether to ether, header_ops of team device is changed to vlan_header_ops. That is incorrect and will trigger null-ptr-deref for vlan->real_dev in vlan_dev_hard_header() because team device is not a vlan device. Cache eth_header_ops in team_setup(), then assign cached header_ops to header_ops of team net device when its type is changed from non-ether to ether to fix the bug. 2024-03-02 not yet calculated CVE-2023-52574
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: x86/srso: Fix SBPB enablement for spec_rstack_overflow=off If the user has requested no SRSO mitigation, other mitigations can use the lighter-weight SBPB instead of IBPB. 2024-03-02 not yet calculated CVE-2023-52575
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: x86/mm, kexec, ima: Use memblock_free_late() from ima_free_kexec_buffer() The code calling ima_free_kexec_buffer() runs long after the memblock allocator has already been torn down, potentially resulting in a use after free in memblock_isolate_range(). With KASAN or KFENCE, this use after free will result in a BUG from the idle task, and a subsequent kernel panic. Switch ima_free_kexec_buffer() over to memblock_free_late() to avoid that bug. 2024-03-02 not yet calculated CVE-2023-52576
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: dccp: fix dccp_v4_err()/dccp_v6_err() again dh->dccph_x is the 9th byte (offset 8) in “struct dccp_hdr”, not in the “byte 7” as Jann claimed. We need to make sure the ICMP messages are big enough, using more standard ways (no more assumptions). syzbot reported: BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2667 [inline] BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2681 [inline] BUG: KMSAN: uninit-value in dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94 pskb_may_pull_reason include/linux/skbuff.h:2667 [inline] pskb_may_pull include/linux/skbuff.h:2681 [inline] dccp_v6_err+0x426/0x1aa0 net/dccp/ipv6.c:94 icmpv6_notify+0x4c7/0x880 net/ipv6/icmp.c:867 icmpv6_rcv+0x19d5/0x30d0 ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438 ip6_input_finish net/ipv6/ip6_input.c:483 [inline] NF_HOOK include/linux/netfilter.h:304 [inline] ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492 ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586 dst_input include/net/dst.h:468 [inline] ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79 NF_HOOK include/linux/netfilter.h:304 [inline] ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310 __netif_receive_skb_one_core net/core/dev.c:5523 [inline] __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637 netif_receive_skb_internal net/core/dev.c:5723 [inline] netif_receive_skb+0x58/0x660 net/core/dev.c:5782 tun_rx_batched+0x83b/0x920 tun_get_user+0x564c/0x6940 drivers/net/tun.c:2002 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:1985 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x15c0 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd Uninit was created at: slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767 slab_alloc_node mm/slub.c:3478 [inline] kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559 __alloc_skb+0x318/0x740 net/core/skbuff.c:650 alloc_skb include/linux/skbuff.h:1286 [inline] alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6313 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2795 tun_alloc_skb drivers/net/tun.c:1531 [inline] tun_get_user+0x23cf/0x6940 drivers/net/tun.c:1846 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048 call_write_iter include/linux/fs.h:1985 [inline] new_sync_write fs/read_write.c:491 [inline] vfs_write+0x8ef/0x15c0 fs/read_write.c:584 ksys_write+0x20f/0x4c0 fs/read_write.c:637 __do_sys_write fs/read_write.c:649 [inline] __se_sys_write fs/read_write.c:646 [inline] __x64_sys_write+0x93/0xd0 fs/read_write.c:646 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd CPU: 0 PID: 4995 Comm: syz-executor153 Not tainted 6.6.0-rc1-syzkaller-00014-ga747acc0b752 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023 2024-03-02 not yet calculated CVE-2023-52577
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: bridge: use DEV_STATS_INC() syzbot/KCSAN reported data-races in br_handle_frame_finish() [1] This function can run from multiple cpus without mutual exclusion. Adopt SMP safe DEV_STATS_INC() to update dev->stats fields. Handles updates to dev->stats.tx_dropped while we are at it. [1] BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 NF_HOOK include/linux/netfilter.h:304 [inline] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline] nf_hook_bridge_pre net/bridge/br_input.c:272 [inline] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417 __netif_receive_skb_one_core net/core/dev.c:5521 [inline] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_poll net/core/dev.c:6594 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 run_ksoftirqd+0x17/0x20 kernel/softirq.c:921 smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0: br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189 br_nf_hook_thresh+0x1ed/0x220 br_nf_pre_routing_finish_ipv6+0x50f/0x540 NF_HOOK include/linux/netfilter.h:304 [inline] br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178 br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508 nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline] nf_hook_bridge_pre net/bridge/br_input.c:272 [inline] br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417 __netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417 __netif_receive_skb_one_core net/core/dev.c:5521 [inline] __netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637 process_backlog+0x21f/0x380 net/core/dev.c:5965 __napi_poll+0x60/0x3b0 net/core/dev.c:6527 napi_poll net/core/dev.c:6594 [inline] net_rx_action+0x32b/0x750 net/core/dev.c:6727 __do_softirq+0xc1/0x265 kernel/softirq.c:553 do_softirq+0x5e/0x90 kernel/softirq.c:454 __local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381 __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline] _raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210 spin_unlock_bh include/linux/spinlock.h:396 [inline] batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356 batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560 process_one_work kernel/workqueue.c:2630 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703 worker_thread+0x525/0x730 kernel/workqueue.c:2784 kthread+0x1d7/0x210 kernel/kthread.c:388 ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304 value changed: 0x00000000000d7190 -> 0x00000000000d7191 Reported by Kernel Concurrency Sanitizer on: CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0 2024-03-02 not yet calculated CVE-2023-52578
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ipv4: fix null-deref in ipv4_link_failure Currently, we assume the skb is associated with a device before calling __ip_options_compile, which is not always the case if it is re-routed by ipvs. When skb->dev is NULL, dev_net(skb->dev) will become null-dereference. This patch adds a check for the edge case and switch to use the net_device from the rtable when skb->dev is NULL. 2024-03-02 not yet calculated CVE-2023-52579
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net/core: Fix ETH_P_1588 flow dissector When a PTP ethernet raw frame with a size of more than 256 bytes followed by a 0xff pattern is sent to __skb_flow_dissect, nhoff value calculation is wrong. For example: hdr->message_length takes the wrong value (0xffff) and it does not replicate real header length. In this case, ‘nhoff’ value was overridden and the PTP header was badly dissected. This leads to a kernel crash. net/core: flow_dissector net/core flow dissector nhoff = 0x0000000e net/core flow dissector hdr->message_length = 0x0000ffff net/core flow dissector nhoff = 0x0001000d (u16 overflow) … skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 skb frag: 00000000: f7 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Using the size of the ptp_header struct will allow the corrected calculation of the nhoff value. net/core flow dissector nhoff = 0x0000000e net/core flow dissector nhoff = 0x00000030 (sizeof ptp_header) … skb linear: 00000000: 00 a0 c9 00 00 00 00 a0 c9 00 00 00 88 f7 ff ff skb linear: 00000010: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb linear: 00000020: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff skb frag: 00000000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Kernel trace: [ 74.984279] ————[ cut here ]———— [ 74.989471] kernel BUG at include/linux/skbuff.h:2440! [ 74.995237] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI [ 75.001098] CPU: 4 PID: 0 Comm: swapper/4 Tainted: G U 5.15.85-intel-ese-standard-lts #1 [ 75.011629] Hardware name: Intel Corporation A-Island (CPU:AlderLake)/A-Island (ID:06), BIOS SB_ADLP.01.01.00.01.03.008.D-6A9D9E73-dirty Mar 30 2023 [ 75.026507] RIP: 0010:eth_type_trans+0xd0/0x130 [ 75.031594] Code: 03 88 47 78 eb c7 8b 47 68 2b 47 6c 48 8b 97 c0 00 00 00 83 f8 01 7e 1b 48 85 d2 74 06 66 83 3a ff 74 09 b8 00 04 00 00 eb ab <0f> 0b b8 00 01 00 00 eb a2 48 85 ff 74 eb 48 8d 54 24 06 31 f6 b9 [ 75.052612] RSP: 0018:ffff9948c0228de0 EFLAGS: 00010297 [ 75.058473] RAX: 00000000000003f2 RBX: ffff8e47047dc300 RCX: 0000000000001003 [ 75.066462] RDX: ffff8e4e8c9ea040 RSI: ffff8e4704e0a000 RDI: ffff8e47047dc300 [ 75.074458] RBP: ffff8e4704e2acc0 R08: 00000000000003f3 R09: 0000000000000800 [ 75.082466] R10: 000000000000000d R11: ffff9948c0228dec R12: ffff8e4715e4e010 [ 75.090461] R13: ffff9948c0545018 R14: 0000000000000001 R15: 0000000000000800 [ 75.098464] FS: 0000000000000000(0000) GS:ffff8e4e8fb00000(0000) knlGS:0000000000000000 [ 75.107530] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 75.113982] CR2: 00007f5eb35934a0 CR3: 0000000150e0a002 CR4: 0000000000770ee0 [ 75.121980] PKRU: 55555554 [ 75.125035] Call Trace: [ 75.127792] <IRQ> [ 75.130063] ? eth_get_headlen+0xa4/0xc0 [ 75.134472] igc_process_skb_fields+0xcd/0x150 [ 75.139461] igc_poll+0xc80/0x17b0 [ 75.143272] __napi_poll+0x27/0x170 [ 75.147192] net_rx_action+0x234/0x280 [ 75.151409] __do_softirq+0xef/0x2f4 [ 75.155424] irq_exit_rcu+0xc7/0x110 [ 75.159432] common_interrupt+0xb8/0xd0 [ 75.163748] </IRQ> [ 75.166112] <TASK> [ 75.168473] asm_common_interrupt+0x22/0x40 [ 75.173175] RIP: 0010:cpuidle_enter_state+0xe2/0x350 [ 75.178749] Code: 85 c0 0f 8f 04 02 00 00 31 ff e8 39 6c 67 ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 50 02 00 00 31 ff e8 52 b0 6d ff fb 45 85 f6 <0f> 88 b1 00 00 00 49 63 ce 4c 2b 2c 24 48 89 c8 48 6b d1 68 48 c1 [ 75.199757] RSP: 0018:ffff9948c013bea8 EFLAGS: 00000202 [ 75.205614] RAX: ffff8e4e8fb00000 RBX: ffffb948bfd23900 RCX: 000000000000001f [ 75.213619] RDX: 0000000000000004 RSI: ffffffff94206161 RDI: ffffffff94212e20 [ 75.221620] RBP: 0000000000000004 R08: 000000117568973a R09: 0000000000000001 [ 75.229622] R10: 000000000000afc8 R11: ffff8e4e8fb29ce4 R12: ffffffff945ae980 [ 75.237628] R13: 000000117568973a R14: 0000000000000004 R15: 0000000000000000 [ 75.245635] ? —truncated— 2024-03-02 not yet calculated CVE-2023-52580
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: netfilter: nf_tables: fix memleak when more than 255 elements expired When more than 255 elements expired we’re supposed to switch to a new gc container structure. This never happens: u8 type will wrap before reaching the boundary and nft_trans_gc_space() always returns true. This means we recycle the initial gc container structure and lose track of the elements that came before. While at it, don’t deref ‘gc’ after we’ve passed it to call_rcu. 2024-03-02 not yet calculated CVE-2023-52581
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: netfs: Only call folio_start_fscache() one time for each folio If a network filesystem using netfs implements a clamp_length() function, it can set subrequest lengths smaller than a page size. When we loop through the folios in netfs_rreq_unlock_folios() to set any folios to be written back, we need to make sure we only call folio_start_fscache() once for each folio. Otherwise, this simple testcase: mount -o fsc,rsize=1024,wsize=1024 127.0.0.1:/export /mnt/nfs dd if=/dev/zero of=/mnt/nfs/file.bin bs=4096 count=1 1+0 records in 1+0 records out 4096 bytes (4.1 kB, 4.0 KiB) copied, 0.0126359 s, 324 kB/s echo 3 > /proc/sys/vm/drop_caches cat /mnt/nfs/file.bin > /dev/null will trigger an oops similar to the following: page dumped because: VM_BUG_ON_FOLIO(folio_test_private_2(folio)) ————[ cut here ]———— kernel BUG at include/linux/netfs.h:44! … CPU: 5 PID: 134 Comm: kworker/u16:5 Kdump: loaded Not tainted 6.4.0-rc5 … RIP: 0010:netfs_rreq_unlock_folios+0x68e/0x730 [netfs] … Call Trace: netfs_rreq_assess+0x497/0x660 [netfs] netfs_subreq_terminated+0x32b/0x610 [netfs] nfs_netfs_read_completion+0x14e/0x1a0 [nfs] nfs_read_completion+0x2f9/0x330 [nfs] rpc_free_task+0x72/0xa0 [sunrpc] rpc_async_release+0x46/0x70 [sunrpc] process_one_work+0x3bd/0x710 worker_thread+0x89/0x610 kthread+0x181/0x1c0 ret_from_fork+0x29/0x50 2024-03-02 not yet calculated CVE-2023-52582
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 openvpn — openvpn_3_core_library
  The PKCS#7 parser in OpenVPN 3 Core Library versions through 3.8.3 did not properly validate the parsed data, which would result in the application crashing. 2024-02-29 not yet calculated CVE-2023-6247
security@openvpn.net unknown — wp_jobsearch
  The WP JobSearch WordPress plugin before 2.3.4 does not prevent attackers from logging-in as any users with the only knowledge of that user’s email address. 2024-02-27 not yet calculated CVE-2023-6584
contact@wpscan.com

unknown — wp_jobsearch

The WP JobSearch WordPress plugin before 2.3.4 does not validate files to be uploaded, which could allow unauthenticated attackers to upload arbitrary files such as PHP on the server 2024-02-27 not yet calculated CVE-2023-6585
contact@wpscan.com unknown — page_builder:_pagelayer
  The Page Builder: Pagelayer WordPress plugin before 1.8.1 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup) 2024-02-27 not yet calculated CVE-2023-7115
contact@wpscan.com unknown — jetbackup The JetBackup WordPress plugin before 2.0.9.9 doesn’t use index files to prevent public directory listing of sensitive directories in certain configurations, which allows malicious actors to leak backup files. 2024-02-27 not yet calculated CVE-2023-7165
contact@wpscan.com unknown — persian_fonts
  The Persian Fonts WordPress plugin through 1.6 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup). 2024-02-27 not yet calculated CVE-2023-7167
contact@wpscan.com unknown — wp_dashboard_notes
  The WP Dashboard Notes WordPress plugin before 1.0.11 is vulnerable to Insecure Direct Object References (IDOR) in post_id= parameter. Authenticated users are able to delete private notes associated with different user accounts. This poses a significant security risk as it violates the principle of least privilege and compromises the integrity and privacy of user data. 2024-02-27 not yet calculated CVE-2023-7198
contact@wpscan.com unknown — fatal_error_notify
  The Fatal Error Notify WordPress plugin before 1.5.3 does not have authorisation and CSRF checks in its test_error AJAX action, allowing any authenticated users, such as subscriber to call it and spam the admin email address with error messages. The issue is also exploitable via CSRF 2024-02-27 not yet calculated CVE-2023-7202
contact@wpscan.com
contact@wpscan.com unknown — smart_forms The Smart Forms WordPress plugin before 2.6.87 does not have authorisation in various AJAX actions, which could allow users with a role as low as subscriber to call them and perform unauthorised actions such as deleting entries. The plugin also lacks CSRF checks in some places which could allow attackers to make logged in users perform unwanted actions via CSRF attacks such as deleting entries. 2024-02-27 not yet calculated CVE-2023-7203
contact@wpscan.com langchain-ai — langchain-ai/langchain
  With the following crawler configuration: “`python from bs4 import BeautifulSoup as Soup url = “https://example.com” loader = RecursiveUrlLoader( url=url, max_depth=2, extractor=lambda x: Soup(x, “html.parser”).text ) docs = loader.load() “` An attacker in control of the contents of `https://example.com` could place a malicious HTML file in there with links like “https://example.completely.different/my_file.html” and the crawler would proceed to download that file as well even though `prevent_outside=True`. https://github.com/langchain-ai/langchain/blob/bf0b3cc0b5ade1fb95a5b1b6fa260e99064c2e22/libs/community/langchain_community/document_loaders/recursive_url_loader.py#L51-L51 Resolved in https://github.com/langchain-ai/langchain/pull/15559 2024-02-26 not yet calculated CVE-2024-0243
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  User can send a chat that contains an XSS opportunity that will then run when the chat is sent and on subsequent page loads. Given the minimum requirement for a user to send a chat is to be given access to a workspace via an admin the risk is low. Additionally, the location in which the XSS renders is only limited to the user who submits the XSS. Ultimately, this attack is limited to the user attacking themselves. There is no anonymous chat submission unless the user does not take the minimum steps required to protect their instance. 2024-02-26 not yet calculated CVE-2024-0435
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  Theoretically, it would be possible for an attacker to brute-force the password for an instance in single-user password protection mode via a timing attack given the linear nature of the `!==` used for comparison. The risk is minified by the additional overhead of the request, which varies in a non-constant nature making the attack less reliable to execute 2024-02-26 not yet calculated CVE-2024-0436
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  As a manager, you should not be able to modify a series of settings. In the UI this is indeed hidden as a convenience for the role since most managers would not be savvy enough to modify these settings. They can use their token to still modify those settings though through a standard HTTP request While this is not a critical vulnerability, it does indeed need to be patched to enforce the expected permission level. 2024-02-26 not yet calculated CVE-2024-0439
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  Attacker, with permission to submit a link or submits a link via POST to be collected that is using the file:// protocol can then introspect host files and other relatively stored files. 2024-02-26 not yet calculated CVE-2024-0440
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  The inclusion of the web scraper for AnythingLLM means that any user with the proper authorization level (manager, admin, and when in single user) could put in the URL “` http://169.254.169.254/latest/meta-data/identity-credentials/ec2/security-credentials/ec2-instance “` which is a special IP and URL that resolves only when the request comes from within an EC2 instance. This would allow the user to see the connection/secret credentials for their specific instance and be able to manage it regardless of who deployed it. The user would have to have pre-existing knowledge of the hosting infra which the target instance is deployed on, but if sent – would resolve if on EC2 and the proper `iptable` or firewall rule is not configured for their setup. 2024-02-26 not yet calculated CVE-2024-0455
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  A user who is privileged already `manager` or `admin` can set their profile picture via the frontend API using a relative filepath to then user the PFP GET API to download any valid files. The attacker would have to have been granted privileged permissions to the system before executing this attack. 2024-02-28 not yet calculated CVE-2024-0550
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  Enable exports of the database and associated exported information of the system via the default user role. The attacked would have to have been granted access to the system prior to the attack. It is worth noting that the deterministic nature of the export name is lower risk as the UI for exporting would start the download at the same time, which once downloaded – deletes the export from the system. The endpoint for exporting should simply be patched to a higher privilege level. 2024-02-27 not yet calculated CVE-2024-0551
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  Should an instance of AnythingLLM be hosted on an internal network and the attacked be explicitly granted a permission level of manager or admin, they could link-scrape internally resolving IPs of other services that are on the same network as AnythingLLM. This would require the attacker also be able to guess these internal IPs as `/*` ranging is not possible, but could be brute forced. There is a duty of care that other services on the same network would not be fully open and accessible via a simple CuRL with zero authentication as it is not possible to set headers or access via the link collector. 2024-02-27 not yet calculated CVE-2024-0759
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  Any user can delete an arbitrary folder (recursively) on a remote server due to bad input sanitization leading to path traversal. The attacker would need access to the server at some privilege level since this endpoint is protected and requires authorization. 2024-02-27 not yet calculated CVE-2024-0763
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  If an attacked was given access to an instance with the admin or manager role there is no backend authentication that would prevent the attacked from creating a new user with an `admin` role and then be able to use this new account to have elevated privileges on the instance 2024-03-02 not yet calculated CVE-2024-0795
security@huntr.dev
security@huntr.dev mintplex-labs — mintplex-labs/anything-llm
  A user with a `default` role given to them by the admin can sent `DELETE` HTTP requests to `remove-folder` and `remove-document` to delete folders and source files from the instance even when their role should explicitly not allow this action on the system. 2024-02-26 not yet calculated CVE-2024-0798
security@huntr.dev
security@huntr.dev unknown — spiffy_calendar
  The Spiffy Calendar WordPress plugin before 4.9.9 doesn’t check the event_author parameter, and allows any user to alter it when creating an event, leading to deceiving users/admins that a page was created by a Contributor+. 2024-02-27 not yet calculated CVE-2024-0855
contact@wpscan.com leo_khoa — laragon
  Enabling Simple Ajax Uploader plugin included in Laragon open-source software allows for a remote code execution (RCE) attack via an improper input validation in a file_upload.php file which serves as an example. By default, Laragon is not vulnerable until a user decides to use the aforementioned plugin. 2024-02-29 not yet calculated CVE-2024-0864
cvd@cert.pl
cvd@cert.pl
cvd@cert.pl langchain-ai — langchain-ai/chat-langchain
  Cross-site Scripting (XSS) – DOM in GitHub repository langchain-ai/chat-langchain prior to 0.0.0. 2024-03-02 not yet calculated CVE-2024-0968
security@huntr.dev
security@huntr.dev unknown — shariff_wrapper
  The Shariff Wrapper WordPress plugin before 4.6.10 does not sanitise and escape some of its settings, which could allow high privilege users such as admin to perform Stored Cross-Site Scripting attacks even when the unfiltered_html capability is disallowed (for example in multisite setup) 2024-02-27 not yet calculated CVE-2024-1106
contact@wpscan.com hp_inc. — hp_thinpro_8.0
  Previous versions of HP ThinPro (prior to HP ThinPro 8.0 SP 8) could potentially contain security vulnerabilities. HP has released HP ThinPro 8.0 SP 8, which includes updates to mitigate potential vulnerabilities. 2024-03-01 not yet calculated CVE-2024-1174
hp-security-alert@hp.com hp_inc. — hp_designjet
  Certain HP DesignJet print products are potentially vulnerable to information disclosure related to accessing memory out-of-bounds when using the general-purpose gateway (GGW) over port 9220. 2024-03-01 not yet calculated CVE-2024-1869
hp-security-alert@hp.com scrapy — scrapy/scrapy
  Parts of the Scrapy API were found to be vulnerable to a ReDoS attack. Handling a malicious response could cause extreme CPU and memory usage during the parsing of its content, due to the use of vulnerable regular expressions for that parsing. 2024-02-28 not yet calculated CVE-2024-1892
security@huntr.dev
security@huntr.dev freescout-helpdesk — freescout-helpdesk/freescout
  Unrestricted Upload of File with Dangerous Type in freescout-helpdesk/freescout 2024-02-28 not yet calculated CVE-2024-1932
security@huntr.dev google — chrome
  Type Confusion in V8 in Google Chrome prior to 122.0.6261.94 allowed a remote attacker to potentially exploit object corruption via a crafted HTML page. (Chromium security severity: High) 2024-02-29 not yet calculated CVE-2024-1938
chrome-cve-admin@google.com
chrome-cve-admin@google.com
chrome-cve-admin@google.com google — chrome
  Type Confusion in V8 in Google Chrome prior to 122.0.6261.94 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High) 2024-02-29 not yet calculated CVE-2024-1939
chrome-cve-admin@google.com
chrome-cve-admin@google.com
chrome-cve-admin@google.com joomla!_project — joomla!_cms
  The MFA management features did not properly terminate existing user sessions when a user’s MFA methods have been modified. 2024-02-29 not yet calculated CVE-2024-21722
security@joomla.org joomla!_project — joomla!_cms
  Inadequate parsing of URLs could result into an open redirect. 2024-02-29 not yet calculated CVE-2024-21723
security@joomla.org joomla!_project — joomla!_cms
  Inadequate input validation for media selection fields lead to XSS vulnerabilities in various extensions. 2024-02-29 not yet calculated CVE-2024-21724
security@joomla.org joomla!_project — joomla!_cms
  Inadequate escaping of mail addresses lead to XSS vulnerabilities in various components. 2024-02-29 not yet calculated CVE-2024-21725
security@joomla.org joomla!_project — joomla!_cms
  Inadequate content filtering leads to XSS vulnerabilities in various components. 2024-02-29 not yet calculated CVE-2024-21726
security@joomla.org apache_software_foundation — apache_james_mime4j
  Improper input validation allows for header injection in MIME4J library when using MIME4J DOM for composing message. This can be exploited by an attacker to add unintended headers to MIME messages. 2024-02-27 not yet calculated CVE-2024-21742
security@apache.org
security@apache.org elecom_co.,ltd. — wrc-1167gs2-b
  ELECOM wireless LAN routers contain a cross-site scripting vulnerability. Assume that a malicious administrative user configures the affected product with specially crafted content. When another administrative user logs in and operates the product, an arbitrary script may be executed on the web browser. Affected products and versions are as follows: WRC-1167GS2-B v1.67 and earlier, WRC-1167GS2H-B v1.67 and earlier, WRC-2533GS2-B v1.62 and earlier, WRC-2533GS2-W v1.62 and earlier, and WRC-2533GS2V-B v1.62 and earlier. 2024-02-28 not yet calculated CVE-2024-21798
vultures@jpcert.or.jp
vultures@jpcert.or.jp N/A — N/A
  Buffer Overflow vulnerability in XNSoft NConvert 7.163 (for Windows x86) allows attackers to cause a denial of service via crafted xwd file. 2024-02-28 not yet calculated CVE-2024-22532
cve@mitre.org N/A — N/A
  An issue was discovered in Linksys Router E1700 1.0.04 (build 3), allows authenticated attackers to escalate privileges via a crafted GET request to the /goform/* URI or via the ExportSettings function. 2024-02-27 not yet calculated CVE-2024-22543
cve@mitre.org N/A — N/A
  An issue was discovered in Linksys Router E1700 version 1.0.04 (build 3), allows authenticated attackers to execute arbitrary code via the setDateTime function. 2024-02-27 not yet calculated CVE-2024-22544
cve@mitre.org N/A — N/A
  Webtrees 2.1.18 is vulnerable to Directory Traversal. By manipulating the “media_folder” parameter in the URL, an attacker (in this case, an administrator) can navigate beyond the intended directory (the ‘media/’ directory) to access sensitive files in other parts of the application’s file system. 2024-02-28 not yet calculated CVE-2024-22723
cve@mitre.org miguel_ribeiro — wallos
  Wallos 0.9 is vulnerable to Cross Site Scripting (XSS) in all text-based input fields without proper validation, excluding those requiring specific formats like date fields. 2024-02-23 not yet calculated CVE-2024-22776
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue in Clojure versions 1.20 to 1.12.0-alpha5 allows an attacker to cause a denial of service (DoS) via the clojure.core$partial$fn__5920 function. 2024-02-29 not yet calculated CVE-2024-22871
cve@mitre.org N/A — N/A
  Tencent Blueking CMDB v3.2.x to v3.9.x was discovered to contain a Server-Side Request Forgery (SSRF) via the event subscription function (/service/subscription.go). This vulnerability allows attackers to access internal requests via a crafted POST request. 2024-02-26 not yet calculated CVE-2024-22873
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  Nteract v.0.28.0 was discovered to contain a remote code execution (RCE) vulnerability via the Markdown link. 2024-03-01 not yet calculated CVE-2024-22891
cve@mitre.org N/A — N/A
  SQL injection vulnerability in Dynamic Lab Management System Project in PHP v.1.0 allows a remote attacker to execute arbitrary code via a crafted script. 2024-02-27 not yet calculated CVE-2024-22917
cve@mitre.org N/A — N/A
  Cross-site scripting (XSS) vulnerability in Parents & Student Portal in Genesis School Management Systems in Genesis AIMS Student Information Systems v.3053 allows remote attackers to inject arbitrary web script or HTML via the message parameter. 2024-02-29 not yet calculated CVE-2024-22936
cve@mitre.org
cve@mitre.org N/A — N/A
  Cross Site Request Forgery vulnerability in FlyCms v.1.0 allows a remote attacker to execute arbitrary code via the system/article/category_edit component. 2024-02-29 not yet calculated CVE-2024-22939
cve@mitre.org
cve@mitre.org N/A — N/A
  SQL injection vulnerability in Projectworlds Visitor Management System in PHP v.1.0 allows a remote attacker to escalate privileges via the name parameter in the myform.php endpoint. 2024-02-28 not yet calculated CVE-2024-22983
cve@mitre.org
cve@mitre.org
cve@mitre.org zkteco — zkbio_wdms
  An issue in zkteco zkbio WDMS v.8.0.5 allows an attacker to execute arbitrary code via the /files/backup/ component. 2024-02-23 not yet calculated CVE-2024-22988
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue in WuKongOpenSource WukongCRM v.72crm_9.0.1_20191202 allows a remote attacker to execute arbitrary code via the parseObject() function in the fastjson component. 2024-02-29 not yet calculated CVE-2024-23052
cve@mitre.org
cve@mitre.org N/A — N/A
  Couchbase Server before 7.2.4 has a private key leak in goxdcr.log. 2024-02-29 not yet calculated CVE-2024-23302
cve@mitre.org
cve@mitre.org
cve@mitre.org apache_software_foundation — apache_dolphinscheduler
  Improper Input Validation vulnerability in Apache DolphinScheduler. An authenticated user can cause arbitrary, unsandboxed javascript to be executed on the server. This issue is a legacy of CVE-2023-49299. We didn’t fix it completely in CVE-2023-49299, and we added one more patch to fix it. This issue affects Apache DolphinScheduler: until 3.2.1. Users are recommended to upgrade to version 3.2.1, which fixes the issue. 2024-02-23 not yet calculated CVE-2024-23320
security@apache.org
security@apache.org
security@apache.org
security@apache.org
security@apache.org apache_software_foundation — apache_xerces_c++ The Apache Xerces C++ XML parser on versions 3.0.0 before 3.2.5 contains a use-after-free error triggered during the scanning of external DTDs. Users are recommended to upgrade to version 3.2.5 which fixes the issue, or mitigate the issue by disabling DTD processing. This can be accomplished via the DOM using a standard parser feature, or via SAX using the XERCES_DISABLE_DTD environment variable. This issue has been disclosed before as CVE-2018-1311, but unfortunately that advisory incorrectly stated the issue would be fixed in version 3.2.3 or 3.2.4. 2024-02-29 not yet calculated CVE-2024-23807
security@apache.org
security@apache.org elecom_co.,ltd. — wrc-1167gs2-b
  Cross-site request forgery (CSRF) vulnerability in ELECOM wireless LAN routers allows a remote unauthenticated attacker to hijack the authentication of administrators and to perform unintended operations to the affected product. Affected products and versions are as follows: WRC-1167GS2-B v1.67 and earlier, WRC-1167GS2H-B v1.67 and earlier, WRC-2533GS2-B v1.62 and earlier, WRC-2533GS2-W v1.62 and earlier, and WRC-2533GS2V-B v1.62 and earlier. 2024-02-28 not yet calculated CVE-2024-23910
vultures@jpcert.or.jp
vultures@jpcert.or.jp apache_software_foundation — apache_ofbiz
  Possible path traversal in Apache OFBiz allowing file inclusion. Users are recommended to upgrade to version 18.12.12, that fixes the issue. 2024-02-29 not yet calculated CVE-2024-23946
security@apache.org
security@apache.org
security@apache.org
security@apache.org
security@apache.org
security@apache.org N/A — N/A
  SQL Injection vulnerability in Likeshop before 2.5.7 allows attackers to run abitrary SQL commands via the function DistributionMemberLogic::getFansLists. 2024-02-27 not yet calculated CVE-2024-24027
cve@mitre.org N/A — N/A
  Code-projects Simple Stock System 1.0 is vulnerable to SQL Injection. 2024-02-27 not yet calculated CVE-2024-24095
cve@mitre.org N/A — N/A
  Code-projects Computer Book Store 1.0 is vulnerable to SQL Injection via BookSBIN. 2024-02-27 not yet calculated CVE-2024-24096
cve@mitre.org N/A — N/A
  Code-projects Scholars Tracking System 1.0 is vulnerable to SQL Injection under Employment Status Information Update. 2024-02-27 not yet calculated CVE-2024-24099
cve@mitre.org N/A — N/A
  Code-projects Computer Book Store 1.0 is vulnerable to SQL Injection via PublisherID. 2024-02-27 not yet calculated CVE-2024-24100
cve@mitre.org N/A — N/A
  A memory leak issue discovered in parseSWF_DEFINEBUTTON in libming v0.4.8 allows attackers to cause s denial of service via a crafted SWF file. 2024-02-29 not yet calculated CVE-2024-24146
cve@mitre.org N/A — N/A
  A memory leak issue discovered in parseSWF_FILLSTYLEARRAY in libming v0.4.8 allows attackers to cause s denial of service via a crafted SWF file. 2024-02-29 not yet calculated CVE-2024-24147
cve@mitre.org N/A — N/A
  A memory leak issue discovered in parseSWF_FREECHARACTER in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file. 2024-02-28 not yet calculated CVE-2024-24148
cve@mitre.org N/A — N/A
  A memory leak issue discovered in parseSWF_GLYPHENTRY in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file. 2024-02-29 not yet calculated CVE-2024-24149
cve@mitre.org N/A — N/A
  A memory leak issue discovered in parseSWF_TEXTRECORD in libming v0.4.8 allows attackers to cause a denial of service via a crafted SWF file. 2024-02-29 not yet calculated CVE-2024-24150
cve@mitre.org N/A — N/A
  Bento4 v1.5.1-628 contains a Memory leak on AP4_Movie::AP4_Movie, parsing tracks and added into m_Tracks list, but mp42aac cannot correctly delete when we got an no audio track found error. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted mp4 file. 2024-02-29 not yet calculated CVE-2024-24155
cve@mitre.org N/A — N/A
  Heap Buffer Overflow vulnerability in qpdf 11.9.0 allows attackers to crash the application via the std::__shared_count() function at /bits/shared_ptr_base.h. 2024-02-29 not yet calculated CVE-2024-24246
cve@mitre.org prestashop — prestashop
  In the module “Survey TMA” (ecomiz_survey_tma) up to version 2.0.0 from Ecomiz for PrestaShop, a guest can download personal information without restriction. 2024-02-23 not yet calculated CVE-2024-24309
cve@mitre.org
cve@mitre.org prestashop — prestashop
  In the module “Generate barcode on invoice / delivery slip” (ecgeneratebarcode) from Ether Creation <= 1.2.0 for PrestaShop, a guest can perform SQL injection. 2024-02-23 not yet calculated CVE-2024-24310
cve@mitre.org
cve@mitre.org N/A — N/A
  SQL injection vulnerability in linlinjava litemall v.1.8.0 allows a remote attacker to obtain sensitive information via the nickname, consignee, orderSN, orderStatusArray parameters of the AdminOrdercontroller.java component. 2024-02-27 not yet calculated CVE-2024-24323
cve@mitre.org N/A — N/A
  SQL Injection vulnerability in Nagios XI 2024R1.01 allows a remote attacker to execute arbitrary code via a crafted payload to the monitoringwizard.php component. 2024-02-26 not yet calculated CVE-2024-24401
cve@mitre.org N/A — N/A
  An issue in Nagios XI 2024R1.01 allows a remote attacker to escalate privileges via a crafted script to the /usr/local/nagios/bin/npcd component. 2024-02-26 not yet calculated CVE-2024-24402
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in Pkp OJS v.3.4 allows an attacker to execute arbitrary code via the Input Title component. 2024-03-01 not yet calculated CVE-2024-24511
cve@mitre.org
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in Pkp OJS v.3.4 allows an attacker to execute arbitrary code via the input subtitle component. 2024-03-01 not yet calculated CVE-2024-24512
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue in EpointWebBuilder 5.1.0-sp1, 5.2.1-sp1, 5.4.1 and 5.4.2 allows a remote attacker to execute arbitrary code via the infoid parameter of the URL. 2024-02-29 not yet calculated CVE-2024-24525
cve@mitre.org N/A — N/A
  Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none. 2024-02-26 not yet calculated CVE-2024-24528 yealink — configuration_encrypt_tool
  Insecure AES key in Yealink Configuration Encrypt Tool below verrsion 1.2. A single, vendorwide, hardcoded AES key in the configuration tool used to encrypt provisioning documents was leaked leading to a compromise of confidentiality of provisioning documents. 2024-02-23 not yet calculated CVE-2024-24681
cve@mitre.org N/A — N/A
  An issue was discovered on Innovaphone PBX before 14r1 devices. It provides different responses to incoming requests in a way that reveals information to an attacker. 2024-02-27 not yet calculated CVE-2024-24720
cve@mitre.org N/A — N/A
  An issue was discovered on Innovaphone PBX before 14r1 devices. The password form, used to authenticate, allows a Brute Force Attack through which an attacker may be able to access the administration panel 2024-02-27 not yet calculated CVE-2024-24721
cve@mitre.org N/A — N/A
  XenForo before 2.2.14 allows Directory Traversal (with write access) by an authenticated user who has permissions to administer styles, and uses a ZIP archive for Styles Import. 2024-02-29 not yet calculated CVE-2024-25006
cve@mitre.org
cve@mitre.org
cve@mitre.org apache_software_foundation — apache_ofbiz
  Possible path traversal in Apache OFBiz allowing authentication bypass. Users are recommended to upgrade to version 18.12.12, that fixes the issue. 2024-02-29 not yet calculated CVE-2024-25065
security@apache.org
security@apache.org
security@apache.org
security@apache.org
security@apache.org
security@apache.org N/A — N/A
  Splinefont in FontForge through 20230101 allows command injection via crafted filenames. 2024-02-26 not yet calculated CVE-2024-25081
cve@mitre.org
cve@mitre.org N/A — N/A
  Splinefont in FontForge through 20230101 allows command injection via crafted archives or compressed files. 2024-02-26 not yet calculated CVE-2024-25082
cve@mitre.org
cve@mitre.org j’s_communications_co.,_ltd. — revoworks_scvx
  Protection mechanism failure issue exists in RevoWorks SCVX prior to scvimage4.10.21_1013 (when using ‘VirusChecker’ or ‘ThreatChecker’ feature) and RevoWorks Browser prior to 2.2.95 (when using ‘VirusChecker’ or ‘ThreatChecker’ feature). If data containing malware is saved in a specific file format (eml, dmg, vhd, iso, msi), malware may be taken outside the sandboxed environment. 2024-03-01 not yet calculated CVE-2024-25091
vultures@jpcert.or.jp
vultures@jpcert.or.jp N/A — N/A
  Cross Site Scripting vulnerability in 71CMS v.1.0.0 allows a remote attacker to execute arbitrary code via the uploadfile action parameter in the controller.php file. 2024-02-27 not yet calculated CVE-2024-25166
cve@mitre.org N/A — N/A
  An issue in Mezzanine v6.0.0 allows attackers to bypass access control mechanisms in the admin panel via a crafted request. 2024-02-28 not yet calculated CVE-2024-25169
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue in Mezzanine v6.0.0 allows attackers to bypass access controls via manipulating the Host header. 2024-02-28 not yet calculated CVE-2024-25170
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue discovered in pdfmake 0.2.9 allows remote attackers to run arbitrary code via crafted POST request to the path ‘/pdf’. 2024-02-29 not yet calculated CVE-2024-25180
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in Phpgurukul User Registration & Login and User Management System 1.0 allows attackers to run arbitrary code via the search bar. 2024-02-28 not yet calculated CVE-2024-25202
cve@mitre.org N/A — N/A
  SQL Injection vulnerability in /app/api/controller/Store.php in Niushop B2B2C V5 allows attackers to run arbitrary SQL commands via latitude and longitude parameters. 2024-02-26 not yet calculated CVE-2024-25247
cve@mitre.org N/A — N/A
  SQL Injection vulnerability in the orderGoodsDelivery() function in Niushop B2B2C V5 allows attackers to run arbitrary SQL commands via the order_id parameter. 2024-02-26 not yet calculated CVE-2024-25248
cve@mitre.org N/A — N/A
  texlive-bin commit c515e was discovered to contain heap buffer overflow via the function ttfLoadHDMX:ttfdump. This vulnerability allows attackers to cause a Denial of Service (DoS) via supplying a crafted TTF file. 2024-02-29 not yet calculated CVE-2024-25262
cve@mitre.org
cve@mitre.org N/A — N/A
  Deskfiler v1.2.3 allows attackers to execute arbitrary code via uploading a crafted plugin. 2024-02-29 not yet calculated CVE-2024-25291
cve@mitre.org N/A — N/A
  Cross-site scripting (XSS) vulnerability in RenderTune v1.1.4 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Upload Title parameter. 2024-02-29 not yet calculated CVE-2024-25292
cve@mitre.org N/A — N/A
  mjml-app versions 3.0.4 and 3.1.0-beta were discovered to contain a remote code execution (RCE) via the href attribute. 2024-03-01 not yet calculated CVE-2024-25293
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in ITFlow.org before commit v.432488eca3998c5be6b6b9e8f8ba01f54bc12378 allows a remtoe attacker to execute arbitrary code and obtain sensitive information via the settings.php, settings+company.php, settings_defaults.php,settings_integrations.php, settings_invoice.php, settings_localization.php, settings_mail.php components. 2024-02-26 not yet calculated CVE-2024-25344
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  SQL Injection vulnerability in /zms/admin/edit-ticket.php in PHPGurukul Zoo Management System 1.0 via tickettype and tprice parameters. 2024-02-28 not yet calculated CVE-2024-25350
cve@mitre.org N/A — N/A
  SQL Injection vulnerability in /zms/admin/changeimage.php in PHPGurukul Zoo Management System 1.0 allows attackers to run arbitrary SQL commands via the editid parameter. 2024-02-28 not yet calculated CVE-2024-25351
cve@mitre.org N/A — N/A
  Directory Traversal vulnerability in DICOM® Connectivity Framework by laurelbridge before v.2.7.6b allows a remote attacker to execute arbitrary code via the format_logfile.pl file. 2024-03-01 not yet calculated CVE-2024-25386
cve@mitre.org
cve@mitre.org N/A — N/A
  In Srelay (the SOCKS proxy and Relay) v.0.4.8p3, a specially crafted network payload can trigger a denial of service condition and disrupt the service. 2024-02-27 not yet calculated CVE-2024-25398
cve@mitre.org
cve@mitre.org N/A — N/A
  Subrion CMS 4.2.1 is vulnerable to Cross Site Scripting (XSS) via adminer.php. 2024-02-27 not yet calculated CVE-2024-25399
cve@mitre.org N/A — N/A
  Subrion CMS 4.2.1 is vulnerable to SQL Injection via ia.core.mysqli.php. 2024-02-27 not yet calculated CVE-2024-25400
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  flusity-CMS 2.33 is vulnerable to Unrestricted Upload of File with Dangerous Type in update_setting.php. 2024-02-26 not yet calculated CVE-2024-25410
cve@mitre.org N/A — N/A
  SQL Injection vulnerability in SEMCMS v.4.8 allows a remote attacker to execute arbitrary code and obtain sensitive information via the SEMCMS_Menu.php component. 2024-02-28 not yet calculated CVE-2024-25422
cve@mitre.org N/A — N/A
  A cross-site scripting (XSS) vulnerability in Pkp Ojs v3.3 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Publicname parameter. 2024-03-01 not yet calculated CVE-2024-25434
cve@mitre.org
cve@mitre.org N/A — N/A
  A cross-site scripting (XSS) vulnerability in Md1health Md1patient v2.0.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Msg parameter. 2024-02-28 not yet calculated CVE-2024-25435
cve@mitre.org N/A — N/A
  A cross-site scripting (XSS) vulnerability in the Production module of Pkp Ojs v3.3 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Input subject field under the Add Discussion function. 2024-03-01 not yet calculated CVE-2024-25436
cve@mitre.org
cve@mitre.org N/A — N/A
  A cross-site scripting (XSS) vulnerability in the Submission module of Pkp Ojs v3.3 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Input subject field under the Add Discussion function. 2024-03-01 not yet calculated CVE-2024-25438
cve@mitre.org
cve@mitre.org crmeb — crmeb
  SQL Injection vulnerability in CRMEB crmeb_java v.1.3.4 and before allows a remote attacker to obtain sensitive information via the latitude and longitude parameters in the api/front/store/list component. 2024-02-23 not yet calculated CVE-2024-25469
cve@mitre.org
cve@mitre.org N/A — N/A
  Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. 2024-03-01 not yet calculated CVE-2024-25553 N/A — N/A
  Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority. 2024-03-01 not yet calculated CVE-2024-25554 elecom_co.,ltd. — wrc-1167gs2-b
  OS command injection vulnerability in ELECOM wireless LAN routers allows a network-adjacent attacker with an administrative privilege to execute arbitrary OS commands by sending a specially crafted request to the product. Affected products and versions are as follows: WRC-1167GS2-B v1.67 and earlier, WRC-1167GS2H-B v1.67 and earlier, WRC-2533GS2-B v1.62 and earlier, WRC-2533GS2-W v1.62 and earlier, and WRC-2533GS2V-B v1.62 and earlier. 2024-02-28 not yet calculated CVE-2024-25579
vultures@jpcert.or.jp
vultures@jpcert.or.jp N/A — N/A
  diffoscope before 256 allows directory traversal via an embedded filename in a GPG file. Contents of any file, such as ../.ssh/id_rsa, may be disclosed to an attacker. This occurs because the value of the gpg –use-embedded-filenames option is trusted. 2024-02-27 not yet calculated CVE-2024-25711
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  http-swagger before 1.2.6 allows XSS via PUT requests, because a file that has been uploaded (via httpSwagger.WrapHandler and *webdav.memFile) can subsequently be accessed via a GET request. NOTE: this is independently fixable with respect to CVE-2022-24863, because (if a solution continued to allow PUT requests) large files could have been blocked without blocking JavaScript, or JavaScript could have been blocked without blocking large files. 2024-02-29 not yet calculated CVE-2024-25712
cve@mitre.org
cve@mitre.org N/A — N/A
  yyjson through 0.8.0 has a double free, leading to remote code execution in some cases, because the pool_free function lacks loop checks. (pool_free is part of the pool series allocator, along with pool_malloc and pool_realloc.) 2024-02-29 not yet calculated CVE-2024-25713
cve@mitre.org N/A — N/A
  ZenML Server in the ZenML machine learning package before 0.46.7 for Python allows remote privilege escalation because the /api/v1/users/{user_name_or_id}/activate REST API endpoint allows access on the basis of a valid username along with a new password in the request body. These are also patched versions: 0.44.4, 0.43.1, and 0.42.2. 2024-02-27 not yet calculated CVE-2024-25723
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org hitron — coda
  Hitron CODA-4582 and CODA-4589 devices have default PSKs that are generated from 5-digit hex values concatenated with a “Hitron” substring, resulting in insufficient entropy (only about one million possibilities). 2024-02-23 not yet calculated CVE-2024-25730
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  A Stack Based Buffer Overflow vulnerability in Tenda AC9 v.3.0 with firmware version v.15.03.06.42_multi allows a remote attacker to execute arbitrary code via the fromSetSysTime function. 2024-02-26 not yet calculated CVE-2024-25751
cve@mitre.org N/A — N/A
  openNDS 10.2.0 is vulnerable to Use-After-Free via /openNDS/src/auth.c. 2024-02-26 not yet calculated CVE-2024-25763
cve@mitre.org N/A — N/A
  nanomq 0.21.2 contains a Use-After-Free vulnerability in /nanomq/nng/src/core/socket.c. 2024-02-26 not yet calculated CVE-2024-25767
cve@mitre.org N/A — N/A
  OpenDMARC 1.4.2 contains a null pointer dereference vulnerability in /OpenDMARC/libopendmarc/opendmarc_policy.c. 2024-02-26 not yet calculated CVE-2024-25768
cve@mitre.org N/A — N/A
  libming 0.4.8 contains a memory leak vulnerability in /libming/src/actioncompiler/listaction.c. 2024-02-26 not yet calculated CVE-2024-25770
cve@mitre.org N/A — N/A
  F-logic DataCube3 v1.0 is vulnerable to Incorrect Access Control due to an improper directory access restriction. An unauthenticated, remote attacker can exploit this, by sending a URI that contains the path of the configuration file. A successful exploit could allow the attacker to extract the root and admin password. 2024-02-29 not yet calculated CVE-2024-25830
cve@mitre.org N/A — N/A
  F-logic DataCube3 Version 1.0 is affected by a reflected cross-site scripting (XSS) vulnerability due to improper input sanitization. An authenticated, remote attacker can execute arbitrary JavaScript code in the web management interface. 2024-02-29 not yet calculated CVE-2024-25831
cve@mitre.org N/A — N/A
  F-logic DataCube3 v1.0 is vulnerable to unrestricted file upload, which could allow an authenticated malicious actor to upload a file of dangerous type by manipulating the filename extension. 2024-02-29 not yet calculated CVE-2024-25832
cve@mitre.org N/A — N/A
  F-logic DataCube3 v1.0 is vulnerable to unauthenticated SQL injection, which could allow an unauthenticated malicious actor to execute arbitrary SQL queries in database. 2024-02-29 not yet calculated CVE-2024-25833
cve@mitre.org N/A — N/A
  In the module “Account Manager | Sales Representative & Dealers | CRM” (prestasalesmanager) up to 9.0 from Presta World for PrestaShop, a guest can download personal information without restriction by performing a path traversal attack. 2024-02-27 not yet calculated CVE-2024-25840
cve@mitre.org
cve@mitre.org N/A — N/A
  In the module “So Flexibilite” (soflexibilite) from Common-Services for PrestaShop < 4.1.26, a guest (authenticated customer) can perform Cross Site Scripting (XSS) injection. 2024-02-27 not yet calculated CVE-2024-25841
cve@mitre.org
cve@mitre.org N/A — N/A
  In the module “Import/Update Bulk Product from any Csv/Excel File Pro” (ba_importer) up to version 1.1.28 from Buy Addons for PrestaShop, a guest can perform SQL injection in affected versions. 2024-02-27 not yet calculated CVE-2024-25843
cve@mitre.org
cve@mitre.org N/A — N/A
  In the module “Product Catalog (CSV, Excel) Import” (simpleimportproduct) <= 6.7.0 from MyPrestaModules for PrestaShop, a guest can upload files with extensions .php. 2024-02-27 not yet calculated CVE-2024-25846
cve@mitre.org
cve@mitre.org N/A — N/A
  A path traversal vulnerability in the /path/to/uploads/ directory of Blesta before v5.9.2 allows attackers to takeover user accounts and execute arbitrary code. 2024-02-28 not yet calculated CVE-2024-25859
cve@mitre.org N/A — N/A
  Cross Site Scripting (XSS) vulnerability in hexo-theme-anzhiyu v1.6.12, allows remote attackers to execute arbitrary code via the algolia search function. 2024-03-02 not yet calculated CVE-2024-25865
cve@mitre.org N/A — N/A
  A SQL Injection vulnerability in CodeAstro Membership Management System in PHP v.1.0 allows a remote attacker to execute arbitrary SQL commands via the email parameter in the index.php component. 2024-02-28 not yet calculated CVE-2024-25866
cve@mitre.org N/A — N/A
  A SQL Injection vulnerability in CodeAstro Membership Management System in PHP v.1.0 allows a remote attacker to execute arbitrary SQL commands via the membershipType and membershipAmount parameters in the add_type.php component. 2024-02-28 not yet calculated CVE-2024-25867
cve@mitre.org N/A — N/A
  A Cross Site Scripting (XSS) vulnerability in CodeAstro Membership Management System in PHP v.1.0 allows a remote attacker to execute arbitrary code via the membershipType parameter in the add_type.php component. 2024-02-28 not yet calculated CVE-2024-25868
cve@mitre.org N/A — N/A
  An Unrestricted File Upload vulnerability in CodeAstro Membership Management System in PHP v.1.0 allows a remote attacker to execute arbitrary code via upload of a crafted php file in the settings.php component. 2024-02-28 not yet calculated CVE-2024-25869
cve@mitre.org zhejiang_uniview_technologies_co.,ltd_and_atsumi_electric_co.,_ltd. — oet-213h-bts1
  Initialization of a resource with an insecure default vulnerability in OET-213H-BTS1 sold in Japan by Atsumi Electric Co., Ltd. allows a network-adjacent unauthenticated attacker to configure and control the affected product. 2024-03-01 not yet calculated CVE-2024-25972
vultures@jpcert.or.jp
vultures@jpcert.or.jp
vultures@jpcert.or.jp apache_software_foundation — apache_airflow
  Apache Airflow, versions before 2.8.2, has a vulnerability that allows authenticated Ops and Viewers users to view all information on audit logs, including dag names and usernames they were not permitted to view. With 2.8.2 and newer, Ops and Viewer users do not have audit log permission by default, they need to be explicitly granted permissions to see the logs. Only admin users have audit log permission by default. Users of Apache Airflow are recommended to upgrade to version 2.8.2 or newer to mitigate the risk associated with this vulnerability 2024-03-01 not yet calculated CVE-2024-26280
security@apache.org
security@apache.org N/A — N/A
  A Null pointer dereference in usr/sbin/httpd in ASUS AC68U 3.0.0.4.384.82230 allows remote attackers to trigger DoS via network packet. 2024-02-28 not yet calculated CVE-2024-26342
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in Piwigo before v.14.2.0 allows a remote attacker to escalate privileges via the batch function on the admin page. 2024-02-28 not yet calculated CVE-2024-26450
cve@mitre.org N/A — N/A
  fluent-bit 2.2.2 contains a Use-After-Free vulnerability in /fluent-bit/plugins/custom_calyptia/calyptia.c. 2024-02-26 not yet calculated CVE-2024-26455
cve@mitre.org N/A — N/A
  Kerberos 5 (aka krb5) 1.21.2 contains a memory leak in /krb5/src/lib/rpc/pmap_rmt.c. 2024-02-29 not yet calculated CVE-2024-26458
cve@mitre.org N/A — N/A
  Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/lib/gssapi/krb5/k5sealv3.c. 2024-02-29 not yet calculated CVE-2024-26461
cve@mitre.org N/A — N/A
  Kerberos 5 (aka krb5) 1.21.2 contains a memory leak vulnerability in /krb5/src/kdc/ndr.c. 2024-02-29 not yet calculated CVE-2024-26462
cve@mitre.org N/A — N/A
  Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: none. Reason: This candidate was withdrawn by its CNA. Further investigation showed that it was not a security issue. Notes: none. 2024-02-27 not yet calculated CVE-2024-26464 N/A — N/A
  A DOM based cross-site scripting (XSS) vulnerability in the component /beep/Beep.Instrument.js of stewdio beep.js before commit ef22ad7 allows attackers to execute arbitrary Javascript via sending a crafted URL. 2024-02-26 not yet calculated CVE-2024-26465
cve@mitre.org N/A — N/A
  A DOM based cross-site scripting (XSS) vulnerability in the component /dom/ranges/Range-test-iframe.html of web-platform-tests/wpt before commit 938e843 allows attackers to execute arbitrary Javascript via sending a crafted URL. 2024-02-26 not yet calculated CVE-2024-26466
cve@mitre.org N/A — N/A
  A DOM based cross-site scripting (XSS) vulnerability in the component generator.html of tabatkins/railroad-diagrams before commit ea9a123 allows attackers to execute arbitrary Javascript via sending a crafted URL. 2024-02-26 not yet calculated CVE-2024-26467
cve@mitre.org N/A — N/A
  A DOM based cross-site scripting (XSS) vulnerability in the component index.html of jstrieb/urlpages before commit 035b647 allows attackers to execute arbitrary Javascript via sending a crafted URL. 2024-02-26 not yet calculated CVE-2024-26468
cve@mitre.org N/A — N/A
  A host header injection vulnerability in the forgot password function of FullStackHero’s WebAPI Boilerplate v1.0.0 and v1.0.1 allows attackers to leak the password reset token via a crafted request. 2024-02-29 not yet calculated CVE-2024-26470
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  A reflected cross-site scripting (XSS) vulnerability in zhimengzhe iBarn v1.5 allows attackers to inject malicious JavaScript into the web browser of a victim via the search parameter in offer.php. 2024-02-29 not yet calculated CVE-2024-26471
cve@mitre.org
cve@mitre.org N/A — N/A
  A reflected cross-site scripting (XSS) vulnerability in SocialMediaWebsite v1.0.1 allows attackers to inject malicious JavaScript into the web browser of a victim via the selector or validator parameters in offer.php. 2024-02-29 not yet calculated CVE-2024-26472
cve@mitre.org
cve@mitre.org N/A — N/A
  A reflected cross-site scripting (XSS) vulnerability in SocialMediaWebsite v1.0.1 allows attackers to inject malicious JavaScript into the web browser of a victim via the poll parameter in poll.php. 2024-02-29 not yet calculated CVE-2024-26473
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue in open-emr before v.7.0.2 allows a remote attacker to escalate privileges via a crafted script to the formid parameter in the ereq_form.php component. 2024-02-28 not yet calculated CVE-2024-26476
cve@mitre.org
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in Bonitasoft, S.A v.7.14. and fixed in v.9.0.2, 8.0.3, 7.15.7, 7.14.8 allows attackers to execute arbitrary code via a crafted payload to the Groups Display name field. 2024-02-27 not yet calculated CVE-2024-26542
cve@mitre.org N/A — N/A
  An issue in vivotek Network Camera v.FD8166A-VVTK-0204j allows a remote attacker to execute arbitrary code via a crafted payload to the upload_file.cgi component. 2024-02-29 not yet calculated CVE-2024-26548
cve@mitre.org N/A — N/A
  An issue in uverif v.2.0 allows a remote attacker to obtain sensitive information. 2024-02-28 not yet calculated CVE-2024-26559
cve@mitre.org linux — linux
  In the Linux kernel, the following vulnerability has been resolved: i2c: i801: Fix block process call transactions According to the Intel datasheets, software must reset the block buffer index twice for block process call transactions: once before writing the outgoing data to the buffer, and once again before reading the incoming data from the buffer. The driver is currently missing the second reset, causing the wrong portion of the block buffer to be read. 2024-02-23 not yet calculated CVE-2024-26593
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ksmbd: validate mech token in session setup If client send invalid mech token in session setup request, ksmbd validate and make the error if it is invalid. 2024-02-23 not yet calculated CVE-2024-26594
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after failing to attach the region to an ACL group, we hit a NULL pointer dereference upon ‘region->group->tcam’ [1]. Fix by retrieving the ‘tcam’ pointer using mlxsw_sp_acl_to_tcam(). [1] BUG: kernel NULL pointer dereference, address: 0000000000000000 […] RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0 […] Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b 2024-02-23 not yet calculated CVE-2024-26595
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: dsa: fix netdev_priv() dereference before check on non-DSA netdevice events After the blamed commit, we started doing this dereference for every NETDEV_CHANGEUPPER and NETDEV_PRECHANGEUPPER event in the system. static inline struct dsa_port *dsa_user_to_port(const struct net_device *dev) { struct dsa_user_priv *p = netdev_priv(dev); return p->dp; } Which is obviously bogus, because not all net_devices have a netdev_priv() of type struct dsa_user_priv. But struct dsa_user_priv is fairly small, and p->dp means dereferencing 8 bytes starting with offset 16. Most drivers allocate that much private memory anyway, making our access not fault, and we discard the bogus data quickly afterwards, so this wasn’t caught. But the dummy interface is somewhat special in that it calls alloc_netdev() with a priv size of 0. So every netdev_priv() dereference is invalid, and we get this when we emit a NETDEV_PRECHANGEUPPER event with a VLAN as its new upper: $ ip link add dummy1 type dummy $ ip link add link dummy1 name dummy1.100 type vlan id 100 [ 43.309174] ================================================================== [ 43.316456] BUG: KASAN: slab-out-of-bounds in dsa_user_prechangeupper+0x30/0xe8 [ 43.323835] Read of size 8 at addr ffff3f86481d2990 by task ip/374 [ 43.330058] [ 43.342436] Call trace: [ 43.366542] dsa_user_prechangeupper+0x30/0xe8 [ 43.371024] dsa_user_netdevice_event+0xb38/0xee8 [ 43.375768] notifier_call_chain+0xa4/0x210 [ 43.379985] raw_notifier_call_chain+0x24/0x38 [ 43.384464] __netdev_upper_dev_link+0x3ec/0x5d8 [ 43.389120] netdev_upper_dev_link+0x70/0xa8 [ 43.393424] register_vlan_dev+0x1bc/0x310 [ 43.397554] vlan_newlink+0x210/0x248 [ 43.401247] rtnl_newlink+0x9fc/0xe30 [ 43.404942] rtnetlink_rcv_msg+0x378/0x580 Avoid the kernel oops by dereferencing after the type check, as customary. 2024-02-23 not yet calculated CVE-2024-26596
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: net: qualcomm: rmnet: fix global oob in rmnet_policy The variable rmnet_link_ops assign a *bigger* maxtype which leads to a global out-of-bounds read when parsing the netlink attributes. See bug trace below: ================================================================== BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline] BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207 CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G N 6.1.0 #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 Call Trace: <TASK> __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106 print_address_description mm/kasan/report.c:284 [inline] print_report+0x172/0x475 mm/kasan/report.c:395 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495 validate_nla lib/nlattr.c:386 [inline] __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600 __nla_parse+0x3e/0x50 lib/nlattr.c:697 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline] __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline] netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921 sock_sendmsg_nosec net/socket.c:714 [inline] sock_sendmsg+0x154/0x190 net/socket.c:734 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565 do_syscall_x64 arch/x86/entry/common.c:50 [inline] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80 entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fdcf2072359 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 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 <48> 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359 RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003 RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 </TASK> The buggy address belongs to the variable: rmnet_policy+0x30/0xe0 The buggy address belongs to the physical page: page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243 flags: 0x200000000001000(reserved|node=0|zone=2) raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000 raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000 page dumped because: kasan: bad access detected Memory state around the buggy address: ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9 >ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9 ^ ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 According to the comment of `nla_parse_nested_deprecated`, the maxtype should be len(destination array) – 1. Hence use `IFLA_RMNET_MAX` here. 2024-02-23 not yet calculated CVE-2024-26597
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache There is a potential UAF scenario in the case of an LPI translation cache hit racing with an operation that invalidates the cache, such as a DISCARD ITS command. The root of the problem is that vgic_its_check_cache() does not elevate the refcount on the vgic_irq before dropping the lock that serializes refcount changes. Have vgic_its_check_cache() raise the refcount on the returned vgic_irq and add the corresponding decrement after queueing the interrupt. 2024-02-23 not yet calculated CVE-2024-26598
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: pwm: Fix out-of-bounds access in of_pwm_single_xlate() With args->args_count == 2 args->args[2] is not defined. Actually the flags are contained in args->args[1]. 2024-02-23 not yet calculated CVE-2024-26599
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP If the external phy working together with phy-omap-usb2 does not implement send_srp(), we may still attempt to call it. This can happen on an idle Ethernet gadget triggering a wakeup for example: configfs-gadget.g1 gadget.0: ECM Suspend configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup … Unable to handle kernel NULL pointer dereference at virtual address 00000000 when execute … PC is at 0x0 LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc] … musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core] usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether] eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4 sch_direct_xmit from __dev_queue_xmit+0x334/0xd88 __dev_queue_xmit from arp_solicit+0xf0/0x268 arp_solicit from neigh_probe+0x54/0x7c neigh_probe from __neigh_event_send+0x22c/0x47c __neigh_event_send from neigh_resolve_output+0x14c/0x1c0 neigh_resolve_output from ip_finish_output2+0x1c8/0x628 ip_finish_output2 from ip_send_skb+0x40/0xd8 ip_send_skb from udp_send_skb+0x124/0x340 udp_send_skb from udp_sendmsg+0x780/0x984 udp_sendmsg from __sys_sendto+0xd8/0x158 __sys_sendto from ret_fast_syscall+0x0/0x58 Let’s fix the issue by checking for send_srp() and set_vbus() before calling them. For USB peripheral only cases these both could be NULL. 2024-02-26 not yet calculated CVE-2024-26600
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: ext4: regenerate buddy after block freeing failed if under fc replay This mostly reverts commit 6bd97bf273bd (“ext4: remove redundant mb_regenerate_buddy()”) and reintroduces mb_regenerate_buddy(). Based on code in mb_free_blocks(), fast commit replay can end up marking as free blocks that are already marked as such. This causes corruption of the buddy bitmap so we need to regenerate it in that case. 2024-02-26 not yet calculated CVE-2024-26601
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: sched/membarrier: reduce the ability to hammer on sys_membarrier On some systems, sys_membarrier can be very expensive, causing overall slowdowns for everything. So put a lock on the path in order to serialize the accesses to prevent the ability for this to be called at too high of a frequency and saturate the machine. 2024-02-26 not yet calculated CVE-2024-26602
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: x86/fpu: Stop relying on userspace for info to fault in xsave buffer Before this change, the expected size of the user space buffer was taken from fx_sw->xstate_size. fx_sw->xstate_size can be changed from user-space, so it is possible construct a sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of the buffer required by xrstor is accessible. In this case, xrstor tries to restore and accesses the unmapped area which results in a fault. But fault_in_readable succeeds because buf + fx_sw->xstate_size is within the still mapped area, so it goes back and tries xrstor again. It will spin in this loop forever. Instead, fault in the maximum size which can be touched by XRSTOR (taken from fpstate->user_size). [ dhansen: tweak subject / changelog ] 2024-02-26 not yet calculated CVE-2024-26603
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: Revert “kobject: Remove redundant checks for whether ktype is NULL” This reverts commit 1b28cb81dab7c1eedc6034206f4e8d644046ad31. It is reported to cause problems, so revert it for now until the root cause can be found. 2024-02-26 not yet calculated CVE-2024-26604
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: PCI/ASPM: Fix deadlock when enabling ASPM A last minute revert in 6.7-final introduced a potential deadlock when enabling ASPM during probe of Qualcomm PCIe controllers as reported by lockdep: ============================================ WARNING: possible recursive locking detected 6.7.0 #40 Not tainted ——————————————– kworker/u16:5/90 is trying to acquire lock: ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc but task is already holding lock: ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc other info that might help us debug this: Possible unsafe locking scenario: CPU0 —- lock(pci_bus_sem); lock(pci_bus_sem); *** DEADLOCK *** Call trace: print_deadlock_bug+0x25c/0x348 __lock_acquire+0x10a4/0x2064 lock_acquire+0x1e8/0x318 down_read+0x60/0x184 pcie_aspm_pm_state_change+0x58/0xdc pci_set_full_power_state+0xa8/0x114 pci_set_power_state+0xc4/0x120 qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom] pci_walk_bus+0x64/0xbc qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom] The deadlock can easily be reproduced on machines like the Lenovo ThinkPad X13s by adding a delay to increase the race window during asynchronous probe where another thread can take a write lock. Add a new pci_set_power_state_locked() and associated helper functions that can be called with the PCI bus semaphore held to avoid taking the read lock twice. 2024-02-26 not yet calculated CVE-2024-26605
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: binder: signal epoll threads of self-work In (e)poll mode, threads often depend on I/O events to determine when data is ready for consumption. Within binder, a thread may initiate a command via BINDER_WRITE_READ without a read buffer and then make use of epoll_wait() or similar to consume any responses afterwards. It is then crucial that epoll threads are signaled via wakeup when they queue their own work. Otherwise, they risk waiting indefinitely for an event leaving their work unhandled. What is worse, subsequent commands won’t trigger a wakeup either as the thread has pending work. 2024-02-26 not yet calculated CVE-2024-26606
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: drm/bridge: sii902x: Fix probing race issue A null pointer dereference crash has been observed rarely on TI platforms using sii9022 bridge: [ 53.271356] sii902x_get_edid+0x34/0x70 [sii902x] [ 53.276066] sii902x_bridge_get_edid+0x14/0x20 [sii902x] [ 53.281381] drm_bridge_get_edid+0x20/0x34 [drm] [ 53.286305] drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper] [ 53.292955] drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper] [ 53.300510] drm_client_modeset_probe+0x1f0/0xbd4 [drm] [ 53.305958] __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper] [ 53.313611] drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper] [ 53.320039] drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper] [ 53.326401] drm_client_register+0x5c/0xa0 [drm] [ 53.331216] drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper] [ 53.336881] tidss_probe+0x128/0x264 [tidss] [ 53.341174] platform_probe+0x68/0xc4 [ 53.344841] really_probe+0x188/0x3c4 [ 53.348501] __driver_probe_device+0x7c/0x16c [ 53.352854] driver_probe_device+0x3c/0x10c [ 53.357033] __device_attach_driver+0xbc/0x158 [ 53.361472] bus_for_each_drv+0x88/0xe8 [ 53.365303] __device_attach+0xa0/0x1b4 [ 53.369135] device_initial_probe+0x14/0x20 [ 53.373314] bus_probe_device+0xb0/0xb4 [ 53.377145] deferred_probe_work_func+0xcc/0x124 [ 53.381757] process_one_work+0x1f0/0x518 [ 53.385770] worker_thread+0x1e8/0x3dc [ 53.389519] kthread+0x11c/0x120 [ 53.392750] ret_from_fork+0x10/0x20 The issue here is as follows: – tidss probes, but is deferred as sii902x is still missing. – sii902x starts probing and enters sii902x_init(). – sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from DRM’s perspective. – sii902x calls sii902x_audio_codec_init() and platform_device_register_data() – The registration of the audio platform device causes probing of the deferred devices. – tidss probes, which eventually causes sii902x_bridge_get_edid() to be called. – sii902x_bridge_get_edid() tries to use the i2c to read the edid. However, the sii902x driver has not set up the i2c part yet, leading to the crash. Fix this by moving the drm_bridge_add() to the end of the sii902x_init(), which is also at the very end of sii902x_probe(). 2024-02-29 not yet calculated CVE-2024-26607
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 linux — linux
  In the Linux kernel, the following vulnerability has been resolved: mm: huge_memory: don’t force huge page alignment on 32 bit commit efa7df3e3bb5 (“mm: align larger anonymous mappings on THP boundaries”) caused two issues [1] [2] reported on 32 bit system or compat userspace. It doesn’t make too much sense to force huge page alignment on 32 bit system due to the constrained virtual address space. [1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/ [2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/ 2024-03-02 not yet calculated CVE-2024-26621
416baaa9-dc9f-4396-8d5f-8c081fb06d67
416baaa9-dc9f-4396-8d5f-8c081fb06d67 N/A — N/A
  Amazon Fire OS 7 before 7.6.6.9 and 8 before 8.1.0.3 allows Fire TV applications to establish local ADB (Android Debug Bridge) connections. NOTE: some third parties dispute whether this has security relevance, because an ADB connection is only possible after the (non-default) ADB Debugging option is enabled, and after the initiator of that specific connection attempt has been approved via a full-screen prompt. 2024-02-26 not yet calculated CVE-2024-27350
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered in phpseclib 1.x before 1.0.23, 2.x before 2.0.47, and 3.x before 3.0.36. An attacker can construct a malformed certificate containing an extremely large prime to cause a denial of service (CPU consumption for an isPrime primality check). NOTE: this issue was introduced when attempting to fix CVE-2023-27560. 2024-03-01 not yet calculated CVE-2024-27354
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered in phpseclib 1.x before 1.0.23, 2.x before 2.0.47, and 3.x before 3.0.36. When processing the ASN.1 object identifier of a certificate, a sub identifier may be provided that leads to a denial of service (CPU consumption for decodeOID). 2024-03-01 not yet calculated CVE-2024-27355
cve@mitre.org
cve@mitre.org N/A — N/A
  An issue was discovered on certain GL-iNet devices. Attackers can download files such as logs via commands, potentially obtaining critical user information. This affects MT6000 4.5.5, XE3000 4.4.4, X3000 4.4.5, MT3000 4.5.0, MT2500 4.5.0, AXT1800 4.5.0, AX1800 4.5.0, A1300 4.5.0, S200 4.1.4-0300, X750 4.3.7, SFT1200 4.3.7, XE300 4.3.7, MT1300 4.3.10, AR750 4.3.10, AR750S 4.3.10, AR300M 4.3.10, AR300M16 4.3.10, B1300 4.3.10, MT300N-v2 4.3.10, X300B 3.217, S1300 3.216, SF1200 3.216, MV1000 3.216, N300 3.216, B2200 3.216, and X1200 3.203. 2024-02-27 not yet calculated CVE-2024-27356
cve@mitre.org
cve@mitre.org N/A — N/A
  Certain WithSecure products allow a Denial of Service because the engine scanner can go into an infinite loop when processing an archive file. This affects WithSecure Client Security 15, WithSecure Server Security 15, WithSecure Email and Server Security 15, WithSecure Elements Endpoint Protection 17 and later, WithSecure Client Security for Mac 15, WithSecure Elements Endpoint Protection for Mac 17 and later, WithSecure Linux Security 64 12.0, WithSecure Linux Protection 12.0, and WithSecure Atlant 1.0.35-1. 2024-02-26 not yet calculated CVE-2024-27359
cve@mitre.org N/A — N/A
  langchain_experimental (aka LangChain Experimental) in LangChain before 0.1.8 allows an attacker to bypass the CVE-2023-44467 fix and execute arbitrary code via the __import__, __subclasses__, __builtins__, __globals__, __getattribute__, __bases__, __mro__, or __base__ attribute in Python code. These are not prohibited by pal_chain/base.py. 2024-02-26 not yet calculated CVE-2024-27444
cve@mitre.org N/A — N/A
  pretix before 2024.1.1 mishandles file validation. 2024-02-26 not yet calculated CVE-2024-27447
cve@mitre.org N/A — N/A
  In the Bentley ALIM Web application, certain configuration settings can cause exposure of a user’s ALIM session token when the user attempts to download files. This is fixed in Assetwise ALIM Web 23.00.02.03 and Assetwise Information Integrity Server 23.00.04.04. 2024-02-26 not yet calculated CVE-2024-27455
cve@mitre.org N/A — N/A
  rack-cors (aka Rack CORS Middleware) 2.0.1 has 0666 permissions for the .rb files. 2024-02-26 not yet calculated CVE-2024-27456
cve@mitre.org N/A — N/A
  Linksys E2000 Ver.1.0.06 build 1 is vulnerable to authentication bypass via the position.js file. 2024-03-01 not yet calculated CVE-2024-27497
cve@mitre.org N/A — N/A
  Bagisto v1.5.1 is vulnerable for Cross site scripting(XSS) via png file upload vulnerability in product review option. 2024-03-01 not yet calculated CVE-2024-27499
cve@mitre.org
cve@mitre.org N/A — N/A
  libLAS 1.8.1 contains a memory leak vulnerability in /libLAS/apps/ts2las.cpp. 2024-02-27 not yet calculated CVE-2024-27507
cve@mitre.org N/A — N/A
  Atheme 7.2.12 contains a memory leak vulnerability in /atheme/src/crypto-benchmark/main.c. 2024-02-27 not yet calculated CVE-2024-27508
cve@mitre.org N/A — N/A
  Osclass 5.1.2 is vulnerable to SQL Injection. 2024-02-28 not yet calculated CVE-2024-27515
cve@mitre.org N/A — N/A
  livehelperchat 4.28v is vulnerable to Server-Side Template Injection (SSTI). 2024-02-29 not yet calculated CVE-2024-27516
cve@mitre.org N/A — N/A
  Webasyst 2.9.9 has a Cross-Site Scripting (XSS) vulnerability, Attackers can create blogs containing malicious code after gaining blog permissions. 2024-02-29 not yet calculated CVE-2024-27517
cve@mitre.org N/A — N/A
  Stupid Simple CMS 1.2.4 is vulnerable to Cross Site Scripting (XSS) within the blog title of the settings. 2024-03-01 not yet calculated CVE-2024-27558
cve@mitre.org N/A — N/A
  Stupid Simple CMS v1.2.4 was discovered to contain a Cross-Site Request Forgery (CSRF) via the component /save_settings.php 2024-03-01 not yet calculated CVE-2024-27559
cve@mitre.org N/A — N/A
  LBT T300- T390 v2.2.1.8 were discovered to contain a stack overflow via the vpn_client_ip parameter in the config_vpn_pptp function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request. 2024-03-01 not yet calculated CVE-2024-27567
cve@mitre.org N/A — N/A
  LBT T300-T390 v2.2.1.8 were discovered to contain a stack overflow via the apn_name_3g parameter in the setupEC20Apn function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request. 2024-03-01 not yet calculated CVE-2024-27568
cve@mitre.org N/A — N/A
  LBT T300-T390 v2.2.1.8 were discovered to contain a stack overflow via the ApCliSsid parameter in the init_nvram function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request. 2024-03-01 not yet calculated CVE-2024-27569
cve@mitre.org N/A — N/A
  LBT T300-T390 v2.2.1.8 were discovered to contain a stack overflow via the ApCliSsid parameter in the generate_conf_router function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request. 2024-03-01 not yet calculated CVE-2024-27570
cve@mitre.org N/A — N/A
  LBT T300-T390 v2.2.1.8 were discovered to contain a stack overflow via the ApCliSsid parameter in the makeCurRemoteApList function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request. 2024-03-01 not yet calculated CVE-2024-27571
cve@mitre.org N/A — N/A
  LBT T300-T390 v2.2.1.8 were discovered to contain a stack overflow via the ApCliSsid parameter in the updateCurAPlist function. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted POST request. 2024-03-01 not yet calculated CVE-2024-27572
cve@mitre.org N/A — N/A
  D-Link DIR-823G A1V1.0.2B05 was discovered to contain a buffer overflow via the SOAPACTION parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input, and possibly remote code execution. 2024-02-29 not yet calculated CVE-2024-27655
cve@mitre.org N/A — N/A
  D-Link DIR-823G A1V1.0.2B05 was discovered to contain a buffer overflow via the Cookie parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input, and possibly remote code execution. 2024-02-29 not yet calculated CVE-2024-27656
cve@mitre.org N/A — N/A
  D-Link DIR-823G A1V1.0.2B05 was discovered to contain a buffer overflow via the User-Agent parameter. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input, and possibly remote code execution. 2024-02-29 not yet calculated CVE-2024-27657
cve@mitre.org N/A — N/A
  D-Link DIR-823G A1V1.0.2B05 was discovered to contain Null-pointer dereferences in sub_4484A8(). This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. 2024-02-29 not yet calculated CVE-2024-27658
cve@mitre.org N/A — N/A
  D-Link DIR-823G A1V1.0.2B05 was discovered to contain Null-pointer dereferences in sub_42AF30(). This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. 2024-02-29 not yet calculated CVE-2024-27659
cve@mitre.org N/A — N/A
  D-Link DIR-823G A1V1.0.2B05 was discovered to contain a Null-pointer dereferences in sub_41C488(). This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. 2024-02-29 not yet calculated CVE-2024-27660
cve@mitre.org N/A — N/A
  D-Link DIR-823G A1V1.0.2B05 was discovered to contain Null-pointer dereferences in sub_4484A8(). This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. 2024-02-29 not yet calculated CVE-2024-27661
cve@mitre.org N/A — N/A
  D-Link DIR-823G A1V1.0.2B05 was discovered to contain a Null-pointer dereferences in sub_4110f4(). This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input. 2024-02-29 not yet calculated CVE-2024-27662
cve@mitre.org N/A — N/A
  Stupid Simple CMS v1.2.4 was discovered to contain a Cross-Site Request Forgery (CSRF) via /update-article.php. 2024-03-01 not yet calculated CVE-2024-27689
cve@mitre.org N/A — N/A
  A Cross Site Scripting vulnerability in CSZ CMS v.1.3.0 allows an attacker to execute arbitrary code via a crafted script to the Site Name fields of the Site Settings component. 2024-03-01 not yet calculated CVE-2024-27734
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in Petrol Pump Mangement Software v.1.0 allows an attacker to execute arbitrary code via a crafted payload to the Address parameter in the add_invoices.php component. 2024-03-01 not yet calculated CVE-2024-27743
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  Cross Site Scripting vulnerability in Petrol Pump Mangement Software v.1.0 allows an attacker to execute arbitrary code via a crafted payload to the image parameter in the profile.php component. 2024-03-01 not yet calculated CVE-2024-27744
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  SQL Injection vulnerability in Petrol Pump Mangement Software v.1.0 allows an attacker to execute arbitrary code via a crafted payload to the email address parameter in the index.php component. 2024-03-01 not yet calculated CVE-2024-27746
cve@mitre.org
cve@mitre.org
cve@mitre.org N/A — N/A
  File Upload vulnerability in Petrol Pump Mangement Software v.1.0 allows an attacker to execute arbitrary code via a crafted payload to the email Image parameter in the profile.php component. 2024-03-01 not yet calculated CVE-2024-27747
cve@mitre.org
cve@mitre.org
cve@mitre.org apache_software_foundation — apache_airflow
  Apache Airflow, versions before 2.8.2, has a vulnerability that allows authenticated users to view DAG code and import errors of DAGs they do not have permission to view through the API and the UI. Users of Apache Airflow are recommended to upgrade to version 2.8.2 or newer to mitigate the risk associated with this vulnerability 2024-02-29 not yet calculated CVE-2024-27906
security@apache.org
security@apache.org
security@apache.org
security@apache.org N/A — N/A
  ospf_te_parse_te in ospfd/ospf_te.c in FRRouting (FRR) through 9.1 allows remote attackers to cause a denial of service (ospfd daemon crash) via a malformed OSPF LSA packet, because of an attempted access to a missing attribute field. 2024-02-28 not yet calculated CVE-2024-27913
cve@mitre.org