{"schema_version":"1.7.2","id":"OESA-2024-1677","modified":"2024-05-31T11:08:11Z","published":"2024-05-31T11:08:11Z","upstream":["CVE-2021-47269","CVE-2021-47284","CVE-2021-47335","CVE-2021-47393","CVE-2021-47455","CVE-2021-47473","CVE-2021-47497","CVE-2022-48695","CVE-2022-48697","CVE-2022-48702","CVE-2022-48704","CVE-2022-48710","CVE-2023-52650","CVE-2023-52652","CVE-2023-52653","CVE-2023-52656","CVE-2023-52683","CVE-2023-52691","CVE-2023-52698","CVE-2023-52813","CVE-2023-52817","CVE-2023-52818","CVE-2023-52835","CVE-2023-52840","CVE-2023-52847","CVE-2023-52867","CVE-2023-52868","CVE-2024-26955","CVE-2024-26956","CVE-2024-26957","CVE-2024-26958","CVE-2024-26960","CVE-2024-26961","CVE-2024-26965","CVE-2024-26966","CVE-2024-26969","CVE-2024-26974","CVE-2024-26976","CVE-2024-26981","CVE-2024-26982","CVE-2024-26993","CVE-2024-26994","CVE-2024-26996","CVE-2024-26999","CVE-2024-27000","CVE-2024-27001","CVE-2024-27008","CVE-2024-27010","CVE-2024-27011","CVE-2024-27024","CVE-2024-27028","CVE-2024-27037","CVE-2024-27046","CVE-2024-27051","CVE-2024-27054","CVE-2024-27059","CVE-2024-27062","CVE-2024-27072","CVE-2024-27073","CVE-2024-27075","CVE-2024-27077","CVE-2024-27078","CVE-2024-27388","CVE-2024-27403","CVE-2024-27419","CVE-2024-27426","CVE-2024-27427","CVE-2024-27428","CVE-2024-35805","CVE-2024-35806","CVE-2024-35815","CVE-2024-35835","CVE-2024-35886","CVE-2024-35898","CVE-2024-35922","CVE-2024-35930","CVE-2024-35936","CVE-2024-35950","CVE-2024-35976","CVE-2024-35997"],"summary":"kernel security update","details":"The Linux Kernel, the operating system core itself.\r\n\r\nSecurity Fix(es):\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: ep0: fix NULL pointer exception\r\n\r\nThere is no validation of the index from dwc3_wIndex_to_dep() and we might\nbe referring a non-existing ep and trigger a NULL pointer exception. In\ncertain configurations we might use fewer eps and the index might wrongly\nindicate a larger ep index than existing.\r\n\r\nBy adding this validation from the patch we can actually report a wrong\nindex back to the caller.\r\n\r\nIn our usecase we are using a composite device on an older kernel, but\nupstream might use this fix also. Unfortunately, I cannot describe the\nhardware for others to reproduce the issue as it is a proprietary\nimplementation.\r\n\r\n[   82.958261] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a4\n[   82.966891] Mem abort info:\n[   82.969663]   ESR = 0x96000006\n[   82.972703]   Exception class = DABT (current EL), IL = 32 bits\n[   82.978603]   SET = 0, FnV = 0\n[   82.981642]   EA = 0, S1PTW = 0\n[   82.984765] Data abort info:\n[   82.987631]   ISV = 0, ISS = 0x00000006\n[   82.991449]   CM = 0, WnR = 0\n[   82.994409] user pgtable: 4k pages, 39-bit VAs, pgdp = 00000000c6210ccc\n[   83.000999] [00000000000000a4] pgd=0000000053aa5003, pud=0000000053aa5003, pmd=0000000000000000\n[   83.009685] Internal error: Oops: 96000006 [#1] PREEMPT SMP\n[   83.026433] Process irq/62-dwc3 (pid: 303, stack limit = 0x000000003985154c)\n[   83.033470] CPU: 0 PID: 303 Comm: irq/62-dwc3 Not tainted 4.19.124 #1\n[   83.044836] pstate: 60000085 (nZCv daIf -PAN -UAO)\n[   83.049628] pc : dwc3_ep0_handle_feature+0x414/0x43c\n[   83.054558] lr : dwc3_ep0_interrupt+0x3b4/0xc94\r\n\r\n...\r\n\r\n[   83.141788] Call trace:\n[   83.144227]  dwc3_ep0_handle_feature+0x414/0x43c\n[   83.148823]  dwc3_ep0_interrupt+0x3b4/0xc94\n[   83.181546] ---[ end trace aac6b5267d84c32f ]---(CVE-2021-47269)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nisdn: mISDN: netjet: Fix crash in nj_probe:\r\n\r\n\u0026apos;nj_setup\u0026apos; in netjet.c might fail with -EIO and in this case\n\u0026apos;card-\u0026gt;irq\u0026apos; is initialized and is bigger than zero. A subsequent call to\n\u0026apos;nj_release\u0026apos; will free the irq that has not been requested.\r\n\r\nFix this bug by deleting the previous assignment to \u0026apos;card-\u0026gt;irq\u0026apos; and just\nkeep the assignment before \u0026apos;request_irq\u0026apos;.\r\n\r\nThe KASAN\u0026apos;s log reveals it:\r\n\r\n[    3.354615 ] WARNING: CPU: 0 PID: 1 at kernel/irq/manage.c:1826\nfree_irq+0x100/0x480\n[    3.355112 ] Modules linked in:\n[    3.355310 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[    3.355816 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[    3.356552 ] RIP: 0010:free_irq+0x100/0x480\n[    3.356820 ] Code: 6e 08 74 6f 4d 89 f4 e8 5e ac 09 00 4d 8b 74 24 18\n4d 85 f6 75 e3 e8 4f ac 09 00 8b 75 c8 48 c7 c7 78 c1 2e 85 e8 e0 cf f5\nff \u0026lt;0f\u0026gt; 0b 48 8b 75 c0 4c 89 ff e8 72 33 0b 03 48 8b 43 40 4c 8b a0 80\n[    3.358012 ] RSP: 0000:ffffc90000017b48 EFLAGS: 00010082\n[    3.358357 ] RAX: 0000000000000000 RBX: ffff888104dc8000 RCX:\n0000000000000000\n[    3.358814 ] RDX: ffff8881003c8000 RSI: ffffffff8124a9e6 RDI:\n00000000ffffffff\n[    3.359272 ] RBP: ffffc90000017b88 R08: 0000000000000000 R09:\n0000000000000000\n[    3.359732 ] R10: ffffc900000179f0 R11: 0000000000001d04 R12:\n0000000000000000\n[    3.360195 ] R13: ffff888107dc6000 R14: ffff888107dc6928 R15:\nffff888104dc80a8\n[    3.360652 ] FS:  0000000000000000(0000) GS:ffff88817bc00000(0000)\nknlGS:0000000000000000\n[    3.361170 ] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[    3.361538 ] CR2: 0000000000000000 CR3: 000000000582e000 CR4:\n00000000000006f0\n[    3.362003 ] DR0: 0000000000000000 DR1: 0000000000000000 DR2:\n0000000000000000\n[    3.362175 ] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:\n0000000000000400\n[    3.362175 ] Call Trace:\n[    3.362175 ]  nj_release+0x51/0x1e0\n[    3.362175 ]  nj_probe+0x450/0x950\n[    3.362175 ]  ? pci_device_remove+0x110/0x110\n[    3.362175 ]  local_pci_probe+0x45/0xa0\n[    3.362175 ]  pci_device_probe+0x12b/0x1d0\n[    3.362175 ]  really_probe+0x2a9/0x610\n[    3.362175 ]  driver_probe_device+0x90/0x1d0\n[    3.362175 ]  ? mutex_lock_nested+0x1b/0x20\n[    3.362175 ]  device_driver_attach+0x68/0x70\n[    3.362175 ]  __driver_attach+0x124/0x1b0\n[    3.362175 ]  ? device_driver_attach+0x70/0x70\n[    3.362175 ]  bus_for_each_dev+0xbb/0x110\n[    3.362175 ]  ? rdinit_setup+0x45/0x45\n[    3.362175 ]  driver_attach+0x27/0x30\n[    3.362175 ]  bus_add_driver+0x1eb/0x2a0\n[    3.362175 ]  driver_register+0xa9/0x180\n[    3.362175 ]  __pci_register_driver+0x82/0x90\n[    3.362175 ]  ? w6692_init+0x38/0x38\n[    3.362175 ]  nj_init+0x36/0x38\n[    3.362175 ]  do_one_initcall+0x7f/0x3d0\n[    3.362175 ]  ? rdinit_setup+0x45/0x45\n[    3.362175 ]  ? rcu_read_lock_sched_held+0x4f/0x80\n[    3.362175 ]  kernel_init_freeable+0x2aa/0x301\n[    3.362175 ]  ? rest_init+0x2c0/0x2c0\n[    3.362175 ]  kernel_init+0x18/0x190\n[    3.362175 ]  ? rest_init+0x2c0/0x2c0\n[    3.362175 ]  ? rest_init+0x2c0/0x2c0\n[    3.362175 ]  ret_from_fork+0x1f/0x30\n[    3.362175 ] Kernel panic - not syncing: panic_on_warn set ...\n[    3.362175 ] CPU: 0 PID: 1 Comm: swapper/0 Not tainted\n5.13.0-rc1-00144-g25a1298726e #13\n[    3.362175 ] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS\nrel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014\n[    3.362175 ] Call Trace:\n[    3.362175 ]  dump_stack+0xba/0xf5\n[    3.362175 ]  ? free_irq+0x100/0x480\n[    3.362175 ]  panic+0x15a/0x3f2\n[    3.362175 ]  ? __warn+0xf2/0x150\n[    3.362175 ]  ? free_irq+0x100/0x480\n[    3.362175 ]  __warn+0x108/0x150\n[    3.362175 ]  ? free_irq+0x100/0x480\n[    3.362175 ]  report_bug+0x119/0x1c0\n[    3.362175 ]  handle_bug+0x3b/0x80\n[    3.362175 ]  exc_invalid_op+0x18/0x70\n[    3.362175 ]  asm_exc_invalid_op+0x12/0x20\n[    3.362175 ] RIP: 0010:free_irq+0x100\n---truncated---(CVE-2021-47284)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nf2fs: fix to avoid racing on fsync_entry_slab by multi filesystem instances\r\n\r\nAs syzbot reported, there is an use-after-free issue during f2fs recovery:\r\n\r\nUse-after-free write at 0xffff88823bc16040 (in kfence-#10):\n kmem_cache_destroy+0x1f/0x120 mm/slab_common.c:486\n f2fs_recover_fsync_data+0x75b0/0x8380 fs/f2fs/recovery.c:869\n f2fs_fill_super+0x9393/0xa420 fs/f2fs/super.c:3945\n mount_bdev+0x26c/0x3a0 fs/super.c:1367\n legacy_get_tree+0xea/0x180 fs/fs_context.c:592\n vfs_get_tree+0x86/0x270 fs/super.c:1497\n do_new_mount fs/namespace.c:2905 [inline]\n path_mount+0x196f/0x2be0 fs/namespace.c:3235\n do_mount fs/namespace.c:3248 [inline]\n __do_sys_mount fs/namespace.c:3456 [inline]\n __se_sys_mount+0x2f9/0x3b0 fs/namespace.c:3433\n do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nThe root cause is multi f2fs filesystem instances can race on accessing\nglobal fsync_entry_slab pointer, result in use-after-free issue of slab\ncache, fixes to init/destroy this slab cache only once during module\ninit/destroy procedure to avoid this issue.(CVE-2021-47335)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (mlxreg-fan) Return non-zero value when fan current state is enforced from sysfs\r\n\r\nFan speed minimum can be enforced from sysfs. For example, setting\ncurrent fan speed to 20 is used to enforce fan speed to be at 100%\nspeed, 19 - to be not below 90% speed, etcetera. This feature provides\nability to limit fan speed according to some system wise\nconsiderations, like absence of some replaceable units or high system\nambient temperature.\r\n\r\nRequest for changing fan minimum speed is configuration request and can\nbe set only through \u0026apos;sysfs\u0026apos; write procedure. In this situation value of\nargument \u0026apos;state\u0026apos; is above nominal fan speed maximum.\r\n\r\nReturn non-zero code in this case to avoid\nthermal_cooling_device_stats_update() call, because in this case\nstatistics update violates thermal statistics table range.\nThe issues is observed in case kernel is configured with option\nCONFIG_THERMAL_STATISTICS.\r\n\r\nHere is the trace from KASAN:\n[  159.506659] BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x7d/0xb0\n[  159.516016] Read of size 4 at addr ffff888116163840 by task hw-management.s/7444\n[  159.545625] Call Trace:\n[  159.548366]  dump_stack+0x92/0xc1\n[  159.552084]  ? thermal_cooling_device_stats_update+0x7d/0xb0\n[  159.635869]  thermal_zone_device_update+0x345/0x780\n[  159.688711]  thermal_zone_device_set_mode+0x7d/0xc0\n[  159.694174]  mlxsw_thermal_modules_init+0x48f/0x590 [mlxsw_core]\n[  159.700972]  ? mlxsw_thermal_set_cur_state+0x5a0/0x5a0 [mlxsw_core]\n[  159.731827]  mlxsw_thermal_init+0x763/0x880 [mlxsw_core]\n[  160.070233] RIP: 0033:0x7fd995909970\n[  160.074239] Code: 73 01 c3 48 8b 0d 28 d5 2b 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 99 2d 2c 00 00 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ..\n[  160.095242] RSP: 002b:00007fff54f5d938 EFLAGS: 00000246 ORIG_RAX: 0000000000000001\n[  160.103722] RAX: ffffffffffffffda RBX: 0000000000000013 RCX: 00007fd995909970\n[  160.111710] RDX: 0000000000000013 RSI: 0000000001906008 RDI: 0000000000000001\n[  160.119699] RBP: 0000000001906008 R08: 00007fd995bc9760 R09: 00007fd996210700\n[  160.127687] R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000013\n[  160.135673] R13: 0000000000000001 R14: 00007fd995bc8600 R15: 0000000000000013\n[  160.143671]\n[  160.145338] Allocated by task 2924:\n[  160.149242]  kasan_save_stack+0x19/0x40\n[  160.153541]  __kasan_kmalloc+0x7f/0xa0\n[  160.157743]  __kmalloc+0x1a2/0x2b0\n[  160.161552]  thermal_cooling_device_setup_sysfs+0xf9/0x1a0\n[  160.167687]  __thermal_cooling_device_register+0x1b5/0x500\n[  160.173833]  devm_thermal_of_cooling_device_register+0x60/0xa0\n[  160.180356]  mlxreg_fan_probe+0x474/0x5e0 [mlxreg_fan]\n[  160.248140]\n[  160.249807] The buggy address belongs to the object at ffff888116163400\n[  160.249807]  which belongs to the cache kmalloc-1k of size 1024\n[  160.263814] The buggy address is located 64 bytes to the right of\n[  160.263814]  1024-byte region [ffff888116163400, ffff888116163800)\n[  160.277536] The buggy address belongs to the page:\n[  160.282898] page:0000000012275840 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888116167000 pfn:0x116160\n[  160.294872] head:0000000012275840 order:3 compound_mapcount:0 compound_pincount:0\n[  160.303251] flags: 0x200000000010200(slab|head|node=0|zone=2)\n[  160.309694] raw: 0200000000010200 ffffea00046f7208 ffffea0004928208 ffff88810004dbc0\n[  160.318367] raw: ffff888116167000 00000000000a0006 00000001ffffffff 0000000000000000\n[  160.327033] page dumped because: kasan: bad access detected\n[  160.333270]\n[  160.334937] Memory state around the buggy address:\n[  160.356469] \u0026gt;ffff888116163800: fc ..(CVE-2021-47393)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nptp: Fix possible memory leak in ptp_clock_register()\r\n\r\nI got memory leak as follows when doing fault injection test:\r\n\r\nunreferenced object 0xffff88800906c618 (size 8):\n  comm \u0026quot;i2c-idt82p33931\u0026quot;, pid 4421, jiffies 4294948083 (age 13.188s)\n  hex dump (first 8 bytes):\n    70 74 70 30 00 00 00 00                          ptp0....\n  backtrace:\n    [\u0026lt;00000000312ed458\u0026gt;] __kmalloc_track_caller+0x19f/0x3a0\n    [\u0026lt;0000000079f6e2ff\u0026gt;] kvasprintf+0xb5/0x150\n    [\u0026lt;0000000026aae54f\u0026gt;] kvasprintf_const+0x60/0x190\n    [\u0026lt;00000000f323a5f7\u0026gt;] kobject_set_name_vargs+0x56/0x150\n    [\u0026lt;000000004e35abdd\u0026gt;] dev_set_name+0xc0/0x100\n    [\u0026lt;00000000f20cfe25\u0026gt;] ptp_clock_register+0x9f4/0xd30 [ptp]\n    [\u0026lt;000000008bb9f0de\u0026gt;] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]\r\n\r\nWhen posix_clock_register() returns an error, the name allocated\nin dev_set_name() will be leaked, the put_device() should be used\nto give up the device reference, then the name will be freed in\nkobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: qla2xxx: Fix a memory leak in an error path of qla2x00_process_els()\r\n\r\nCommit 8c0eb596baa5 (\u0026quot;[SCSI] qla2xxx: Fix a memory leak in an error path of\nqla2x00_process_els()\u0026quot;), intended to change:\r\n\r\n        bsg_job-\u0026gt;request-\u0026gt;msgcode == FC_BSG_HST_ELS_NOLOGIN\r\n\r\n\n        bsg_job-\u0026gt;request-\u0026gt;msgcode != FC_BSG_RPT_ELS\r\n\r\nbut changed it to:\r\n\r\n        bsg_job-\u0026gt;request-\u0026gt;msgcode == FC_BSG_RPT_ELS\r\n\r\ninstead.\r\n\r\nChange the == to a != to avoid leaking the fcport structure or freeing\nunallocated memory.(CVE-2021-47473)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmem: Fix shift-out-of-bound (UBSAN) with byte size cells\r\n\r\nIf a cell has \u0026apos;nbits\u0026apos; equal to a multiple of BITS_PER_BYTE the logic\r\n\r\n *p \u0026amp;= GENMASK((cell-\u0026gt;nbits%BITS_PER_BYTE) - 1, 0);\r\n\r\nwill become undefined behavior because nbits modulo BITS_PER_BYTE is 0, and we\nsubtract one from that making a large number that is then shifted more than the\nnumber of bits that fit into an unsigned long.\r\n\r\nUBSAN reports this problem:\r\n\r\n UBSAN: shift-out-of-bounds in drivers/nvmem/core.c:1386:8\n shift exponent 64 is too large for 64-bit type \u0026apos;unsigned long\u0026apos;\n CPU: 6 PID: 7 Comm: kworker/u16:0 Not tainted 5.15.0-rc3+ #9\n Hardware name: Google Lazor (rev3+) with KB Backlight (DT)\n Workqueue: events_unbound deferred_probe_work_func\n Call trace:\n  dump_backtrace+0x0/0x170\n  show_stack+0x24/0x30\n  dump_stack_lvl+0x64/0x7c\n  dump_stack+0x18/0x38\n  ubsan_epilogue+0x10/0x54\n  __ubsan_handle_shift_out_of_bounds+0x180/0x194\n  __nvmem_cell_read+0x1ec/0x21c\n  nvmem_cell_read+0x58/0x94\n  nvmem_cell_read_variable_common+0x4c/0xb0\n  nvmem_cell_read_variable_le_u32+0x40/0x100\n  a6xx_gpu_init+0x170/0x2f4\n  adreno_bind+0x174/0x284\n  component_bind_all+0xf0/0x264\n  msm_drm_bind+0x1d8/0x7a0\n  try_to_bring_up_master+0x164/0x1ac\n  __component_add+0xbc/0x13c\n  component_add+0x20/0x2c\n  dp_display_probe+0x340/0x384\n  platform_probe+0xc0/0x100\n  really_probe+0x110/0x304\n  __driver_probe_device+0xb8/0x120\n  driver_probe_device+0x4c/0xfc\n  __device_attach_driver+0xb0/0x128\n  bus_for_each_drv+0x90/0xdc\n  __device_attach+0xc8/0x174\n  device_initial_probe+0x20/0x2c\n  bus_probe_device+0x40/0xa4\n  deferred_probe_work_func+0x7c/0xb8\n  process_one_work+0x128/0x21c\n  process_scheduled_works+0x40/0x54\n  worker_thread+0x1ec/0x2a8\n  kthread+0x138/0x158\n  ret_from_fork+0x10/0x20\r\n\r\nFix it by making sure there are any bits to mask out.(CVE-2021-47497)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Fix use-after-free warning\r\n\r\nFix the following use-after-free warning which is observed during\ncontroller reset:\r\n\r\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 23 PID: 5399 at lib/refcount.c:28 refcount_warn_saturate+0xa6/0xf0(CVE-2022-48695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet: fix a use-after-free\r\n\r\nFix the following use-after-free complaint triggered by blktests nvme/004:\r\n\r\nBUG: KASAN: user-memory-access in blk_mq_complete_request_remote+0xac/0x350\nRead of size 4 at addr 0000607bd1835943 by task kworker/13:1/460\nWorkqueue: nvmet-wq nvme_loop_execute_work [nvme_loop]\nCall Trace:\n show_stack+0x52/0x58\n dump_stack_lvl+0x49/0x5e\n print_report.cold+0x36/0x1e2\n kasan_report+0xb9/0xf0\n __asan_load4+0x6b/0x80\n blk_mq_complete_request_remote+0xac/0x350\n nvme_loop_queue_response+0x1df/0x275 [nvme_loop]\n __nvmet_req_complete+0x132/0x4f0 [nvmet]\n nvmet_req_complete+0x15/0x40 [nvmet]\n nvmet_execute_io_connect+0x18a/0x1f0 [nvmet]\n nvme_loop_execute_work+0x20/0x30 [nvme_loop]\n process_one_work+0x56e/0xa70\n worker_thread+0x2d1/0x640\n kthread+0x183/0x1c0\n ret_from_fork+0x1f/0x30(CVE-2022-48697)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: emu10k1: Fix out of bounds access in snd_emu10k1_pcm_channel_alloc()\r\n\r\nThe voice allocator sometimes begins allocating from near the end of the\narray and then wraps around, however snd_emu10k1_pcm_channel_alloc()\naccesses the newly allocated voices as if it never wrapped around.\r\n\r\nThis results in out of bounds access if the first voice has a high enough\nindex so that first_voice + requested_voice_count \u0026gt; NUM_G (64).\nThe more voices are requested, the more likely it is for this to occur.\r\n\r\nThis was initially discovered using PipeWire, however it can be reproduced\nby calling aplay multiple times with 16 channels:\naplay -r 48000 -D plughw:CARD=Live,DEV=3 -c 16 /dev/zero\r\n\r\nUBSAN: array-index-out-of-bounds in sound/pci/emu10k1/emupcm.c:127:40\nindex 65 is out of range for type \u0026apos;snd_emu10k1_voice [64]\u0026apos;\nCPU: 1 PID: 31977 Comm: aplay Tainted: G        W IOE      6.0.0-rc2-emu10k1+ #7\nHardware name: ASUSTEK COMPUTER INC P5W DH Deluxe/P5W DH Deluxe, BIOS 3002    07/22/2010\nCall Trace:\n\u0026lt;TASK\u0026gt;\ndump_stack_lvl+0x49/0x63\ndump_stack+0x10/0x16\nubsan_epilogue+0x9/0x3f\n__ubsan_handle_out_of_bounds.cold+0x44/0x49\nsnd_emu10k1_playback_hw_params+0x3bc/0x420 [snd_emu10k1]\nsnd_pcm_hw_params+0x29f/0x600 [snd_pcm]\nsnd_pcm_common_ioctl+0x188/0x1410 [snd_pcm]\n? exit_to_user_mode_prepare+0x35/0x170\n? do_syscall_64+0x69/0x90\n? syscall_exit_to_user_mode+0x26/0x50\n? do_syscall_64+0x69/0x90\n? exit_to_user_mode_prepare+0x35/0x170\nsnd_pcm_ioctl+0x27/0x40 [snd_pcm]\n__x64_sys_ioctl+0x95/0xd0\ndo_syscall_64+0x5c/0x90\n? do_syscall_64+0x69/0x90\n? do_syscall_64+0x69/0x90\nentry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48702)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: add a force flush to delay work when radeon\r\n\r\nAlthough radeon card fence and wait for gpu to finish processing current batch rings,\nthere is still a corner case that radeon lockup work queue may not be fully flushed,\nand meanwhile the radeon_suspend_kms() function has called pci_set_power_state() to\nput device in D3hot state.\nPer PCI spec rev 4.0 on 5.3.1.4.1 D3hot State.\n\u0026gt; Configuration and Message requests are the only TLPs accepted by a Function in\n\u0026gt; the D3hot state. All other received Requests must be handled as Unsupported Requests,\n\u0026gt; and all received Completions may optionally be handled as Unexpected Completions.\nThis issue will happen in following logs:\nUnable to handle kernel paging request at virtual address 00008800e0008010\nCPU 0 kworker/0:3(131): Oops 0\npc = [\u0026lt;ffffffff811bea5c\u0026gt;]  ra = [\u0026lt;ffffffff81240844\u0026gt;]  ps = 0000 Tainted: G        W\npc is at si_gpu_check_soft_reset+0x3c/0x240\nra is at si_dma_is_lockup+0x34/0xd0\nv0 = 0000000000000000  t0 = fff08800e0008010  t1 = 0000000000010000\nt2 = 0000000000008010  t3 = fff00007e3c00000  t4 = fff00007e3c00258\nt5 = 000000000000ffff  t6 = 0000000000000001  t7 = fff00007ef078000\ns0 = fff00007e3c016e8  s1 = fff00007e3c00000  s2 = fff00007e3c00018\ns3 = fff00007e3c00000  s4 = fff00007fff59d80  s5 = 0000000000000000\ns6 = fff00007ef07bd98\na0 = fff00007e3c00000  a1 = fff00007e3c016e8  a2 = 0000000000000008\na3 = 0000000000000001  a4 = 8f5c28f5c28f5c29  a5 = ffffffff810f4338\nt8 = 0000000000000275  t9 = ffffffff809b66f8  t10 = ff6769c5d964b800\nt11= 000000000000b886  pv = ffffffff811bea20  at = 0000000000000000\ngp = ffffffff81d89690  sp = 00000000aa814126\nDisabling lock debugging due to kernel taint\nTrace:\n[\u0026lt;ffffffff81240844\u0026gt;] si_dma_is_lockup+0x34/0xd0\n[\u0026lt;ffffffff81119610\u0026gt;] radeon_fence_check_lockup+0xd0/0x290\n[\u0026lt;ffffffff80977010\u0026gt;] process_one_work+0x280/0x550\n[\u0026lt;ffffffff80977350\u0026gt;] worker_thread+0x70/0x7c0\n[\u0026lt;ffffffff80977410\u0026gt;] worker_thread+0x130/0x7c0\n[\u0026lt;ffffffff80982040\u0026gt;] kthread+0x200/0x210\n[\u0026lt;ffffffff809772e0\u0026gt;] worker_thread+0x0/0x7c0\n[\u0026lt;ffffffff80981f8c\u0026gt;] kthread+0x14c/0x210\n[\u0026lt;ffffffff80911658\u0026gt;] ret_from_kernel_thread+0x18/0x20\n[\u0026lt;ffffffff80981e40\u0026gt;] kthread+0x0/0x210\n Code: ad3e0008  43f0074a  ad7e0018  ad9e0020  8c3001e8  40230101\n \u0026lt;88210000\u0026gt; 4821ed21\nSo force lockup work queue flush to fix this problem.(CVE-2022-48704)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: fix a possible null pointer dereference\r\n\r\nIn radeon_fp_native_mode(), the return value of drm_mode_duplicate()\nis assigned to mode, which will lead to a NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.\r\n\r\nThe failure status of drm_cvt_mode() on the other path is checked too.(CVE-2022-48710)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/tegra: dsi: Add missing check for of_find_device_by_node\r\n\r\nAdd check for the return value of of_find_device_by_node() and return\nthe error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nNTB: fix possible name leak in ntb_register_device()\r\n\r\nIf device_register() fails in ntb_register_device(), the device name\nallocated by dev_set_name() should be freed. As per the comment in\ndevice_register(), callers should use put_device() to give up the\nreference in the error path. So fix this by calling put_device() in the\nerror path so that the name can be freed in kobject_cleanup().\r\n\r\nAs a result of this, put_device() in the error path of\nntb_register_device() is removed and the actual error is returned.\r\n\r\n[mani: reworded commit message](CVE-2023-52652)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix a memleak in gss_import_v2_context\r\n\r\nThe ctx-\u0026gt;mech_used.data allocated by kmemdup is not freed in neither\ngss_import_v2_context nor it only caller gss_krb5_import_sec_context,\nwhich frees ctx on error.\r\n\r\nThus, this patch reform the last call of gss_import_v2_context to the\ngss_krb5_import_ctx_v2, preventing the memleak while keepping the return\nformation.(CVE-2023-52653)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nio_uring: drop any code related to SCM_RIGHTS\r\n\r\nThis is dead code after we dropped support for passing io_uring fds\nover SCM_RIGHTS, get rid of it.(CVE-2023-52656)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nACPI: LPIT: Avoid u32 multiplication overflow\r\n\r\nIn lpit_update_residency() there is a possibility of overflow\nin multiplication, if tsc_khz is large enough (\u0026gt; UINT_MAX/1000).\r\n\r\nChange multiplication to mul_u32_u32().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52683)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: fix a double-free in si_dpm_init\r\n\r\nWhen the allocation of\nadev-\u0026gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,\namdgpu_free_extended_power_table is called to free some fields of adev.\nHowever, when the control flow returns to si_dpm_sw_init, it goes to\nlabel dpm_failed and calls si_dpm_fini, which calls\namdgpu_free_extended_power_table again and free those fields again. Thus\na double-free is triggered.(CVE-2023-52691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncalipso: fix memory leak in netlbl_calipso_add_pass()\r\n\r\nIf IPv6 support is disabled at boot (ipv6.disable=1),\nthe calipso_init() -\u0026gt; netlbl_calipso_ops_register() function isn\u0026apos;t called,\nand the netlbl_calipso_ops_get() function always returns NULL.\nIn this case, the netlbl_calipso_add_pass() function allocates memory\nfor the doi_def variable but doesn\u0026apos;t free it with the calipso_doi_free().\r\n\r\nBUG: memory leak\nunreferenced object 0xffff888011d68180 (size 64):\n  comm \u0026quot;syz-executor.1\u0026quot;, pid 10746, jiffies 4295410986 (age 17.928s)\n  hex dump (first 32 bytes):\n    00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  ................\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;...\u0026gt;] kmalloc include/linux/slab.h:552 [inline]\n    [\u0026lt;...\u0026gt;] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]\n    [\u0026lt;...\u0026gt;] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111\n    [\u0026lt;...\u0026gt;] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739\n    [\u0026lt;...\u0026gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]\n    [\u0026lt;...\u0026gt;] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800\n    [\u0026lt;...\u0026gt;] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515\n    [\u0026lt;...\u0026gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811\n    [\u0026lt;...\u0026gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]\n    [\u0026lt;...\u0026gt;] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339\n    [\u0026lt;...\u0026gt;] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934\n    [\u0026lt;...\u0026gt;] sock_sendmsg_nosec net/socket.c:651 [inline]\n    [\u0026lt;...\u0026gt;] sock_sendmsg+0x157/0x190 net/socket.c:671\n    [\u0026lt;...\u0026gt;] ____sys_sendmsg+0x712/0x870 net/socket.c:2342\n    [\u0026lt;...\u0026gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396\n    [\u0026lt;...\u0026gt;] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429\n    [\u0026lt;...\u0026gt;] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46\n    [\u0026lt;...\u0026gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6\r\n\r\nFound by InfoTeCS on behalf of Linux Verification Center\n(linuxtesting.org) with Syzkaller\r\n\r\n[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: pcrypt - Fix hungtask for PADATA_RESET\r\n\r\nWe found a hungtask bug in test_aead_vec_cfg as follows:\r\n\r\nINFO: task cryptomgr_test:391009 blocked for more than 120 seconds.\n\u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\nCall trace:\n __switch_to+0x98/0xe0\n __schedule+0x6c4/0xf40\n schedule+0xd8/0x1b4\n schedule_timeout+0x474/0x560\n wait_for_common+0x368/0x4e0\n wait_for_completion+0x20/0x30\n wait_for_completion+0x20/0x30\n test_aead_vec_cfg+0xab4/0xd50\n test_aead+0x144/0x1f0\n alg_test_aead+0xd8/0x1e0\n alg_test+0x634/0x890\n cryptomgr_test+0x40/0x70\n kthread+0x1e0/0x220\n ret_from_fork+0x10/0x18\n Kernel panic - not syncing: hung_task: blocked tasks\r\n\r\nFor padata_do_parallel, when the return err is 0 or -EBUSY, it will call\nwait_for_completion(\u0026amp;wait-\u0026gt;completion) in test_aead_vec_cfg. In normal\ncase, aead_request_complete() will be called in pcrypt_aead_serial and the\nreturn err is 0 for padata_do_parallel. But, when pinst-\u0026gt;flags is\nPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and it\nwon\u0026apos;t call aead_request_complete(). Therefore, test_aead_vec_cfg will\nhung at wait_for_completion(\u0026amp;wait-\u0026gt;completion), which will cause\nhungtask.\r\n\r\nThe problem comes as following:\n(padata_do_parallel)                 |\n    rcu_read_lock_bh();              |\n    err = -EINVAL;                   |   (padata_replace)\n                                     |     pinst-\u0026gt;flags |= PADATA_RESET;\n    err = -EBUSY                     |\n    if (pinst-\u0026gt;flags \u0026amp; PADATA_RESET) |\n        rcu_read_unlock_bh()         |\n        return err\r\n\r\nIn order to resolve the problem, we replace the return err -EBUSY with\n-EAGAIN, which means parallel_data is changing, and the caller should call\nit again.\r\n\r\nv3:\nremove retry and just change the return err.\nv2:\nintroduce padata_try_do_parallel() in pcrypt_aead_encrypt and\npcrypt_aead_decrypt to solve the hungtask.(CVE-2023-52813)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL\r\n\r\nIn certain types of chips, such as VEGA20, reading the amdgpu_regs_smc file could result in an abnormal null pointer access when the smc_rreg pointer is NULL. Below are the steps to reproduce this issue and the corresponding exception log:\r\n\r\n1. Navigate to the directory: /sys/kernel/debug/dri/0\n2. Execute command: cat amdgpu_regs_smc\n3. Exception Log::\n[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000\n[4005007.702562] #PF: supervisor instruction fetch in kernel mode\n[4005007.702567] #PF: error_code(0x0010) - not-present page\n[4005007.702570] PGD 0 P4D 0\n[4005007.702576] Oops: 0010 [#1] SMP NOPTI\n[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G           OE     5.15.0-43-generic #46-Ubunt       u\n[4005007.702590] RIP: 0010:0x0\n[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.\n[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206\n[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68\n[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000\n[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980\n[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000\n[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000\n[4005007.702622] FS:  00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000\n[4005007.702626] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0\n[4005007.702633] Call Trace:\n[4005007.702636]  \u0026lt;TASK\u0026gt;\n[4005007.702640]  amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]\n[4005007.703002]  full_proxy_read+0x5c/0x80\n[4005007.703011]  vfs_read+0x9f/0x1a0\n[4005007.703019]  ksys_read+0x67/0xe0\n[4005007.703023]  __x64_sys_read+0x19/0x20\n[4005007.703028]  do_syscall_64+0x5c/0xc0\n[4005007.703034]  ? do_user_addr_fault+0x1e3/0x670\n[4005007.703040]  ? exit_to_user_mode_prepare+0x37/0xb0\n[4005007.703047]  ? irqentry_exit_to_user_mode+0x9/0x20\n[4005007.703052]  ? irqentry_exit+0x19/0x30\n[4005007.703057]  ? exc_page_fault+0x89/0x160\n[4005007.703062]  ? asm_exc_page_fault+0x8/0x30\n[4005007.703068]  entry_SYSCALL_64_after_hwframe+0x44/0xae\n[4005007.703075] RIP: 0033:0x7f5e07672992\n[4005007.703079] Code: c0 e9 b2 fe ff ff 50 48 8d 3d fa b2 0c 00 e8 c5 1d 02 00 0f 1f 44 00 00 f3 0f        1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 56 c3 0f 1f 44 00 00 48 83 e       c 28 48 89 54 24\n[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000\n[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992\n[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003\n[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010\n[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000\n[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000\n[4005007.703105]  \u0026lt;/TASK\u0026gt;\n[4005007.703107] Modules linked in: nf_tables libcrc32c nfnetlink algif_hash af_alg binfmt_misc nls_       iso8859_1 ipmi_ssif ast intel_rapl_msr intel_rapl_common drm_vram_helper drm_ttm_helper amd64_edac t       tm edac_mce_amd kvm_amd ccp mac_hid k10temp kvm acpi_ipmi ipmi_si rapl sch_fq_codel ipmi_devintf ipm       i_msghandler msr parport_pc ppdev lp parport mtd pstore_blk efi_pstore ramoops pstore_zone reed_solo       mon ip_tables x_tables autofs4 ib_uverbs ib_core amdgpu(OE) amddrm_ttm_helper(OE) amdttm(OE) iommu_v       2 amd_sched(OE) amdkcl(OE) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops cec rc_core        drm igb ahci xhci_pci libahci i2c_piix4 i2c_algo_bit xhci_pci_renesas dca\n[4005007.703184] CR2: 0000000000000000\n[4005007.703188] ---[ en\n---truncated---(CVE-2023-52817)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd: Fix UBSAN array-index-out-of-bounds for SMU7\r\n\r\nFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nperf/core: Bail out early if the request AUX area is out of bound\r\n\r\nWhen perf-record with a large AUX area, e.g 4GB, it fails with:\r\n\r\n    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n    failed to mmap with 12 (Cannot allocate memory)\r\n\r\nand it reveals a WARNING with __alloc_pages():\r\n\r\n\t------------[ cut here ]------------\n\tWARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248\n\tCall trace:\n\t __alloc_pages+0x1ec/0x248\n\t __kmalloc_large_node+0xc0/0x1f8\n\t __kmalloc_node+0x134/0x1e8\n\t rb_alloc_aux+0xe0/0x298\n\t perf_mmap+0x440/0x660\n\t mmap_region+0x308/0x8a8\n\t do_mmap+0x3c0/0x528\n\t vm_mmap_pgoff+0xf4/0x1b8\n\t ksys_mmap_pgoff+0x18c/0x218\n\t __arm64_sys_mmap+0x38/0x58\n\t invoke_syscall+0x50/0x128\n\t el0_svc_common.constprop.0+0x58/0x188\n\t do_el0_svc+0x34/0x50\n\t el0_svc+0x34/0x108\n\t el0t_64_sync_handler+0xb8/0xc0\n\t el0t_64_sync+0x1a4/0x1a8\r\n\r\n\u0026apos;rb-\u0026gt;aux_pages\u0026apos; allocated by kcalloc() is a pointer array which is used to\nmaintains AUX trace pages. The allocated page for this array is physically\ncontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the\nsize of pointer array crosses the limitation set by MAX_ORDER, it reveals a\nWARNING.\r\n\r\nSo bail out early with -ENOMEM if the request AUX area is out of bound,\ne.g.:\r\n\r\n    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1\n    failed to mmap with 12 (Cannot allocate memory)(CVE-2023-52835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: synaptics-rmi4 - fix use after free in rmi_unregister_function()\r\n\r\nThe put_device() calls rmi_release_function() which frees \u0026quot;fn\u0026quot; so the\ndereference on the next line \u0026quot;fn-\u0026gt;num_of_irqs\u0026quot; is a use after free.\nMove the put_device() to the end to fix this.(CVE-2023-52840)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: bttv: fix use after free error due to btv-\u0026gt;timeout timer\r\n\r\nThere may be some a race condition between timer function\nbttv_irq_timeout and bttv_remove. The timer is setup in\nprobe and there is no timer_delete operation in remove\nfunction. When it hit kfree btv, the function might still be\ninvoked, which will cause use after free bug.\r\n\r\nThis bug is found by static analysis, it may be false positive.\r\n\r\nFix it by adding del_timer_sync invoking to the remove function.\r\n\r\ncpu0                cpu1\n                  bttv_probe\n                    -\u0026gt;timer_setup\n                      -\u0026gt;bttv_set_dma\n                        -\u0026gt;mod_timer;\nbttv_remove\n  -\u0026gt;kfree(btv);\n                  -\u0026gt;bttv_irq_timeout\n                    -\u0026gt;USE btv(CVE-2023-52847)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/radeon: possible buffer overflow\r\n\r\nBuffer \u0026apos;afmt_status\u0026apos; of size 6 could overflow, since index \u0026apos;afmt_idx\u0026apos; is\nchecked after access.(CVE-2023-52867)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nthermal: core: prevent potential string overflow\r\n\r\nThe dev-\u0026gt;id value comes from ida_alloc() so it\u0026apos;s a number between zero\nand INT_MAX.  If it\u0026apos;s too high then these sprintf()s will overflow.(CVE-2023-52868)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: prevent kernel bug at submit_bh_wbc()\r\n\r\nFix a bug where nilfs_get_block() returns a successful status when\nsearching and inserting the specified block both fail inconsistently.  If\nthis inconsistent behavior is not due to a previously fixed bug, then an\nunexpected race is occurring, so return a temporary error -EAGAIN instead.\r\n\r\nThis prevents callers such as __block_write_begin_int() from requesting a\nread into a buffer that is not mapped, which would cause the BUG_ON check\nfor the BH_Mapped flag in submit_bh_wbc() to fail.(CVE-2024-26955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix failure to detect DAT corruption in btree and direct mappings\r\n\r\nPatch series \u0026quot;nilfs2: fix kernel bug at submit_bh_wbc()\u0026quot;.\r\n\r\nThis resolves a kernel BUG reported by syzbot.  Since there are two\nflaws involved, I\u0026apos;ve made each one a separate patch.\r\n\r\nThe first patch alone resolves the syzbot-reported bug, but I think\nboth fixes should be sent to stable, so I\u0026apos;ve tagged them as such.\r\n\r\n\nThis patch (of 2):\r\n\r\nSyzbot has reported a kernel bug in submit_bh_wbc() when writing file data\nto a nilfs2 file system whose metadata is corrupted.\r\n\r\nThere are two flaws involved in this issue.\r\n\r\nThe first flaw is that when nilfs_get_block() locates a data block using\nbtree or direct mapping, if the disk address translation routine\nnilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata\ncorruption, it can be passed back to nilfs_get_block().  This causes\nnilfs_get_block() to misidentify an existing block as non-existent,\ncausing both data block lookup and insertion to fail inconsistently.\r\n\r\nThe second flaw is that nilfs_get_block() returns a successful status in\nthis inconsistent state.  This causes the caller __block_write_begin_int()\nor others to request a read even though the buffer is not mapped,\nresulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()\nfailing.\r\n\r\nThis fixes the first issue by changing the return value to code -EINVAL\nwhen a conversion using DAT fails with code -ENOENT, avoiding the\nconflicting condition that leads to the kernel bug described above.  Here,\ncode -EINVAL indicates that metadata corruption was detected during the\nblock lookup, which will be properly handled as a file system error and\nconverted to -EIO when passing through the nilfs2 bmap layer.(CVE-2024-26956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/zcrypt: fix reference counting on zcrypt card objects\r\n\r\nTests with hot-plugging crytpo cards on KVM guests with debug\nkernel build revealed an use after free for the load field of\nthe struct zcrypt_card. The reason was an incorrect reference\nhandling of the zcrypt card object which could lead to a free\nof the zcrypt card object while it was still in use.\r\n\r\nThis is an example of the slab message:\r\n\r\n    kernel: 0x00000000885a7512-0x00000000885a7513 @offset=1298. First byte 0x68 instead of 0x6b\n    kernel: Allocated in zcrypt_card_alloc+0x36/0x70 [zcrypt] age=18046 cpu=3 pid=43\n    kernel:  kmalloc_trace+0x3f2/0x470\n    kernel:  zcrypt_card_alloc+0x36/0x70 [zcrypt]\n    kernel:  zcrypt_cex4_card_probe+0x26/0x380 [zcrypt_cex4]\n    kernel:  ap_device_probe+0x15c/0x290\n    kernel:  really_probe+0xd2/0x468\n    kernel:  driver_probe_device+0x40/0xf0\n    kernel:  __device_attach_driver+0xc0/0x140\n    kernel:  bus_for_each_drv+0x8c/0xd0\n    kernel:  __device_attach+0x114/0x198\n    kernel:  bus_probe_device+0xb4/0xc8\n    kernel:  device_add+0x4d2/0x6e0\n    kernel:  ap_scan_adapter+0x3d0/0x7c0\n    kernel:  ap_scan_bus+0x5a/0x3b0\n    kernel:  ap_scan_bus_wq_callback+0x40/0x60\n    kernel:  process_one_work+0x26e/0x620\n    kernel:  worker_thread+0x21c/0x440\n    kernel: Freed in zcrypt_card_put+0x54/0x80 [zcrypt] age=9024 cpu=3 pid=43\n    kernel:  kfree+0x37e/0x418\n    kernel:  zcrypt_card_put+0x54/0x80 [zcrypt]\n    kernel:  ap_device_remove+0x4c/0xe0\n    kernel:  device_release_driver_internal+0x1c4/0x270\n    kernel:  bus_remove_device+0x100/0x188\n    kernel:  device_del+0x164/0x3c0\n    kernel:  device_unregister+0x30/0x90\n    kernel:  ap_scan_adapter+0xc8/0x7c0\n    kernel:  ap_scan_bus+0x5a/0x3b0\n    kernel:  ap_scan_bus_wq_callback+0x40/0x60\n    kernel:  process_one_work+0x26e/0x620\n    kernel:  worker_thread+0x21c/0x440\n    kernel:  kthread+0x150/0x168\n    kernel:  __ret_from_fork+0x3c/0x58\n    kernel:  ret_from_fork+0xa/0x30\n    kernel: Slab 0x00000372022169c0 objects=20 used=18 fp=0x00000000885a7c88 flags=0x3ffff00000000a00(workingset|slab|node=0|zone=1|lastcpupid=0x1ffff)\n    kernel: Object 0x00000000885a74b8 @offset=1208 fp=0x00000000885a7c88\n    kernel: Redzone  00000000885a74b0: bb bb bb bb bb bb bb bb                          ........\n    kernel: Object   00000000885a74b8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a74c8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a74d8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a74e8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a74f8: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b  kkkkkkkkkkkkkkkk\n    kernel: Object   00000000885a7508: 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 68 4b 6b 6b 6b a5  kkkkkkkkkkhKkkk.\n    kernel: Redzone  00000000885a7518: bb bb bb bb bb bb bb bb                          ........\n    kernel: Padding  00000000885a756c: 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a 5a              ZZZZZZZZZZZZ\n    kernel: CPU: 0 PID: 387 Comm: systemd-udevd Not tainted 6.8.0-HF #2\n    kernel: Hardware name: IBM 3931 A01 704 (KVM/Linux)\n    kernel: Call Trace:\n    kernel:  [\u0026lt;00000000ca5ab5b8\u0026gt;] dump_stack_lvl+0x90/0x120\n    kernel:  [\u0026lt;00000000c99d78bc\u0026gt;] check_bytes_and_report+0x114/0x140\n    kernel:  [\u0026lt;00000000c99d53cc\u0026gt;] check_object+0x334/0x3f8\n    kernel:  [\u0026lt;00000000c99d820c\u0026gt;] alloc_debug_processing+0xc4/0x1f8\n    kernel:  [\u0026lt;00000000c99d852e\u0026gt;] get_partial_node.part.0+0x1ee/0x3e0\n    kernel:  [\u0026lt;00000000c99d94ec\u0026gt;] ___slab_alloc+0xaf4/0x13c8\n    kernel:  [\u0026lt;00000000c99d9e38\u0026gt;] __slab_alloc.constprop.0+0x78/0xb8\n    kernel:  [\u0026lt;00000000c99dc8dc\u0026gt;] __kmalloc+0x434/0x590\n    kernel:  [\u0026lt;00000000c9b4c0ce\u0026gt;] ext4_htree_store_dirent+0x4e/0x1c0\n    kernel:  [\u0026lt;00000000c9b908a2\u0026gt;] htree_dirblock_to_tree+0x17a/0x3f0\n    kernel: \n---truncated---(CVE-2024-26957)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfs: fix UAF in direct writes\r\n\r\nIn production we have been hitting the following warning consistently\r\n\r\n------------[ cut here ]------------\nrefcount_t: underflow; use-after-free.\nWARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0\nWorkqueue: nfsiod nfs_direct_write_schedule_work [nfs]\nRIP: 0010:refcount_warn_saturate+0x9c/0xe0\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? __warn+0x9f/0x130\n ? refcount_warn_saturate+0x9c/0xe0\n ? report_bug+0xcc/0x150\n ? handle_bug+0x3d/0x70\n ? exc_invalid_op+0x16/0x40\n ? asm_exc_invalid_op+0x16/0x20\n ? refcount_warn_saturate+0x9c/0xe0\n nfs_direct_write_schedule_work+0x237/0x250 [nfs]\n process_one_work+0x12f/0x4a0\n worker_thread+0x14e/0x3b0\n ? ZSTD_getCParams_internal+0x220/0x220\n kthread+0xdc/0x120\n ? __btf_name_valid+0xa0/0xa0\n ret_from_fork+0x1f/0x30\r\n\r\nThis is because we\u0026apos;re completing the nfs_direct_request twice in a row.\r\n\r\nThe source of this is when we have our commit requests to submit, we\nprocess them and send them off, and then in the completion path for the\ncommit requests we have\r\n\r\nif (nfs_commit_end(cinfo.mds))\n\tnfs_direct_write_complete(dreq);\r\n\r\nHowever since we\u0026apos;re submitting asynchronous requests we sometimes have\none that completes before we submit the next one, so we end up calling\ncomplete on the nfs_direct_request twice.\r\n\r\nThe only other place we use nfs_generic_commit_list() is in\n__nfs_commit_inode, which wraps this call in a\r\n\r\nnfs_commit_begin();\nnfs_commit_end();\r\n\r\nWhich is a common pattern for this style of completion handling, one\nthat is also repeated in the direct code with get_dreq()/put_dreq()\ncalls around where we process events as well as in the completion paths.\r\n\r\nFix this by using the same pattern for the commit requests.\r\n\r\nBefore with my 200 node rocksdb stress running this warning would pop\nevery 10ish minutes.  With my patch the stress test has been running for\nseveral hours without popping.(CVE-2024-26958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm: swap: fix race between free_swap_and_cache() and swapoff()\r\n\r\nThere was previously a theoretical window where swapoff() could run and\nteardown a swap_info_struct while a call to free_swap_and_cache() was\nrunning in another thread.  This could cause, amongst other bad\npossibilities, swap_page_trans_huge_swapped() (called by\nfree_swap_and_cache()) to access the freed memory for swap_map.\r\n\r\nThis is a theoretical problem and I haven\u0026apos;t been able to provoke it from a\ntest case.  But there has been agreement based on code review that this is\npossible (see link below).\r\n\r\nFix it by using get_swap_device()/put_swap_device(), which will stall\nswapoff().  There was an extra check in _swap_info_get() to confirm that\nthe swap entry was not free.  This isn\u0026apos;t present in get_swap_device()\nbecause it doesn\u0026apos;t make sense in general due to the race between getting\nthe reference and swapoff.  So I\u0026apos;ve added an equivalent check directly in\nfree_swap_and_cache().\r\n\r\nDetails of how to provoke one possible issue (thanks to David Hildenbrand\nfor deriving this):\r\n\r\n--8\u0026lt;-----\r\n\r\n__swap_entry_free() might be the last user and result in\n\u0026quot;count == SWAP_HAS_CACHE\u0026quot;.\r\n\r\nswapoff-\u0026gt;try_to_unuse() will stop as soon as soon as si-\u0026gt;inuse_pages==0.\r\n\r\nSo the question is: could someone reclaim the folio and turn\nsi-\u0026gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().\r\n\r\nImagine the following: 2 MiB folio in the swapcache. Only 2 subpages are\nstill references by swap entries.\r\n\r\nProcess 1 still references subpage 0 via swap entry.\nProcess 2 still references subpage 1 via swap entry.\r\n\r\nProcess 1 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\n[then, preempted in the hypervisor etc.]\r\n\r\nProcess 2 quits. Calls free_swap_and_cache().\n-\u0026gt; count == SWAP_HAS_CACHE\r\n\r\nProcess 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls\n__try_to_reclaim_swap().\r\n\r\n__try_to_reclaim_swap()-\u0026gt;folio_free_swap()-\u0026gt;delete_from_swap_cache()-\u0026gt;\nput_swap_folio()-\u0026gt;free_swap_slot()-\u0026gt;swapcache_free_entries()-\u0026gt;\nswap_entry_free()-\u0026gt;swap_range_free()-\u0026gt;\n...\nWRITE_ONCE(si-\u0026gt;inuse_pages, si-\u0026gt;inuse_pages - nr_entries);\r\n\r\nWhat stops swapoff to succeed after process 2 reclaimed the swap cache\nbut before process1 finished its call to swap_page_trans_huge_swapped()?\r\n\r\n--8\u0026lt;-----(CVE-2024-26960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmac802154: fix llsec key resources release in mac802154_llsec_key_del\r\n\r\nmac802154_llsec_key_del() can free resources of a key directly without\nfollowing the RCU rules for waiting before the end of a grace period. This\nmay lead to use-after-free in case llsec_lookup_key() is traversing the\nlist of keys in parallel with a key deletion:\r\n\r\nrefcount_t: addition on 0; use-after-free.\nWARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0\nModules linked in:\nCPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014\nRIP: 0010:refcount_warn_saturate+0x162/0x2a0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n llsec_lookup_key.isra.0+0x890/0x9e0\n mac802154_llsec_encrypt+0x30c/0x9c0\n ieee802154_subif_start_xmit+0x24/0x1e0\n dev_hard_start_xmit+0x13e/0x690\n sch_direct_xmit+0x2ae/0xbc0\n __dev_queue_xmit+0x11dd/0x3c20\n dgram_sendmsg+0x90b/0xd60\n __sys_sendto+0x466/0x4c0\n __x64_sys_sendto+0xe0/0x1c0\n do_syscall_64+0x45/0xf0\n entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nAlso, ieee802154_llsec_key_entry structures are not freed by\nmac802154_llsec_key_del():\r\n\r\nunreferenced object 0xffff8880613b6980 (size 64):\n  comm \u0026quot;iwpan\u0026quot;, pid 2176, jiffies 4294761134 (age 60.475s)\n  hex dump (first 32 bytes):\n    78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de  x.......\u0026quot;.......\n    00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;ffffffff81dcfa62\u0026gt;] __kmem_cache_alloc_node+0x1e2/0x2d0\n    [\u0026lt;ffffffff81c43865\u0026gt;] kmalloc_trace+0x25/0xc0\n    [\u0026lt;ffffffff88968b09\u0026gt;] mac802154_llsec_key_add+0xac9/0xcf0\n    [\u0026lt;ffffffff8896e41a\u0026gt;] ieee802154_add_llsec_key+0x5a/0x80\n    [\u0026lt;ffffffff8892adc6\u0026gt;] nl802154_add_llsec_key+0x426/0x5b0\n    [\u0026lt;ffffffff86ff293e\u0026gt;] genl_family_rcv_msg_doit+0x1fe/0x2f0\n    [\u0026lt;ffffffff86ff46d1\u0026gt;] genl_rcv_msg+0x531/0x7d0\n    [\u0026lt;ffffffff86fee7a9\u0026gt;] netlink_rcv_skb+0x169/0x440\n    [\u0026lt;ffffffff86ff1d88\u0026gt;] genl_rcv+0x28/0x40\n    [\u0026lt;ffffffff86fec15c\u0026gt;] netlink_unicast+0x53c/0x820\n    [\u0026lt;ffffffff86fecd8b\u0026gt;] netlink_sendmsg+0x93b/0xe60\n    [\u0026lt;ffffffff86b91b35\u0026gt;] ____sys_sendmsg+0xac5/0xca0\n    [\u0026lt;ffffffff86b9c3dd\u0026gt;] ___sys_sendmsg+0x11d/0x1c0\n    [\u0026lt;ffffffff86b9c65a\u0026gt;] __sys_sendmsg+0xfa/0x1d0\n    [\u0026lt;ffffffff88eadbf5\u0026gt;] do_syscall_64+0x45/0xf0\n    [\u0026lt;ffffffff890000ea\u0026gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76\r\n\r\nHandle the proper resource release in the RCU callback function\nmac802154_llsec_key_del_rcu().\r\n\r\nNote that if llsec_lookup_key() finds a key, it gets a refcount via\nllsec_key_get() and locally copies key id from key_entry (which is a\nlist element). So it\u0026apos;s safe to call llsec_key_put() and free the list\nentry after the RCU grace period elapses.\r\n\r\nFound by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-msm8974: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: mmcc-apq8084: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: qcom: gcc-ipq8074: fix terminating of frequency table arrays\r\n\r\nThe frequency table arrays are supposed to be terminated with an\nempty element. Add such entry to the end of the arrays where it\nis missing in order to avoid possible out-of-bound access when\nthe table is traversed by functions like qcom_find_freq() or\nqcom_find_freq_floor().\r\n\r\nOnly compile tested.(CVE-2024-26969)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncrypto: qat - resolve race condition during AER recovery\r\n\r\nDuring the PCI AER system\u0026apos;s error recovery process, the kernel driver\nmay encounter a race condition with freeing the reset_data structure\u0026apos;s\nmemory. If the device restart will take more than 10 seconds the function\nscheduling that restart will exit due to a timeout, and the reset_data\nstructure will be freed. However, this data structure is used for\ncompletion notification after the restart is completed, which leads\nto a UAF bug.\r\n\r\nThis results in a KFENCE bug notice.\r\n\r\n  BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]\n  Use-after-free read at 0x00000000bc56fddf (in kfence-#142):\n  adf_device_reset_worker+0x38/0xa0 [intel_qat]\n  process_one_work+0x173/0x340\r\n\r\nTo resolve this race condition, the memory associated to the container\nof the work_struct is freed on the worker if the timeout expired,\notherwise on the function that schedules the worker.\nThe timeout detection can be done by checking if the caller is\nstill waiting for completion or not by using completion_done() function.(CVE-2024-26974)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: Always flush async #PF workqueue when vCPU is being destroyed\r\n\r\nAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing its\ncompletion queue, e.g. when a VM and all its vCPUs is being destroyed.\nKVM must ensure that none of its workqueue callbacks is running when the\nlast reference to the KVM _module_ is put.  Gifting a reference to the\nassociated VM prevents the workqueue callback from dereferencing freed\nvCPU/VM memory, but does not prevent the KVM module from being unloaded\nbefore the callback completes.\r\n\r\nDrop the misguided VM refcount gifting, as calling kvm_put_kvm() from\nasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will\nresult in deadlock.  async_pf_execute() can\u0026apos;t return until kvm_put_kvm()\nfinishes, and kvm_put_kvm() can\u0026apos;t return until async_pf_execute() finishes:\r\n\r\n WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]\n Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass\n CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015\n Workqueue: events async_pf_execute [kvm]\n RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  async_pf_execute+0x198/0x260 [kvm]\n  process_one_work+0x145/0x2d0\n  worker_thread+0x27e/0x3a0\n  kthread+0xba/0xe0\n  ret_from_fork+0x2d/0x50\n  ret_from_fork_asm+0x11/0x20\n  \u0026lt;/TASK\u0026gt;\n ---[ end trace 0000000000000000 ]---\n INFO: task kworker/8:1:251 blocked for more than 120 seconds.\n       Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119\n \u0026quot;echo 0 \u0026gt; /proc/sys/kernel/hung_task_timeout_secs\u0026quot; disables this message.\n task:kworker/8:1     state:D stack:0     pid:251   ppid:2      flags:0x00004000\n Workqueue: events async_pf_execute [kvm]\n Call Trace:\n  \u0026lt;TASK\u0026gt;\n  __schedule+0x33f/0xa40\n  schedule+0x53/0xc0\n  schedule_timeout+0x12a/0x140\n  __wait_for_common+0x8d/0x1d0\n  __flush_work.isra.0+0x19f/0x2c0\n  kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]\n  kvm_arch_destroy_vm+0x78/0x1b0 [kvm]\n  kvm_put_kvm+0x1c1/0x320 [kvm]\n  async_pf_execute+0x198/0x260 [kvm]\n  process_one_work+0x145/0x2d0\n  worker_thread+0x27e/0x3a0\n  kthread+0xba/0xe0\n  ret_from_fork+0x2d/0x50\n  ret_from_fork_asm+0x11/0x20\n  \u0026lt;/TASK\u0026gt;\r\n\r\nIf kvm_clear_async_pf_completion_queue() actually flushes the workqueue,\nthen there\u0026apos;s no need to gift async_pf_execute() a reference because all\ninvocations of async_pf_execute() will be forced to complete before the\nvCPU and its VM are destroyed/freed.  And that in turn fixes the module\nunloading bug as __fput() won\u0026apos;t do module_put() on the last vCPU reference\nuntil the vCPU has been freed, e.g. if closing the vCPU file also puts the\nlast reference to the KVM module.\r\n\r\nNote that kvm_check_async_pf_completion() may also take the work item off\nthe completion queue and so also needs to flush the work queue, as the\nwork will not be seen by kvm_clear_async_pf_completion_queue().  Waiting\non the workqueue could theoretically delay a vCPU due to waiting for the\nwork to complete, but that\u0026apos;s a very, very small chance, and likely a very\nsmall delay.  kvm_arch_async_page_present_queued() unconditionally makes a\nnew request, i.e. will effectively delay entering the guest, so the\nremaining work is really just:\r\n\r\n        trace_kvm_async_pf_completed(addr, cr2_or_gpa);\r\n\r\n        __kvm_vcpu_wake_up(vcpu);\r\n\r\n        mmput(mm);\r\n\r\nand mmput() can\u0026apos;t drop the last reference to the page tables if the vCPU is\nstill alive, i.e. the vCPU won\u0026apos;t get stuck tearing down page tables.\r\n\r\nAdd a helper to do the flushing, specifically to deal with \u0026quot;wakeup all\u0026quot;\nwork items, as they aren\u0026apos;t actually work items, i.e. are never placed in a\nworkqueue.  Trying to flush a bogus workqueue entry rightly makes\n__flush_work() complain (kudos to whoever added that sanity check).\r\n\r\nNote, commit 5f6de5cbebee (\u0026quot;KVM: Prevent module exit until al\n---truncated---(CVE-2024-26976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix OOB in nilfs_set_de_type\r\n\r\nThe size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is\ndefined as \u0026quot;S_IFMT \u0026gt;\u0026gt; S_SHIFT\u0026quot;, but the nilfs_set_de_type() function,\nwhich uses this array, specifies the index to read from the array in the\nsame way as \u0026quot;(mode \u0026amp; S_IFMT) \u0026gt;\u0026gt; S_SHIFT\u0026quot;.\r\n\r\nstatic void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode\n *inode)\n{\n\tumode_t mode = inode-\u0026gt;i_mode;\r\n\r\n\tde-\u0026gt;file_type = nilfs_type_by_mode[(mode \u0026amp; S_IFMT)\u0026gt;\u0026gt;S_SHIFT]; // oob\n}\r\n\r\nHowever, when the index is determined this way, an out-of-bounds (OOB)\nerror occurs by referring to an index that is 1 larger than the array size\nwhen the condition \u0026quot;mode \u0026amp; S_IFMT == S_IFMT\u0026quot; is satisfied.  Therefore, a\npatch to resize the nilfs_type_by_mode array should be applied to prevent\nOOB errors.(CVE-2024-26981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSquashfs: check the inode number is not the invalid value of zero\r\n\r\nSyskiller has produced an out of bounds access in fill_meta_index().\r\n\r\nThat out of bounds access is ultimately caused because the inode\nhas an inode number with the invalid value of zero, which was not checked.\r\n\r\nThe reason this causes the out of bounds access is due to following\nsequence of events:\r\n\r\n1. Fill_meta_index() is called to allocate (via empty_meta_index())\n   and fill a metadata index.  It however suffers a data read error\n   and aborts, invalidating the newly returned empty metadata index.\n   It does this by setting the inode number of the index to zero,\n   which means unused (zero is not a valid inode number).\r\n\r\n2. When fill_meta_index() is subsequently called again on another\n   read operation, locate_meta_index() returns the previous index\n   because it matches the inode number of 0.  Because this index\n   has been returned it is expected to have been filled, and because\n   it hasn\u0026apos;t been, an out of bounds access is performed.\r\n\r\nThis patch adds a sanity check which checks that the inode number\nis not zero when the inode is created and returns -EINVAL if it is.\r\n\r\n[phillip@squashfs.org.uk: whitespace fix]\n  Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk(CVE-2024-26982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs: sysfs: Fix reference leak in sysfs_break_active_protection()\r\n\r\nThe sysfs_break_active_protection() routine has an obvious reference\nleak in its error path.  If the call to kernfs_find_and_get() fails then\nkn will be NULL, so the companion sysfs_unbreak_active_protection()\nroutine won\u0026apos;t get called (and would only cause an access violation by\ntrying to dereference kn-\u0026gt;parent if it was called).  As a result, the\nreference to kobj acquired at the start of the function will never be\nreleased.\r\n\r\nFix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspeakup: Avoid crash on very long word\r\n\r\nIn case a console is set up really large and contains a really long word\n(\u0026gt; 256 characters), we have to stop before the length of the word buffer.(CVE-2024-26994)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error\r\n\r\nWhen ncm function is working and then stop usb0 interface for link down,\neth_stop() is called. At this piont, accidentally if usb transport error\nshould happen in usb_ep_enable(), \u0026apos;in_ep\u0026apos; and/or \u0026apos;out_ep\u0026apos; may not be enabled.\r\n\r\nAfter that, ncm_disable() is called to disable for ncm unbind\nbut gether_disconnect() is never called since \u0026apos;in_ep\u0026apos; is not enabled.\r\n\r\nAs the result, ncm object is released in ncm unbind\nbut \u0026apos;dev-\u0026gt;port_usb\u0026apos; associated to \u0026apos;ncm-\u0026gt;port\u0026apos; is not NULL.\r\n\r\nAnd when ncm bind again to recover netdev, ncm object is reallocated\nbut usb0 interface is already associated to previous released ncm object.\r\n\r\nTherefore, once usb0 interface is up and eth_start_xmit() is called,\nreleased ncm object is dereferrenced and it might cause use-after-free memory.\r\n\r\n[function unlink via configfs]\n  usb0: eth_stop dev-\u0026gt;port_usb=ffffff9b179c3200\n  --\u0026gt; error happens in usb_ep_enable().\n  NCM: ncm_disable: ncm=ffffff9b179c3200\n  --\u0026gt; no gether_disconnect() since ncm-\u0026gt;port.in_ep-\u0026gt;enabled is false.\n  NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200\n  NCM: ncm_free: ncm free ncm=ffffff9b179c3200   \u0026lt;-- released ncm\r\n\r\n[function link via configfs]\n  NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000\n  NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000\n  NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0\n  usb0: eth_open dev-\u0026gt;port_usb=ffffff9b179c3200  \u0026lt;-- previous released ncm\n  usb0: eth_start dev-\u0026gt;port_usb=ffffff9b179c3200 \u0026lt;--\n  eth_start_xmit()\n  --\u0026gt; dev-\u0026gt;wrap()\n  Unable to handle kernel paging request at virtual address dead00000000014f\r\n\r\nThis patch addresses the issue by checking if \u0026apos;ncm-\u0026gt;netdev\u0026apos; is not NULL at\nncm_disable() to call gether_disconnect() to deassociate \u0026apos;dev-\u0026gt;port_usb\u0026apos;.\nIt\u0026apos;s more reasonable to check \u0026apos;ncm-\u0026gt;netdev\u0026apos; to call gether_connect/disconnect\nrather than check \u0026apos;ncm-\u0026gt;port.in_ep-\u0026gt;enabled\u0026apos; since it might not be enabled\nbut the gether connection might be established.(CVE-2024-26996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial/pmac_zilog: Remove flawed mitigation for rx irq flood\r\n\r\nThe mitigation was intended to stop the irq completely. That may be\nbetter than a hard lock-up but it turns out that you get a crash anyway\nif you\u0026apos;re using pmac_zilog as a serial console:\r\n\r\nttyPZ0: pmz: rx irq flood !\nBUG: spinlock recursion on CPU#0, swapper/0\r\n\r\nThat\u0026apos;s because the pr_err() call in pmz_receive_chars() results in\npmz_console_write() attempting to lock a spinlock already locked in\npmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal\nBUG splat. The spinlock in question is the one in struct uart_port.\r\n\r\nEven when it\u0026apos;s not fatal, the serial port rx function ceases to work.\nAlso, the iteration limit doesn\u0026apos;t play nicely with QEMU, as can be\nseen in the bug report linked below.\r\n\r\nA web search for other reports of the error message \u0026quot;pmz: rx irq flood\u0026quot;\ndidn\u0026apos;t produce anything. So I don\u0026apos;t think this code is needed any more.\nRemove it.(CVE-2024-26999)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nserial: mxs-auart: add spinlock around changing cts state\r\n\r\nThe uart_handle_cts_change() function in serial_core expects the caller\nto hold uport-\u0026gt;lock. For example, I have seen the below kernel splat,\nwhen the Bluetooth driver is loaded on an i.MX28 board.\r\n\r\n    [   85.119255] ------------[ cut here ]------------\n    [   85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec\n    [   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs\n    [   85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1\n    [   85.151396] Hardware name: Freescale MXS (Device Tree)\n    [   85.156679] Workqueue: hci0 hci_power_on [bluetooth]\n    (...)\n    [   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4\n    [   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210\n    (...)(CVE-2024-27000)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncomedi: vmk80xx: fix incomplete endpoint checking\r\n\r\nWhile vmk80xx does have endpoint checking implemented, some things\ncan fall through the cracks. Depending on the hardware model,\nURBs can have either bulk or interrupt type, and current version\nof vmk80xx_find_usb_endpoints() function does not take that fully\ninto account. While this warning does not seem to be too harmful,\nat the very least it will crash systems with \u0026apos;panic_on_warn\u0026apos; set on\nthem.\r\n\r\nFix the issue found by Syzkaller [1] by somewhat simplifying the\nendpoint checking process with usb_find_common_endpoints() and\nensuring that only expected endpoint types are present.\r\n\r\nThis patch has not been tested on real hardware.\r\n\r\n[1] Syzkaller report:\nusb 1-1: BOGUS urb xfer, pipe 1 != type 3\nWARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503\n...\nCall Trace:\n \u0026lt;TASK\u0026gt;\n usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59\n vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]\n vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818\n comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067\n usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399\n...\r\n\r\nSimilar issue also found by Syzkaller:(CVE-2024-27001)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm: nv04: Fix out of bounds access\r\n\r\nWhen Output Resource (dcb-\u0026gt;or) value is assigned in\nfabricate_dcb_output(), there may be out of bounds access to\ndac_users array in case dcb-\u0026gt;or is zero because ffs(dcb-\u0026gt;or) is\nused as index there.\nThe \u0026apos;or\u0026apos; argument of fabricate_dcb_output() must be interpreted as a\nnumber of bit to set, not value.\r\n\r\nUtilize macros from \u0026apos;enum nouveau_or\u0026apos; in calls instead of hardcoding.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/sched: Fix mirred deadlock on device recursion\r\n\r\nWhen the mirred action is used on a classful egress qdisc and a packet is\nmirrored or redirected to self we hit a qdisc lock deadlock.\nSee trace below.\r\n\r\n[..... other info removed for brevity....]\n[   82.890906]\n[   82.890906] ============================================\n[   82.890906] WARNING: possible recursive locking detected\n[   82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G        W\n[   82.890906] --------------------------------------------\n[   82.890906] ping/418 is trying to acquire lock:\n[   82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[   82.890906]\n[   82.890906] but task is already holding lock:\n[   82.890906] ffff888006994110 (\u0026amp;sch-\u0026gt;q.lock){+.-.}-{3:3}, at:\n__dev_queue_xmit+0x1778/0x3550\n[   82.890906]\n[   82.890906] other info that might help us debug this:\n[   82.890906]  Possible unsafe locking scenario:\n[   82.890906]\n[   82.890906]        CPU0\n[   82.890906]        ----\n[   82.890906]   lock(\u0026amp;sch-\u0026gt;q.lock);\n[   82.890906]   lock(\u0026amp;sch-\u0026gt;q.lock);\n[   82.890906]\n[   82.890906]  *** DEADLOCK ***\n[   82.890906]\n[..... other info removed for brevity....]\r\n\r\nExample setup (eth0-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n     action mirred egress redirect dev eth0\r\n\r\nAnother example(eth0-\u0026gt;eth1-\u0026gt;eth0) to recreate\ntc qdisc add dev eth0 root handle 1: htb default 30\ntc filter add dev eth0 handle 1: protocol ip prio 2 matchall \\\n     action mirred egress redirect dev eth1\r\n\r\ntc qdisc add dev eth1 root handle 1: htb default 30\ntc filter add dev eth1 handle 1: protocol ip prio 2 matchall \\\n     action mirred egress redirect dev eth0\r\n\r\nWe fix this by adding an owner field (CPU id) to struct Qdisc set after\nroot qdisc is entered. When the softirq enters it a second time, if the\nqdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: fix memleak in map from abort path\r\n\r\nThe delete set command does not rely on the transaction object for\nelement removal, therefore, a combination of delete element + delete set\nfrom the abort path could result in restoring twice the refcount of the\nmapping.\r\n\r\nCheck for inactive element in the next generation for the delete element\ncommand in the abort path, skip restoring state if next generation bit\nhas been already cleared. This is similar to the activate logic using\nthe set walk iterator.\r\n\r\n[ 6170.286929] ------------[ cut here ]------------\n[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287071] Modules linked in: [...]\n[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365\n[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.287886] Code: df 48 8d 7d 58 e8 69 2e 3b df 48 8b 7d 58 e8 80 1b 37 df 48 8d 7d 68 e8 57 2e 3b df 48 8b 7d 68 e8 6e 1b 37 df 48 89 ef eb c4 \u0026lt;0f\u0026gt; 0b 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 0f\n[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202\n[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000\n[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750\n[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55\n[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10\n[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100\n[ 6170.287940] FS:  0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000\n[ 6170.287948] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0\n[ 6170.287962] Call Trace:\n[ 6170.287967]  \u0026lt;TASK\u0026gt;\n[ 6170.287973]  ? __warn+0x9f/0x1a0\n[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092]  ? report_bug+0x1b1/0x1e0\n[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288092]  ? report_bug+0x1b1/0x1e0\n[ 6170.288104]  ? handle_bug+0x3c/0x70\n[ 6170.288112]  ? exc_invalid_op+0x17/0x40\n[ 6170.288120]  ? asm_exc_invalid_op+0x1a/0x20\n[ 6170.288132]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288243]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]\n[ 6170.288366]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]\n[ 6170.288483]  nf_tables_trans_destroy_work+0x588/0x590 [nf_tables](CVE-2024-27011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/rds: fix WARNING in rds_conn_connect_if_down\r\n\r\nIf connection isn\u0026apos;t established yet, get_mr() will fail, trigger connection after\nget_mr().(CVE-2024-27024)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: spi-mt65xx: Fix NULL pointer access in interrupt handler\r\n\r\nThe TX buffer in spi_transfer can be a NULL pointer, so the interrupt\nhandler may end up writing to the invalid memory and cause crashes.\r\n\r\nAdd a check to trans-\u0026gt;tx_buf before using it.(CVE-2024-27028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nclk: zynq: Prevent null pointer dereference caused by kmalloc failure\r\n\r\nThe kmalloc() in zynq_clk_setup() will return null if the\nphysical memory has run out. As a result, if we use snprintf()\nto write data to the null address, the null pointer dereference\nbug will happen.\r\n\r\nThis patch uses a stack variable to replace the kmalloc().(CVE-2024-27037)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnfp: flower: handle acti_netdevs allocation failure\r\n\r\nThe kmalloc_array() in nfp_fl_lag_do_work() will return null, if\nthe physical memory has run out. As a result, if we dereference\nthe acti_netdevs, the null pointer dereference bugs will happen.\r\n\r\nThis patch adds a check to judge whether allocation failure occurs.\nIf it happens, the delayed work will be rescheduled and try again.(CVE-2024-27046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get\u0026apos;s return value\r\n\r\ncpufreq_cpu_get may return NULL. To avoid NULL-dereference check it\nand return 0 in case of error.\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27051)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ns390/dasd: fix double module refcount decrement\r\n\r\nOnce the discipline is associated with the device, deleting the device\ntakes care of decrementing the module\u0026apos;s refcount.  Doing it manually on\nthis error path causes refcount to artificially decrease on each error\nwhile it should just stay the same.(CVE-2024-27054)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nUSB: usb-storage: Prevent divide-by-0 error in isd200_ata_command\r\n\r\nThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS values\nin the ATA ID information to calculate cylinder and head values when\ncreating a CDB for READ or WRITE commands.  The calculation involves\ndivision and modulus operations, which will cause a crash if either of\nthese values is 0.  While this never happens with a genuine device, it\ncould happen with a flawed or subversive emulation, as reported by the\nsyzbot fuzzer.\r\n\r\nProtect against this possibility by refusing to bind to the device if\neither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device\u0026apos;s ID\ninformation is 0.  This requires isd200_Initialization() to return a\nnegative error code when initialization fails; currently it always\nreturns 0 (even when there is an error).(CVE-2024-27059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnouveau: lock the client object tree.\r\n\r\nIt appears the client object tree has no locking unless I\u0026apos;ve missed\nsomething else. Fix races around adding/removing client objects,\nmostly vram bar mappings.\r\n\r\n 4562.099306] general protection fault, probably for non-canonical address 0x6677ed422bceb80c: 0000 [#1] PREEMPT SMP PTI\n[ 4562.099314] CPU: 2 PID: 23171 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27\n[ 4562.099324] Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021\n[ 4562.099330] RIP: 0010:nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099503] Code: 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 48 89 f8 48 85 f6 74 39 48 8b 87 a0 00 00 00 48 85 c0 74 12 \u0026lt;48\u0026gt; 8b 48 f8 48 39 ce 73 15 48 8b 40 10 48 85 c0 75 ee 48 c7 c0 fe\n[ 4562.099506] RSP: 0000:ffffa94cc420bbf8 EFLAGS: 00010206\n[ 4562.099512] RAX: 6677ed422bceb814 RBX: ffff98108791f400 RCX: ffff9810f26b8f58\n[ 4562.099517] RDX: 0000000000000000 RSI: ffff9810f26b9158 RDI: ffff98108791f400\n[ 4562.099519] RBP: ffff9810f26b9158 R08: 0000000000000000 R09: 0000000000000000\n[ 4562.099521] R10: ffffa94cc420bc48 R11: 0000000000000001 R12: ffff9810f02a7cc0\n[ 4562.099526] R13: 0000000000000000 R14: 00000000000000ff R15: 0000000000000007\n[ 4562.099528] FS:  00007f629c5017c0(0000) GS:ffff98142c700000(0000) knlGS:0000000000000000\n[ 4562.099534] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\n[ 4562.099536] CR2: 00007f629a882000 CR3: 000000017019e004 CR4: 00000000003706f0\n[ 4562.099541] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\n[ 4562.099542] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400\n[ 4562.099544] Call Trace:\n[ 4562.099555]  \u0026lt;TASK\u0026gt;\n[ 4562.099573]  ? die_addr+0x36/0x90\n[ 4562.099583]  ? exc_general_protection+0x246/0x4a0\n[ 4562.099593]  ? asm_exc_general_protection+0x26/0x30\n[ 4562.099600]  ? nvkm_object_search+0x1d/0x70 [nouveau]\n[ 4562.099730]  nvkm_ioctl+0xa1/0x250 [nouveau]\n[ 4562.099861]  nvif_object_map_handle+0xc8/0x180 [nouveau]\n[ 4562.099986]  nouveau_ttm_io_mem_reserve+0x122/0x270 [nouveau]\n[ 4562.100156]  ? dma_resv_test_signaled+0x26/0xb0\n[ 4562.100163]  ttm_bo_vm_fault_reserved+0x97/0x3c0 [ttm]\n[ 4562.100182]  ? __mutex_unlock_slowpath+0x2a/0x270\n[ 4562.100189]  nouveau_ttm_fault+0x69/0xb0 [nouveau]\n[ 4562.100356]  __do_fault+0x32/0x150\n[ 4562.100362]  do_fault+0x7c/0x560\n[ 4562.100369]  __handle_mm_fault+0x800/0xc10\n[ 4562.100382]  handle_mm_fault+0x17c/0x3e0\n[ 4562.100388]  do_user_addr_fault+0x208/0x860\n[ 4562.100395]  exc_page_fault+0x7f/0x200\n[ 4562.100402]  asm_exc_page_fault+0x26/0x30\n[ 4562.100412] RIP: 0033:0x9b9870\n[ 4562.100419] Code: 85 a8 f7 ff ff 8b 8d 80 f7 ff ff 89 08 e9 18 f2 ff ff 0f 1f 84 00 00 00 00 00 44 89 32 e9 90 fa ff ff 0f 1f 84 00 00 00 00 00 \u0026lt;44\u0026gt; 89 32 e9 f8 f1 ff ff 0f 1f 84 00 00 00 00 00 66 44 89 32 e9 e7\n[ 4562.100422] RSP: 002b:00007fff9ba2dc70 EFLAGS: 00010246\n[ 4562.100426] RAX: 0000000000000004 RBX: 000000000dd65e10 RCX: 000000fff0000000\n[ 4562.100428] RDX: 00007f629a882000 RSI: 00007f629a882000 RDI: 0000000000000066\n[ 4562.100432] RBP: 00007fff9ba2e570 R08: 0000000000000000 R09: 0000000123ddf000\n[ 4562.100434] R10: 0000000000000001 R11: 0000000000000246 R12: 000000007fffffff\n[ 4562.100436] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\n[ 4562.100446]  \u0026lt;/TASK\u0026gt;\n[ 4562.100448] Modules linked in: nf_conntrack_netbios_ns nf_conntrack_broadcast nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_inet nf_reject_ipv4 nf_reject_ipv6 nft_reject nft_ct nft_chain_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 ip_set nf_tables libcrc32c nfnetlink cmac bnep sunrpc iwlmvm intel_rapl_msr intel_rapl_common snd_sof_pci_intel_cnl x86_pkg_temp_thermal intel_powerclamp snd_sof_intel_hda_common mac80211 coretemp snd_soc_acpi_intel_match kvm_intel snd_soc_acpi snd_soc_hdac_hda snd_sof_pci snd_sof_xtensa_dsp snd_sof_intel_hda_mlink \n---truncated---(CVE-2024-27062)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: usbtv: Remove useless locks in usbtv_video_free()\r\n\r\nRemove locks calls in usbtv_video_free() because\nare useless and may led to a deadlock as reported here:\nhttps://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000\nAlso remove usbtv_stop() call since it will be called when\nunregistering the device.\r\n\r\nBefore \u0026apos;c838530d230b\u0026apos; this issue would only be noticed if you\ndisconnect while streaming and now it is noticeable even when\ndisconnecting while not streaming.\r\n\r\n\n[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ttpci: fix two memleaks in budget_av_attach\r\n\r\nWhen saa7146_register_device and saa7146_vv_init fails, budget_av_attach\nshould free the resources it allocates, like the error-handling of\nttpci_budget_init does. Besides, there are two fixme comment refers to\nsuch deallocations.(CVE-2024-27073)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: dvb-frontends: avoid stack overflow warnings with clang\r\n\r\nA previous patch worked around a KASAN issue in stv0367, now a similar\nproblem showed up with clang:\r\n\r\ndrivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in \u0026apos;stv0367ter_set_frontend\u0026apos; [-Werror,-Wframe-larger-than]\n 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)\r\n\r\nRework the stv0367_writereg() function to be simpler and mark both\nregister access functions as noinline_for_stack so the temporary\ni2c_msg structures do not get duplicated on the stack when KASAN_STACK\nis enabled.(CVE-2024-27075)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity\r\n\r\nThe entity-\u0026gt;name (i.e. name) is allocated in v4l2_m2m_register_entity\nbut isn\u0026apos;t freed in its following error-handling paths. This patch\nadds such deallocation to prevent memleak of entity-\u0026gt;name.(CVE-2024-27077)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: v4l2-tpg: fix some memleaks in tpg_alloc\r\n\r\nIn tpg_alloc, resources should be deallocated in each and every\nerror-handling paths, since they are allocated in for statements.\nOtherwise there would be memleaks because tpg_free is called only when\ntpg_alloc return 0.(CVE-2024-27078)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nSUNRPC: fix some memleaks in gssx_dec_option_array\r\n\r\nThe creds and oa-\u0026gt;data need to be freed in the error-handling paths after\ntheir allocation. So this patch add these deallocations in the\ncorresponding paths.(CVE-2024-27388)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nft_flow_offload: reset dst in route object after setting up flow\r\n\r\ndst is transferred to the flow object, route object does not own it\nanymore.  Reset dst in route object, otherwise if flow_offload_add()\nfails, error path releases dst twice, leading to a refcount underflow.(CVE-2024-27403)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetrom: Fix data-races around sysctl_net_busy_read\r\n\r\nWe need to protect the reader reading the sysctl value because the\nvalue can be changed concurrently.(CVE-2024-27419)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)\r\n\r\nRejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27428)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndm snapshot: fix lockup in dm_exception_table_exit\r\n\r\nThere was reported lockup when we exit a snapshot with many exceptions.\nFix this by adding \u0026quot;cond_resched\u0026quot; to the loop that frees the exceptions.(CVE-2024-35805)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsoc: fsl: qbman: Always disable interrupts when taking cgr_lock\r\n\r\nsmp_call_function_single disables IRQs when executing the callback. To\nprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.\nThis is already done by qman_update_cgr and qman_delete_cgr; fix the\nother lockers.(CVE-2024-35806)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversion\r\n\r\nThe first kiocb_set_cancel_fn() argument may point at a struct kiocb\nthat is not embedded inside struct aio_kiocb. With the current code,\ndepending on the compiler, the req-\u0026gt;ki_ctx read happens either before\nthe IOCB_AIO_RW test or after that test. Move the req-\u0026gt;ki_ctx read such\nthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5e: fix a double-free in arfs_create_groups\r\n\r\nWhen `in` allocated by kvzalloc fails, arfs_create_groups will free\nft-\u0026gt;g and return an error. However, arfs_create_table, the only caller of\narfs_create_groups, will hold this error and call to\nmlx5e_destroy_flow_table, in which the ft-\u0026gt;g will be freed again.(CVE-2024-35835)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nipv6: Fix infinite recursion in fib6_dump_done().\r\n\r\nsyzkaller reported infinite recursive calls of fib6_dump_done() during\nnetlink socket destruction.  [1]\r\n\r\nFrom the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then\nthe response was generated.  The following recvmmsg() resumed the dump\nfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due\nto the fault injection.  [0]\r\n\r\n  12:01:34 executing program 3:\n  r0 = socket$nl_route(0x10, 0x3, 0x0)\n  sendmsg$nl_route(r0, ... snip ...)\n  recvmmsg(r0, ... snip ...) (fail_nth: 8)\r\n\r\nHere, fib6_dump_done() was set to nlk_sk(sk)-\u0026gt;cb.done, and the next call\nof inet6_dump_fib() set it to nlk_sk(sk)-\u0026gt;cb.args[3].  syzkaller stopped\nreceiving the response halfway through, and finally netlink_sock_destruct()\ncalled nlk_sk(sk)-\u0026gt;cb.done().\r\n\r\nfib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-\u0026gt;cb.done() if it\nis still not NULL.  fib6_dump_end() rewrites nlk_sk(sk)-\u0026gt;cb.done() by\nnlk_sk(sk)-\u0026gt;cb.args[3], but it has the same function, not NULL, calling\nitself recursively and hitting the stack guard page.\r\n\r\nTo avoid the issue, let\u0026apos;s set the destructor after kzalloc().\r\n\r\n[0]:\nFAULT_INJECTION: forcing a failure.\nname failslab, interval 1, probability 0, space 0, times 0\nCPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nCall Trace:\n \u0026lt;TASK\u0026gt;\n dump_stack_lvl (lib/dump_stack.c:117)\n should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)\n should_failslab (mm/slub.c:3733)\n kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)\n inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)\n rtnl_dump_all (net/core/rtnetlink.c:4029)\n netlink_dump (net/netlink/af_netlink.c:2269)\n netlink_recvmsg (net/netlink/af_netlink.c:1988)\n ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)\n ___sys_recvmsg (net/socket.c:2846)\n do_recvmmsg (net/socket.c:2943)\n __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)\r\n\r\n[1]:\nBUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)\nstack guard page: 0000 [#1] PREEMPT SMP KASAN\nCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014\nWorkqueue: events netlink_sock_destruct_work\nRIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)\nCode: 3c 24 e8 f3 e9 51 fd e9 28 fd ff ff 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 f3 0f 1e fa 41 57 41 56 41 55 41 54 55 48 89 fd \u0026lt;53\u0026gt; 48 8d 5d 60 e8 b6 4d 07 fd 48 89 da 48 b8 00 00 00 00 00 fc ff\nRSP: 0018:ffffc9000d980000 EFLAGS: 00010293\nRAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3\nRDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358\nRBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000\nR13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68\nFS:  0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0\nPKRU: 55555554\nCall Trace:\n \u0026lt;#DF\u0026gt;\n \u0026lt;/#DF\u0026gt;\n \u0026lt;TASK\u0026gt;\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n ...\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))\n netlink_sock_destruct (net/netlink/af_netlink.c:401)\n __sk_destruct (net/core/sock.c:2177 (discriminator 2))\n sk_destruct (net/core/sock.c:2224)\n __sk_free (net/core/sock.c:2235)\n sk_free (net/core/sock.c:2246)\n process_one_work (kernel/workqueue.c:3259)\n worker_thread (kernel/workqueue.c:3329 kernel/workqueue.\n---truncated---(CVE-2024-35886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()\r\n\r\nnft_unregister_flowtable_type() within nf_flow_inet_module_exit() can\nconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().\nAnd thhere is not any protection when iterate over nf_tables_flowtables\nlist in __nft_flowtable_type_get(). Therefore, there is pertential\ndata-race of nf_tables_flowtables list entry.\r\n\r\nUse list_for_each_entry_rcu() to iterate over nf_tables_flowtables list\nin __nft_flowtable_type_get(), and use rcu_read_lock() in the caller\nnft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfbmon: prevent division by zero in fb_videomode_from_videomode()\r\n\r\nThe expression htotal * vtotal can have a zero value on\noverflow. It is necessary to prevent division by zero like in\nfb_var_to_videomode().\r\n\r\nFound by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()\r\n\r\nThe call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return an\nunsuccessful status.  In such cases, the elsiocb is not issued, the\ncompletion is not called, and thus the elsiocb resource is leaked.\r\n\r\nCheck return value after calling lpfc_sli4_resume_rpi() and conditionally\nrelease the elsiocb resource.(CVE-2024-35930)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()\r\n\r\nThe unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,\nas it could be caused only by two impossible conditions:\r\n\r\n- at first the search key is set up to look for a chunk tree item, with\n  offset -1, this is an inexact search and the key-\u0026gt;offset will contain\n  the correct offset upon a successful search, a valid chunk tree item\n  cannot have an offset -1\r\n\r\n- after first successful search, the found_key corresponds to a chunk\n  item, the offset is decremented by 1 before the next loop, it\u0026apos;s\n  impossible to find a chunk item there due to alignment and size\n  constraints(CVE-2024-35936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/client: Fully protect modes[] with dev-\u0026gt;mode_config.mutex\r\n\r\nThe modes[] array contains pointers to modes on the connectors\u0026apos;\nmode lists, which are protected by dev-\u0026gt;mode_config.mutex.\nThus we need to extend modes[] the same protection or by the\ntime we use it the elements may already be pointing to\nfreed/reused memory.(CVE-2024-35950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING\r\n\r\nsyzbot reported an illegal copy in xsk_setsockopt() [1]\r\n\r\nMake sure to validate setsockopt() @optlen parameter.\r\n\r\n[1]\r\n\r\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]\n BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\nRead of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549\r\n\r\nCPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024\nCall Trace:\n \u0026lt;TASK\u0026gt;\n  __dump_stack lib/dump_stack.c:88 [inline]\n  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114\n  print_address_description mm/kasan/report.c:377 [inline]\n  print_report+0x169/0x550 mm/kasan/report.c:488\n  kasan_report+0x143/0x180 mm/kasan/report.c:601\n  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]\n  copy_from_sockptr include/linux/sockptr.h:55 [inline]\n  xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420\n  do_sock_setsockopt+0x3af/0x720 net/socket.c:2311\n  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n  __do_sys_setsockopt net/socket.c:2343 [inline]\n  __se_sys_setsockopt net/socket.c:2340 [inline]\n  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\nRIP: 0033:0x7fb40587de69\nCode: 28 00 00 00 75 05 48 83 c4 28 c3 e8 e1 20 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48\nRSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036\nRAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69\nRDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006\nRBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000\nR10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000\nR13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08\n \u0026lt;/TASK\u0026gt;\r\n\r\nAllocated by task 7549:\n  kasan_save_stack mm/kasan/common.c:47 [inline]\n  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68\n  poison_kmalloc_redzone mm/kasan/common.c:370 [inline]\n  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387\n  kasan_kmalloc include/linux/kasan.h:211 [inline]\n  __do_kmalloc_node mm/slub.c:3966 [inline]\n  __kmalloc+0x233/0x4a0 mm/slub.c:3979\n  kmalloc include/linux/slab.h:632 [inline]\n  __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869\n  do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293\n  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334\n  __do_sys_setsockopt net/socket.c:2343 [inline]\n  __se_sys_setsockopt net/socket.c:2340 [inline]\n  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340\n do_syscall_64+0xfb/0x240\n entry_SYSCALL_64_after_hwframe+0x6d/0x75\r\n\r\nThe buggy address belongs to the object at ffff888028c6cde0\n which belongs to the cache kmalloc-8 of size 8\nThe buggy address is located 1 bytes to the right of\n allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)\r\n\r\nThe buggy address belongs to the physical page:\npage:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c\nanon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)\npage_type: 0xffffffff()\nraw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001\nraw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000\npage dumped because: kasan: bad access detected\npage_owner tracks the page as allocated\npage last allocated via order 0, migratetype Unmovable, gfp_mask 0x112cc0(GFP_USER|__GFP_NOWARN|__GFP_NORETRY), pid 6648, tgid 6644 (syz-executor.0), ts 133906047828, free_ts 133859922223\n  set_page_owner include/linux/page_owner.h:31 [inline]\n  post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533\n  prep_new_page mm/page_alloc.c:\n---truncated---(CVE-2024-35976)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nHID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up\r\n\r\nThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.\nHowever, this is not necessary, because I2C core already has its own\nlocking for that.\r\n\r\nMore importantly, this flag can cause a lock-up: if the flag is set in\ni2c_hid_xfer() and an interrupt happens, the interrupt handler\n(i2c_hid_irq) will check this flag and return immediately without doing\nanything, then the interrupt handler will be invoked again in an\ninfinite loop.\r\n\r\nSince interrupt handler is an RT task, it takes over the CPU and the\nflag-clearing task never gets scheduled, thus we have a lock-up.\r\n\r\nDelete this unnecessary flag.(CVE-2024-35997)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2405.5.0.0251.oe1"}]}],"ecosystem_specific":{"aarch64":["kernel-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","kernel-debugsource-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","perf-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","kernel-tools-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","bpftool-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","kernel-tools-devel-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","kernel-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","python3-perf-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","python3-perf-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","bpftool-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","python2-perf-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","perf-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","kernel-source-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","kernel-devel-4.19.90-2405.5.0.0251.oe1.aarch64.rpm","python2-perf-debuginfo-4.19.90-2405.5.0.0251.oe1.aarch64.rpm"],"src":["kernel-4.19.90-2405.5.0.0251.oe1.src.rpm"],"x86_64":["bpftool-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","kernel-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","python2-perf-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","perf-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","bpftool-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","kernel-tools-devel-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","kernel-debugsource-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","kernel-devel-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","kernel-tools-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","python2-perf-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","kernel-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","perf-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","python3-perf-debuginfo-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","kernel-source-4.19.90-2405.5.0.0251.oe1.x86_64.rpm","python3-perf-4.19.90-2405.5.0.0251.oe1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1677"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47269"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47284"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47335"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47393"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47455"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47473"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47497"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48695"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48697"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48702"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48704"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48710"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52650"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52652"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52653"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52656"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52683"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52691"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52698"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52813"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52817"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52818"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52835"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52840"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52847"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52867"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52868"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26955"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26956"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26957"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26958"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26960"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26961"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26965"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26966"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26969"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26974"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26976"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26982"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26993"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26994"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26996"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-26999"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27000"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27001"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27008"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27010"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27011"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27024"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27028"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27037"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27046"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27051"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27054"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27059"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27062"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27072"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27073"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27075"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27077"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27078"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27388"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27403"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27419"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27426"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27427"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27428"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35805"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35806"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35815"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35835"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35886"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35898"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35922"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35930"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35936"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35950"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35976"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35997"}],"database_specific":{"severity":"High"}}