{"schema_version":"1.7.2","id":"OESA-2024-2220","modified":"2024-10-12T11:09:18Z","published":"2024-10-12T11:09:18Z","upstream":["CVE-2024-39482","CVE-2024-41030","CVE-2024-41095","CVE-2024-43900","CVE-2024-44958","CVE-2024-44982","CVE-2024-45008","CVE-2024-45016","CVE-2024-46673","CVE-2024-46674","CVE-2024-46679","CVE-2024-46681","CVE-2024-46695","CVE-2024-46707","CVE-2024-46721","CVE-2024-46725","CVE-2024-46726","CVE-2024-46732","CVE-2024-46737","CVE-2024-46738","CVE-2024-46739","CVE-2024-46740","CVE-2024-46743","CVE-2024-46750","CVE-2024-46753","CVE-2024-46755","CVE-2024-46756","CVE-2024-46758","CVE-2024-46759","CVE-2024-46761","CVE-2024-46771","CVE-2024-46777","CVE-2024-46780","CVE-2024-46781","CVE-2024-46791","CVE-2024-46798","CVE-2024-46804","CVE-2024-46814","CVE-2024-46816","CVE-2024-46818","CVE-2024-46821","CVE-2024-46829","CVE-2024-46833","CVE-2024-46841","CVE-2024-46844","CVE-2024-46849","CVE-2024-46857"],"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\nbcache: fix variable length array abuse in btree_iter\r\n\r\nbtree_iter is used in two ways: either allocated on the stack with a\nfixed size MAX_BSETS, or from a mempool with a dynamic size based on the\nspecific cache set. Previously, the struct had a fixed-length array of\nsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sized\niterators, which causes UBSAN to complain.\r\n\r\nThis patch uses the same approach as in bcachefs\u0026apos;s sort_iter and splits\nthe iterator into a btree_iter with a flexible array member and a\nbtree_iter_stack which embeds a btree_iter as well as a fixed-length\ndata array.(CVE-2024-39482)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nksmbd: discard write access to the directory open\r\n\r\nmay_open() does not allow a directory to be opened with the write access.\nHowever, some writing flags set by client result in adding write access\non server, making ksmbd incompatible with FUSE file system. Simply, let\u0026apos;s\ndiscard the write access when opening a directory.\r\n\r\nlist_add corruption. next is NULL.\n------------[ cut here ]------------\nkernel BUG at lib/list_debug.c:26!\npc : __list_add_valid+0x88/0xbc\nlr : __list_add_valid+0x88/0xbc\nCall trace:\n__list_add_valid+0x88/0xbc\nfuse_finish_open+0x11c/0x170\nfuse_open_common+0x284/0x5e8\nfuse_dir_open+0x14/0x24\ndo_dentry_open+0x2a4/0x4e0\ndentry_open+0x50/0x80\nsmb2_open+0xbe4/0x15a4\nhandle_ksmbd_work+0x478/0x5ec\nprocess_one_work+0x1b4/0x448\nworker_thread+0x25c/0x430\nkthread+0x104/0x1d4\nret_from_fork+0x10/0x20(CVE-2024-41030)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modes\r\n\r\nIn nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() is\nassigned to mode, which will lead to a possible NULL pointer dereference\non failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-41095)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: xc2028: avoid use-after-free in load_firmware_cb()\r\n\r\nsyzkaller reported use-after-free in load_firmware_cb() [1].\nThe reason is because the module allocated a struct tuner in tuner_probe(),\nand then the module initialization failed, the struct tuner was released.\nA worker which created during module initialization accesses this struct\ntuner later, it caused use-after-free.\r\n\r\nThe process is as follows:\r\n\r\ntask-6504           worker_thread\ntuner_probe                             \u0026lt;= alloc dvb_frontend [2]\n...\nrequest_firmware_nowait                 \u0026lt;= create a worker\n...\ntuner_remove                            \u0026lt;= free dvb_frontend\n...\n                    request_firmware_work_func  \u0026lt;= the firmware is ready\n                    load_firmware_cb    \u0026lt;= but now the dvb_frontend has been freed\r\n\r\nTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it is\nnull, report a warning and just return.\r\n\r\n[1]:\n    ==================================================================\n     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0\n     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504\r\n\r\n     Call trace:\n      load_firmware_cb+0x1310/0x17a0\n      request_firmware_work_func+0x128/0x220\n      process_one_work+0x770/0x1824\n      worker_thread+0x488/0xea0\n      kthread+0x300/0x430\n      ret_from_fork+0x10/0x20\r\n\r\n     Allocated by task 6504:\n      kzalloc\n      tuner_probe+0xb0/0x1430\n      i2c_device_probe+0x92c/0xaf0\n      really_probe+0x678/0xcd0\n      driver_probe_device+0x280/0x370\n      __device_attach_driver+0x220/0x330\n      bus_for_each_drv+0x134/0x1c0\n      __device_attach+0x1f4/0x410\n      device_initial_probe+0x20/0x30\n      bus_probe_device+0x184/0x200\n      device_add+0x924/0x12c0\n      device_register+0x24/0x30\n      i2c_new_device+0x4e0/0xc44\n      v4l2_i2c_new_subdev_board+0xbc/0x290\n      v4l2_i2c_new_subdev+0xc8/0x104\n      em28xx_v4l2_init+0x1dd0/0x3770\r\n\r\n     Freed by task 6504:\n      kfree+0x238/0x4e4\n      tuner_remove+0x144/0x1c0\n      i2c_device_remove+0xc8/0x290\n      __device_release_driver+0x314/0x5fc\n      device_release_driver+0x30/0x44\n      bus_remove_device+0x244/0x490\n      device_del+0x350/0x900\n      device_unregister+0x28/0xd0\n      i2c_unregister_device+0x174/0x1d0\n      v4l2_device_unregister+0x224/0x380\n      em28xx_v4l2_init+0x1d90/0x3770\r\n\r\n     The buggy address belongs to the object at ffff8000d7ca2000\n      which belongs to the cache kmalloc-2k of size 2048\n     The buggy address is located 776 bytes inside of\n      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)\n     The buggy address belongs to the page:\n     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0\n     flags: 0x7ff800000000100(slab)\n     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000\n     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000\n     page dumped because: kasan: bad access detected\r\n\r\n     Memory state around the buggy address:\n      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     \u0026gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n                           ^\n      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb\n     ==================================================================\r\n\r\n[2]\n    Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsched/smt: Fix unbalance sched_smt_present dec/inc\r\n\r\nI got the following warn report while doing stress test:\r\n\r\njump label: negative count!\nWARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __static_key_slow_dec_cpuslocked+0x16/0x70\n sched_cpu_deactivate+0x26e/0x2a0\n cpuhp_invoke_callback+0x3ad/0x10d0\n cpuhp_thread_fun+0x3f5/0x680\n smpboot_thread_fn+0x56d/0x8d0\n kthread+0x309/0x400\n ret_from_fork+0x41/0x70\n ret_from_fork_asm+0x1b/0x30\n \u0026lt;/TASK\u0026gt;\r\n\r\nBecause when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),\nthe cpu offline failed, but sched_smt_present is decremented before\ncalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, so\nfix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dpu: cleanup FB if dpu_format_populate_layout fails\r\n\r\nIf the dpu_format_populate_layout() fails, then FB is prepared, but not\ncleaned up. This ends up leaking the pin_count on the GEM object and\ncauses a splat during DRM file closure:\r\n\r\nmsm_obj-\u0026gt;pin_count\nWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc\n[...]\nCall trace:\n update_lru_locked+0xc4/0xcc\n put_pages+0xac/0x100\n msm_gem_free_object+0x138/0x180\n drm_gem_object_free+0x1c/0x30\n drm_gem_object_handle_put_unlocked+0x108/0x10c\n drm_gem_object_release_handle+0x58/0x70\n idr_for_each+0x68/0xec\n drm_gem_release+0x28/0x40\n drm_file_free+0x174/0x234\n drm_release+0xb0/0x160\n __fput+0xc0/0x2c8\n __fput_sync+0x50/0x5c\n __arm64_sys_close+0x38/0x7c\n invoke_syscall+0x48/0x118\n el0_svc_common.constprop.0+0x40/0xe0\n do_el0_svc+0x1c/0x28\n el0_svc+0x4c/0x120\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194\nirq event stamp: 129818\nhardirqs last  enabled at (129817): [\u0026lt;ffffa5f6d953fcc0\u0026gt;] console_unlock+0x118/0x124\nhardirqs last disabled at (129818): [\u0026lt;ffffa5f6da7dcf04\u0026gt;] el1_dbg+0x24/0x8c\nsoftirqs last  enabled at (129808): [\u0026lt;ffffa5f6d94afc18\u0026gt;] handle_softirqs+0x4c8/0x4e8\nsoftirqs last disabled at (129785): [\u0026lt;ffffa5f6d94105e4\u0026gt;] __do_softirq+0x14/0x20\r\n\r\nPatchwork: https://patchwork.freedesktop.org/patch/600714/(CVE-2024-44982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nInput: MT - limit max slots\r\n\r\nsyzbot is reporting too large allocation at input_mt_init_slots(), for\nnum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).\r\n\r\nSince nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnetem: fix return value if duplicate enqueue fails\r\n\r\nThere is a bug in netem_enqueue() introduced by\ncommit 5845f706388a (\u0026quot;net: netem: fix skb length BUG_ON in __skb_to_sgvec\u0026quot;)\nthat can lead to a use-after-free.\r\n\r\nThis commit made netem_enqueue() always return NET_XMIT_SUCCESS\nwhen a packet is duplicated, which can cause the parent qdisc\u0026apos;s q.qlen\nto be mistakenly incremented. When this happens qlen_notify() may be\nskipped on the parent during destruction, leaving a dangling pointer\nfor some classful qdiscs like DRR.\r\n\r\nThere are two ways for the bug happen:\r\n\r\n- If the duplicated packet is dropped by rootq-\u0026gt;enqueue() and then\n  the original packet is also dropped.\n- If rootq-\u0026gt;enqueue() sends the duplicated packet to a different qdisc\n  and the original packet is dropped.\r\n\r\nIn both cases NET_XMIT_SUCCESS is returned even though no packets\nare enqueued at the netem qdisc.\r\n\r\nThe fix is to defer the enqueue of the duplicate packet until after\nthe original packet has been guaranteed to return NET_XMIT_SUCCESS.(CVE-2024-45016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: aacraid: Fix double-free on probe failure\r\n\r\naac_probe_one() calls hardware-specific init functions through the\naac_driver_ident::init pointer, all of which eventually call down to\naac_init_adapter().\r\n\r\nIf aac_init_adapter() fails after allocating memory for aac_dev::queues,\nit frees the memory but does not clear that member.\r\n\r\nAfter the hardware-specific init function returns an error,\naac_probe_one() goes down an error path that frees the memory pointed to\nby aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: dwc3: st: fix probed platform device ref count on probe error path\r\n\r\nThe probe function never performs any paltform device allocation, thus\nerror path \u0026quot;undo_platform_dev_alloc\u0026quot; is entirely bogus.  It drops the\nreference count from the platform device being probed.  If error path is\ntriggered, this will lead to unbalanced device reference counts and\npremature release of device resources, thus possible use-after-free when\nreleasing remaining devm-managed resources.(CVE-2024-46674)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nethtool: check device is present when getting link settings\r\n\r\nA sysfs reader can race with a device reset or removal, attempting to\nread device state when the device is not actually present. eg:\r\n\r\n     [exception RIP: qed_get_current_link+17]\n  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]\n  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3\n #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4\n #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300\n #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c\n #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b\n #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3\n #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1\n #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f\n #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb\r\n\r\n crash\u0026gt; struct net_device.state ffff9a9d21336000\n    state = 5,\r\n\r\nstate 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).\nThe device is not present, note lack of __LINK_STATE_PRESENT (0b10).\r\n\r\nThis is the same sort of panic as observed in commit 4224cfd7fb65\n(\u0026quot;net-sysfs: add check for netdevice being present to speed_show\u0026quot;).\r\n\r\nThere are many other callers of __ethtool_get_link_ksettings() which\ndon\u0026apos;t have a device presence check.\r\n\r\nMove this check into ethtool to protect all callers.(CVE-2024-46679)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npktgen: use cpus_read_lock() in pg_net_init()\r\n\r\nI have seen the WARN_ON(smp_processor_id() != cpu) firing\nin pktgen_thread_worker() during tests.\r\n\r\nWe must use cpus_read_lock()/cpus_read_unlock()\naround the for_each_online_cpu(cpu) loop.\r\n\r\nWhile we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.(CVE-2024-46681)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nselinux,smack: don\u0026apos;t bypass permissions check in inode_setsecctx hook\r\n\r\nMarek Gresko reports that the root user on an NFS client is able to\nchange the security labels on files on an NFS filesystem that is\nexported with root squashing enabled.\r\n\r\nThe end of the kerneldoc comment for __vfs_setxattr_noperm() states:\r\n\r\n *  This function requires the caller to lock the inode\u0026apos;s i_mutex before it\n *  is executed. It also assumes that the caller will make the appropriate\n *  permission checks.\r\n\r\nnfsd_setattr() does do permissions checking via fh_verify() and\nnfsd_permission(), but those don\u0026apos;t do all the same permissions checks\nthat are done by security_inode_setxattr() and its related LSM hooks do.\r\n\r\nSince nfsd_setattr() is the only consumer of security_inode_setsecctx(),\nsimplest solution appears to be to replace the call to\n__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  This\nfixes the above issue and has the added benefit of causing nfsd to\nrecall conflicting delegations on a file when a client tries to change\nits security label.(CVE-2024-46695)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nKVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3\r\n\r\nOn a system with a GICv3, if a guest hasn\u0026apos;t been configured with\nGICv3 and that the host is not capable of GICv2 emulation,\na write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.\r\n\r\nWe therefore try to emulate the SGI access, only to hit a NULL\npointer as no private interrupt is allocated (no GIC, remember?).\r\n\r\nThe obvious fix is to give the guest what it deserves, in the\nshape of a UNDEF exception.(CVE-2024-46707)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\napparmor: fix possible NULL pointer dereference\r\n\r\nprofile-\u0026gt;parent-\u0026gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is made\nfrom __create_missing_ancestors(..) and \u0026apos;ent-\u0026gt;old\u0026apos; is NULL in\naa_replace_profiles(..).\nIn that case, it must return an error code and the code, -ENOENT represents\nits state that the path of its parent is not existed yet.\r\n\r\nBUG: kernel NULL pointer dereference, address: 0000000000000030\nPGD 0 P4D 0\nPREEMPT SMP PTI\nCPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24\nHardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10\nR13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000\nFS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0\nCall Trace:\n \u0026lt;TASK\u0026gt;\n ? show_regs+0x6d/0x80\n ? __die+0x24/0x80\n ? page_fault_oops+0x99/0x1b0\n ? kernelmode_fixup_or_oops+0xb2/0x140\n ? __bad_area_nosemaphore+0x1a5/0x2c0\n ? find_vma+0x34/0x60\n ? bad_area_nosemaphore+0x16/0x30\n ? do_user_addr_fault+0x2a2/0x6b0\n ? exc_page_fault+0x83/0x1b0\n ? asm_exc_page_fault+0x27/0x30\n ? aafs_create.constprop.0+0x7f/0x130\n ? aafs_create.constprop.0+0x51/0x130\n __aafs_profile_mkdir+0x3d6/0x480\n aa_replace_profiles+0x83f/0x1270\n policy_update+0xe3/0x180\n profile_load+0xbc/0x150\n ? rw_verify_area+0x47/0x140\n vfs_write+0x100/0x480\n ? __x64_sys_openat+0x55/0xa0\n ? syscall_exit_to_user_mode+0x86/0x260\n ksys_write+0x73/0x100\n __x64_sys_write+0x19/0x30\n x64_sys_call+0x7e/0x25c0\n do_syscall_64+0x7f/0x180\n entry_SYSCALL_64_after_hwframe+0x78/0x80\nRIP: 0033:0x7be9f211c574\nCode: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89\nRSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001\nRAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574\nRDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004\nRBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000\nR10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80\nR13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30\n \u0026lt;/TASK\u0026gt;\nModules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesas\nCR2: 0000000000000030\n---[ end trace 0000000000000000 ]---\nRIP: 0010:aafs_create.constprop.0+0x7f/0x130\nCode: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc \u0026lt;4d\u0026gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a ae\nRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246\nRAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000\nRBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000\nR10: 0000\n---truncated---(CVE-2024-46721)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amdgpu: Fix out-of-bounds write warning\r\n\r\nCheck the ring type value to fix the out-of-bounds\nwrite warning(CVE-2024-46725)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Ensure index calculation will not overflow\r\n\r\n[WHY \u0026amp; HOW]\nMake sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation will\nnever overflow and exceess array size.\r\n\r\nThis fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46726)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Assign linear_pitch_alignment even for VM\r\n\r\n[Description]\nAssign linear_pitch_alignment so we don\u0026apos;t cause a divide by 0\nerror in VM environments(CVE-2024-46732)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnvmet-tcp: fix kernel crash if commands allocation fails\r\n\r\nIf the commands allocation fails in nvmet_tcp_alloc_cmds()\nthe kernel crashes in nvmet_tcp_release_queue_work() because of\na NULL pointer dereference.\r\n\r\n  nvmet: failed to install queue 0 cntlid 1 ret 6\n  Unable to handle kernel NULL pointer dereference at\n         virtual address 0000000000000008\r\n\r\nFix the bug by setting queue-\u0026gt;nr_cmds to zero in case\nnvmet_tcp_alloc_cmd() fails.(CVE-2024-46737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nVMCI: Fix use-after-free when removing resource in vmci_resource_remove()\r\n\r\nWhen removing a resource from vmci_resource_table in\nvmci_resource_remove(), the search is performed using the resource\nhandle by comparing context and resource fields.\r\n\r\nIt is possible though to create two resources with different types\nbut same handle (same context and resource fields).\r\n\r\nWhen trying to remove one of the resources, vmci_resource_remove()\nmay not remove the intended one, but the object will still be freed\nas in the case of the datagram type in vmci_datagram_destroy_handle().\nvmci_resource_table will still hold a pointer to this freed resource\nleading to a use-after-free vulnerability.\r\n\r\nBUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\nBUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\nRead of size 4 at addr ffff88801c16d800 by task syz-executor197/1592\nCall Trace:\n \u0026lt;TASK\u0026gt;\n __dump_stack lib/dump_stack.c:88 [inline]\n dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106\n print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239\n __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425\n kasan_report+0x38/0x51 mm/kasan/report.c:442\n vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]\n vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147\n vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182\n ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444\n kref_put include/linux/kref.h:65 [inline]\n vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline]\n vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195\n vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143\n __fput+0x261/0xa34 fs/file_table.c:282\n task_work_run+0xf0/0x194 kernel/task_work.c:164\n tracehook_notify_resume include/linux/tracehook.h:189 [inline]\n exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187\n exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220\n __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline]\n syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313\n do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86\n entry_SYSCALL_64_after_hwframe+0x6e/0x0\r\n\r\nThis change ensures the type is also checked when removing\nthe resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nuio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescind\r\n\r\nFor primary VM Bus channels, primary_channel pointer is always NULL. This\npointer is valid only for the secondary channels. Also, rescind callback\nis meant for primary channels only.\r\n\r\nFix NULL pointer dereference by retrieving the device_obj from the parent\nfor the primary channel.(CVE-2024-46739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbinder: fix UAF caused by offsets overwrite\r\n\r\nBinder objects are processed and copied individually into the target\nbuffer during transactions. Any raw data in-between these objects is\ncopied as well. However, this raw data copy lacks an out-of-bounds\ncheck. If the raw data exceeds the data section size then the copy\noverwrites the offsets section. This eventually triggers an error that\nattempts to unwind the processed objects. However, at this point the\noffsets used to index these objects are now corrupted.\r\n\r\nUnwinding with corrupted offsets can result in decrements of arbitrary\nnodes and lead to their premature release. Other users of such nodes are\nleft with a dangling pointer triggering a use-after-free. This issue is\nmade evident by the following KASAN report (trimmed):\r\n\r\n  ==================================================================\n  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c\n  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743\r\n\r\n  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1\n  Hardware name: linux,dummy-virt (DT)\n  Call trace:\n   _raw_spin_lock+0xe4/0x19c\n   binder_free_buf+0x128/0x434\n   binder_thread_write+0x8a4/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Allocated by task 743:\n   __kmalloc_cache_noprof+0x110/0x270\n   binder_new_node+0x50/0x700\n   binder_transaction+0x413c/0x6da8\n   binder_thread_write+0x978/0x3260\n   binder_ioctl+0x18f0/0x258c\n  [...]\r\n\r\n  Freed by task 745:\n   kfree+0xbc/0x208\n   binder_thread_read+0x1c5c/0x37d4\n   binder_ioctl+0x16d8/0x258c\n  [...]\n  ==================================================================\r\n\r\nTo avoid this issue, let\u0026apos;s check that the raw data copy is within the\nboundaries of the data section.(CVE-2024-46740)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof/irq: Prevent device address out-of-bounds read in interrupt map walk\r\n\r\nWhen of_irq_parse_raw() is invoked with a device address smaller than\nthe interrupt parent node (from #address-cells property), KASAN detects\nthe following out-of-bounds read when populating the initial match table\n(dyndbg=\u0026quot;func of_irq_parse_* +p\u0026quot;):\r\n\r\n  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0\n  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2\n  OF:  intspec=4\n  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2\n  OF:  -\u0026gt; addrsize=3\n  ==================================================================\n  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0\n  Read of size 4 at addr ffffff81beca5608 by task bash/764\r\n\r\n  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1\n  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023\n  Call trace:\n   dump_backtrace+0xdc/0x130\n   show_stack+0x1c/0x30\n   dump_stack_lvl+0x6c/0x84\n   print_report+0x150/0x448\n   kasan_report+0x98/0x140\n   __asan_load4+0x78/0xa0\n   of_irq_parse_raw+0x2b8/0x8d0\n   of_irq_parse_one+0x24c/0x270\n   parse_interrupts+0xc0/0x120\n   of_fwnode_add_links+0x100/0x2d0\n   fw_devlink_parse_fwtree+0x64/0xc0\n   device_add+0xb38/0xc30\n   of_device_add+0x64/0x90\n   of_platform_device_create_pdata+0xd0/0x170\n   of_platform_bus_create+0x244/0x600\n   of_platform_notify+0x1b0/0x254\n   blocking_notifier_call_chain+0x9c/0xd0\n   __of_changeset_entry_notify+0x1b8/0x230\n   __of_changeset_apply_notify+0x54/0xe4\n   of_overlay_fdt_apply+0xc04/0xd94\n   ...\r\n\r\n  The buggy address belongs to the object at ffffff81beca5600\n   which belongs to the cache kmalloc-128 of size 128\n  The buggy address is located 8 bytes inside of\n   128-byte region [ffffff81beca5600, ffffff81beca5680)\r\n\r\n  The buggy address belongs to the physical page:\n  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4\n  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0\n  flags: 0x8000000000010200(slab|head|zone=2)\n  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300\n  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000\n  page dumped because: kasan: bad access detected\r\n\r\n  Memory state around the buggy address:\n   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n  \u0026gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n                        ^\n   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc\n   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc\n  ==================================================================\n  OF:  -\u0026gt; got it !\r\n\r\nPrevent the out-of-bounds read by copying the device address into a\nbuffer of sufficient size.(CVE-2024-46743)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nPCI: Add missing bridge lock to pci_bus_lock()\r\n\r\nOne of the true positives that the cfg_access_lock lockdep effort\nidentified is this sequence:\r\n\r\n  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70\n  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   ? __warn+0x8c/0x190\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   ? report_bug+0x1f8/0x200\n   ? handle_bug+0x3c/0x70\n   ? exc_invalid_op+0x18/0x70\n   ? asm_exc_invalid_op+0x1a/0x20\n   ? pci_bridge_secondary_bus_reset+0x5d/0x70\n   pci_reset_bus+0x1d8/0x270\n   vmd_probe+0x778/0xa10\n   pci_device_probe+0x95/0x120\r\n\r\nWhere pci_reset_bus() users are triggering unlocked secondary bus resets.\nIronically pci_bus_reset(), several calls down from pci_reset_bus(), uses\npci_bus_lock() before issuing the reset which locks everything *but* the\nbridge itself.\r\n\r\nFor the same motivation as adding:\r\n\r\n  bridge = pci_upstream_bridge(dev);\n  if (bridge)\n    pci_dev_lock(bridge);\r\n\r\nto pci_reset_function() for the \u0026quot;bus\u0026quot; and \u0026quot;cxl_bus\u0026quot; reset cases, add\npci_dev_lock() for @bus-\u0026gt;self to pci_bus_lock().\r\n\r\n[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:\nhttps://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com](CVE-2024-46750)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: handle errors from btrfs_dec_ref() properly\r\n\r\nIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This is\nincorrect, we have proper error handling here, return the error.(CVE-2024-46753)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()\r\n\r\nmwifiex_get_priv_by_id() returns the priv pointer corresponding to\nthe bss_num and bss_type, but without checking if the priv is actually\ncurrently in use.\nUnused priv pointers do not have a wiphy attached to them which can\nlead to NULL pointer dereferences further down the callstack.  Fix\nthis by returning only used priv pointers which have priv-\u0026gt;bss_mode\nset to something else than NL80211_IFTYPE_UNSPECIFIED.\r\n\r\nSaid NULL pointer dereference happened when an Accesspoint was started\nwith wpa_supplicant -i mlan0 with this config:\r\n\r\nnetwork={\n        ssid=\u0026quot;somessid\u0026quot;\n        mode=2\n        frequency=2412\n        key_mgmt=WPA-PSK WPA-PSK-SHA256\n        proto=RSN\n        group=CCMP\n        pairwise=CCMP\n        psk=\u0026quot;12345678\u0026quot;\n}\r\n\r\nWhen waiting for the AP to be established, interrupting wpa_supplicant\nwith \u0026lt;ctrl-c\u0026gt; and starting it again this happens:\r\n\r\n| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140\n| Mem abort info:\n|   ESR = 0x0000000096000004\n|   EC = 0x25: DABT (current EL), IL = 32 bits\n|   SET = 0, FnV = 0\n|   EA = 0, S1PTW = 0\n|   FSC = 0x04: level 0 translation fault\n| Data abort info:\n|   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000\n|   CM = 0, WnR = 0, TnD = 0, TagAccess = 0\n|   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0\n| user pgtable: 4k pages, 48-bit VAs, pgdp=0000000046d96000\n| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000\n| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP\n| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio\n+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs\n+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6\n| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18\n| Hardware name: somemachine (DT)\n| Workqueue: events sdio_irq_work\n| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)\n| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]\n| sp : ffff8000818b3a70\n| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004\n| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9\n| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000\n| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000\n| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517\n| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1\n| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157\n| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124\n| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000\n| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000\n| Call trace:\n|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]\n|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]\n|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]\n|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]\n|  mwifiex_process_event+0x110/0x238 [mwifiex]\n|  mwifiex_main_process+0x428/0xa44 [mwifiex]\n|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]\n|  process_sdio_pending_irqs+0x64/0x1b8\n|  sdio_irq_work+0x4c/0x7c\n|  process_one_work+0x148/0x2a0\n|  worker_thread+0x2fc/0x40c\n|  kthread+0x110/0x114\n|  ret_from_fork+0x10/0x20\n| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)\n| ---[ end trace 0000000000000000 ]---(CVE-2024-46755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (w83627ehf) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (lm95234) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46758)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhwmon: (adc128d818) Fix underflows seen when writing limit attributes\r\n\r\nDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a large\nnegative number such as -9223372036854775808 is provided by the user.\nFix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npci/hotplug/pnv_php: Fix hotplug driver crash on Powernv\r\n\r\nThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernel\ncrash when we try to hot-unplug/disable the PCIe switch/bridge from\nthe PHB.\r\n\r\nThe crash occurs because although the MSI data structure has been\nreleased during disable/hot-unplug path and it has been assigned\nwith NULL, still during unregistration the code was again trying to\nexplicitly disable the MSI which causes the NULL pointer dereference and\nkernel crash.\r\n\r\nThe patch fixes the check during unregistration path to prevent invoking\npci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: bcm: Remove proc entry when dev is unregistered.\r\n\r\nsyzkaller reported a warning in bcm_connect() below. [0]\r\n\r\nThe repro calls connect() to vxcan1, removes vxcan1, and calls\nconnect() with ifindex == 0.\r\n\r\nCalling connect() for a BCM socket allocates a proc entry.\nThen, bcm_sk(sk)-\u0026gt;bound is set to 1 to prevent further connect().\r\n\r\nHowever, removing the bound device resets bcm_sk(sk)-\u0026gt;bound to 0\nin bcm_notify().\r\n\r\nThe 2nd connect() tries to allocate a proc entry with the same\nname and sets NULL to bcm_sk(sk)-\u0026gt;bcm_proc_read, leaking the\noriginal proc entry.\r\n\r\nSince the proc entry is available only for connect()ed sockets,\nlet\u0026apos;s clean up the entry when the bound netdev is unregistered.\r\n\r\n[0]:\nproc_dir_entry \u0026apos;can-bcm/2456\u0026apos; already registered\nWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375\nModules linked in:\nCPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4\nHardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014\nRIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375\nCode: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 \u0026lt;0f\u0026gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48\nRSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246\nRAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80\nRDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002\nRBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0\nR10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000\nR13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ec\nFS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000\nCS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033\nCR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0\nDR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000\nDR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400\nPKRU: 55555554\nCall Trace:\n \u0026lt;TASK\u0026gt;\n proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220\n bcm_connect+0x472/0x840 net/can/bcm.c:1673\n __sys_connect_file net/socket.c:2049 [inline]\n __sys_connect+0x5d2/0x690 net/socket.c:2066\n __do_sys_connect net/socket.c:2076 [inline]\n __se_sys_connect net/socket.c:2073 [inline]\n __x64_sys_connect+0x8f/0x100 net/socket.c:2073\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x4b/0x53\nRIP: 0033:0x7fbd708b0e5d\nCode: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 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 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48\nRSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002a\nRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5d\nRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003\nRBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040\nR10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098\nR13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000\n \u0026lt;/TASK\u0026gt;\nremove_proc_entry: removing non-empty directory \u0026apos;net/can-bcm\u0026apos;, leaking at least \u0026apos;2456\u0026apos;(CVE-2024-46771)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nudf: Avoid excessive partition lengths\r\n\r\nAvoid mounting filesystems where the partition would overflow the\n32-bits used for block number. Also refuse to mount filesystems where\nthe partition length is so large we cannot safely index bits in a\nblock bitmap.(CVE-2024-46777)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: protect references to superblock parameters exposed in sysfs\r\n\r\nThe superblock buffers of nilfs2 can not only be overwritten at runtime\nfor modifications/repairs, but they are also regularly swapped, replaced\nduring resizing, and even abandoned when degrading to one side due to\nbacking device issues.  So, accessing them requires mutual exclusion using\nthe reader/writer semaphore \u0026quot;nilfs-\u0026gt;ns_sem\u0026quot;.\r\n\r\nSome sysfs attribute show methods read this superblock buffer without the\nnecessary mutual exclusion, which can cause problems with pointer\ndereferencing and memory access, so fix it.(CVE-2024-46780)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnilfs2: fix missing cleanup on rollforward recovery error\r\n\r\nIn an error injection test of a routine for mount-time recovery, KASAN\nfound a use-after-free bug.\r\n\r\nIt turned out that if data recovery was performed using partial logs\ncreated by dsync writes, but an error occurred before starting the log\nwriter to create a recovered checkpoint, the inodes whose data had been\nrecovered were left in the ns_dirty_files list of the nilfs object and\nwere not freed.\r\n\r\nFix this issue by cleaning up inodes that have read the recovery data if\nthe recovery routine fails midway before the log writer starts.(CVE-2024-46781)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: mcp251x: fix deadlock if an interrupt occurs during mcp251x_open\r\n\r\nThe mcp251x_hw_wake() function is called with the mpc_lock mutex held and\ndisables the interrupt handler so that no interrupts can be processed while\nwaking the device. If an interrupt has already occurred then waiting for\nthe interrupt handler to complete will deadlock because it will be trying\nto acquire the same mutex.\r\n\r\nCPU0                           CPU1\n----                           ----\nmcp251x_open()\n mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  request_threaded_irq()\n                               \u0026lt;interrupt\u0026gt;\n                               mcp251x_can_ist()\n                                mutex_lock(\u0026amp;priv-\u0026gt;mcp_lock)\n  mcp251x_hw_wake()\n   disable_irq() \u0026lt;-- deadlock\r\n\r\nUse disable_irq_nosync() instead because the interrupt handler does\neverything while holding the mutex so it doesn\u0026apos;t matter if it\u0026apos;s still\nrunning.(CVE-2024-46791)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: dapm: Fix UAF for snd_soc_pcm_runtime object\r\n\r\nWhen using kernel with the following extra config,\r\n\r\n  - CONFIG_KASAN=y\n  - CONFIG_KASAN_GENERIC=y\n  - CONFIG_KASAN_INLINE=y\n  - CONFIG_KASAN_VMALLOC=y\n  - CONFIG_FRAME_WARN=4096\r\n\r\nkernel detects that snd_pcm_suspend_all() access a freed\n\u0026apos;snd_soc_pcm_runtime\u0026apos; object when the system is suspended, which\nleads to a use-after-free bug:\r\n\r\n[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270\n[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330\r\n\r\n[   52.047785] Call trace:\n[   52.047787]  dump_backtrace+0x0/0x3c0\n[   52.047794]  show_stack+0x34/0x50\n[   52.047797]  dump_stack_lvl+0x68/0x8c\n[   52.047802]  print_address_description.constprop.0+0x74/0x2c0\n[   52.047809]  kasan_report+0x210/0x230\n[   52.047815]  __asan_report_load1_noabort+0x3c/0x50\n[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270\n[   52.047824]  snd_soc_suspend+0x19c/0x4e0\r\n\r\nThe snd_pcm_sync_stop() has a NULL check on \u0026apos;substream-\u0026gt;runtime\u0026apos; before\nmaking any access. So we need to always set \u0026apos;substream-\u0026gt;runtime\u0026apos; to NULL\neverytime we kfree() it.(CVE-2024-46798)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Add array index check for hdcp ddc access\r\n\r\n[Why]\nCoverity reports OVERRUN warning. Do not check if array\nindex valid.\r\n\r\n[How]\nCheck msg_id valid and valid array index.(CVE-2024-46804)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check msg_id before processing transcation\r\n\r\n[WHY \u0026amp; HOW]\nHDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a valid\narray index, and it needs checking before used.\r\n\r\nThis fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-46814)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links\r\n\r\n[Why]\nCoverity report OVERRUN warning. There are\nonly max_links elements within dc-\u0026gt;links. link\ncount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.\r\n\r\n[How]\nMake sure link count less than max_links.(CVE-2024-46816)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check gpio_id before used as array index\r\n\r\n[WHY \u0026amp; HOW]\nGPIO_ID_UNKNOWN (-1) is not a valid value for array index and therefore\nshould be checked in advance.\r\n\r\nThis fixes 5 OVERRUN issues reported by Coverity.(CVE-2024-46818)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/pm: Fix negative array index read\r\n\r\nAvoid using the negative values\nfor clk_idex as an index into an array pptable-\u0026gt;DpmDescriptor.\r\n\r\nV2: fix clk_index return check (Tim Huang)(CVE-2024-46821)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrtmutex: Drop rt_mutex::wait_lock before scheduling\r\n\r\nrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In the\ngood case it returns with the lock held and in the deadlock case it emits a\nwarning and goes into an endless scheduling loop with the lock held, which\ntriggers the \u0026apos;scheduling in atomic\u0026apos; warning.\r\n\r\nUnlock rt_mutex::wait_lock in the dead lock case before issuing the warning\nand dropping into the schedule for ever loop.\r\n\r\n[ tglx: Moved unlock before the WARN(), removed the pointless comment,\n  \tmassaged changelog, added Fixes tag ](CVE-2024-46829)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: hns3: void array out of bound when loop tnl_num\r\n\r\nWhen query reg inf of SSU, it loops tnl_num times. However, tnl_num comes\nfrom hardware and the length of array is a fixed value. To void array out\nof bound, make sure the loop time is not greater than the length of array(CVE-2024-46833)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbtrfs: don\u0026apos;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()\r\n\r\nWe handle errors here properly, ENOMEM isn\u0026apos;t fatal, return the error.(CVE-2024-46841)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\num: line: always fill *error_out in setup_one_line()\r\n\r\nThe pointer isn\u0026apos;t initialized by callers, but I have\nencountered cases where it\u0026apos;s still printed; initialize\nit in all possible cases in setup_one_line().(CVE-2024-46844)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: meson: axg-card: fix \u0026apos;use-after-free\u0026apos;\r\n\r\nBuffer \u0026apos;card-\u0026gt;dai_link\u0026apos; is reallocated in \u0026apos;meson_card_reallocate_links()\u0026apos;,\nso move \u0026apos;pad\u0026apos; pointer initialization after this function when memory is\nalready reallocated.\r\n\r\nKasan bug report:\r\n\r\n==================================================================\nBUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bc\nRead of size 8 at addr ffff000000e8b260 by task modprobe/356\r\n\r\nCPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1\nCall trace:\n dump_backtrace+0x94/0xec\n show_stack+0x18/0x24\n dump_stack_lvl+0x78/0x90\n print_report+0xfc/0x5c0\n kasan_report+0xb8/0xfc\n __asan_load8+0x9c/0xb8\n axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card]\n meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils]\n platform_probe+0x8c/0xf4\n really_probe+0x110/0x39c\n __driver_probe_device+0xb8/0x18c\n driver_probe_device+0x108/0x1d8\n __driver_attach+0xd0/0x25c\n bus_for_each_dev+0xe0/0x154\n driver_attach+0x34/0x44\n bus_add_driver+0x134/0x294\n driver_register+0xa8/0x1e8\n __platform_driver_register+0x44/0x54\n axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card]\n do_one_initcall+0xdc/0x25c\n do_init_module+0x10c/0x334\n load_module+0x24c4/0x26cc\n init_module_from_file+0xd4/0x128\n __arm64_sys_finit_module+0x1f4/0x41c\n invoke_syscall+0x60/0x188\n el0_svc_common.constprop.0+0x78/0x13c\n do_el0_svc+0x30/0x40\n el0_svc+0x38/0x78\n el0t_64_sync_handler+0x100/0x12c\n el0t_64_sync+0x190/0x194(CVE-2024-46849)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet/mlx5: Fix bridge mode operations when there are no VFs\r\n\r\nCurrently, trying to set the bridge mode attribute when numvfs=0 leads to a\ncrash:\r\n\r\nbridge link set dev eth2 hwmode vepa\r\n\r\n[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030\n[...]\n[  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core]\n[...]\n[  168.976037] Call Trace:\n[  168.976188]  \u0026lt;TASK\u0026gt;\n[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core]\n[  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core]\n[  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0\n[  168.979714]  rtnetlink_rcv_msg+0x159/0x400\n[  168.980451]  netlink_rcv_skb+0x54/0x100\n[  168.980675]  netlink_unicast+0x241/0x360\n[  168.980918]  netlink_sendmsg+0x1f6/0x430\n[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0\n[  168.982155]  ___sys_sendmsg+0x88/0xd0\n[  168.985036]  __sys_sendmsg+0x59/0xa0\n[  168.985477]  do_syscall_64+0x79/0x150\n[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e\n[  168.987773] RIP: 0033:0x7f8f7950f917\r\n\r\n(esw-\u0026gt;fdb_table.legacy.vepa_fdb is null)\r\n\r\nThe bridge mode is only relevant when there are multiple functions per\nport. Therefore, prevent setting and getting this setting when there are no\nVFs.\r\n\r\nNote that after this change, there are no settings to change on the PF\ninterface using `bridge link` when there are no VFs, so the interface no\nlonger appears in the `bridge link` output.(CVE-2024-46857)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-231.0.0.130.oe2203sp4"}]}],"ecosystem_specific":{"aarch64":["bpftool-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","bpftool-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","kernel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","kernel-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","kernel-debugsource-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","kernel-devel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","kernel-headers-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","kernel-source-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","kernel-tools-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","kernel-tools-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","kernel-tools-devel-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","perf-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","python3-perf-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm","python3-perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.aarch64.rpm"],"src":["kernel-5.10.0-231.0.0.130.oe2203sp4.src.rpm"],"x86_64":["bpftool-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","bpftool-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","kernel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","kernel-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","kernel-debugsource-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","kernel-devel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","kernel-headers-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","kernel-source-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","kernel-tools-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","kernel-tools-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","kernel-tools-devel-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","perf-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","python3-perf-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm","python3-perf-debuginfo-5.10.0-231.0.0.130.oe2203sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2220"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-39482"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41030"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-41095"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-43900"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44958"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-44982"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45008"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45016"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46673"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46674"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46679"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46681"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46695"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46707"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46721"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46725"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46726"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46732"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46737"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46738"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46739"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46740"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46743"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46750"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46753"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46755"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46756"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46758"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46759"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46761"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46771"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46777"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46780"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46781"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46791"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46798"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46804"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46814"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46816"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46818"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46821"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46829"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46833"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46841"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46844"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46849"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46857"}],"database_specific":{"severity":"High"}}