{"schema_version":"1.7.2","id":"OESA-2024-1767","modified":"2024-06-28T11:08:21Z","published":"2024-06-28T11:08:21Z","upstream":["CVE-2021-47231","CVE-2021-47232","CVE-2021-47252","CVE-2021-47288","CVE-2021-47346","CVE-2021-47347","CVE-2021-47434","CVE-2021-47466","CVE-2021-47469","CVE-2021-47493","CVE-2021-47500","CVE-2021-47521","CVE-2021-47565","CVE-2021-47597","CVE-2021-47609","CVE-2022-48737","CVE-2022-48755","CVE-2022-48756","CVE-2023-52670","CVE-2023-52739","CVE-2023-52834","CVE-2023-52853","CVE-2024-27436","CVE-2024-35830","CVE-2024-36894","CVE-2024-36941","CVE-2024-36950","CVE-2024-36971","CVE-2024-38538","CVE-2024-38541","CVE-2024-38552","CVE-2024-38588","CVE-2024-38596","CVE-2024-38607"],"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\ncan: mcba_usb: fix memory leak in mcba_usb\r\n\r\nSyzbot reported memory leak in SocketCAN driver for Microchip CAN BUS\nAnalyzer Tool. The problem was in unfreed usb_coherent.\r\n\r\nIn mcba_usb_start() 20 coherent buffers are allocated and there is\nnothing, that frees them:\r\n\r\n1) In callback function the urb is resubmitted and that\u0026apos;s all\n2) In disconnect function urbs are simply killed, but URB_FREE_BUFFER\n   is not set (see mcba_usb_start) and this flag cannot be used with\n   coherent buffers.\r\n\r\nFail log:\n| [ 1354.053291][ T8413] mcba_usb 1-1:0.0 can0: device disconnected\n| [ 1367.059384][ T8420] kmemleak: 20 new suspected memory leaks (see /sys/kernel/debug/kmem)\r\n\r\nSo, all allocated buffers should be freed with usb_free_coherent()\nexplicitly\r\n\r\nNOTE:\nThe same pattern for allocating and freeing coherent buffers\nis used in drivers/net/can/usb/kvaser_usb/kvaser_usb_core.c(CVE-2021-47231)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: j1939: fix Use-after-Free, hold skb ref while in use\r\n\r\nThis patch fixes a Use-after-Free found by the syzbot.\r\n\r\nThe problem is that a skb is taken from the per-session skb queue,\nwithout incrementing the ref count. This leads to a Use-after-Free if\nthe skb is taken concurrently from the session queue due to a CTS.(CVE-2021-47232)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nbatman-adv: Avoid WARN_ON timing related checks\r\n\r\nThe soft/batadv interface for a queued OGM can be changed during the time\nthe OGM was queued for transmission and when the OGM is actually\ntransmitted by the worker.\r\n\r\nBut WARN_ON must be used to denote kernel bugs and not to print simple\nwarnings. A warning can simply be printed using pr_warn.(CVE-2021-47252)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: ngene: Fix out-of-bounds bug in ngene_command_config_free_buf()\r\n\r\nFix an 11-year old bug in ngene_command_config_free_buf() while\naddressing the following warnings caught with -Warray-bounds:\r\n\r\narch/alpha/include/asm/string.h:22:16: warning: \u0026apos;__builtin_memcpy\u0026apos; offset [12, 16] from the object at \u0026apos;com\u0026apos; is out of the bounds of referenced subobject \u0026apos;config\u0026apos; with type \u0026apos;unsigned char\u0026apos; at offset 10 [-Warray-bounds]\narch/x86/include/asm/string_32.h:182:25: warning: \u0026apos;__builtin_memcpy\u0026apos; offset [12, 16] from the object at \u0026apos;com\u0026apos; is out of the bounds of referenced subobject \u0026apos;config\u0026apos; with type \u0026apos;unsigned char\u0026apos; at offset 10 [-Warray-bounds]\r\n\r\nThe problem is that the original code is trying to copy 6 bytes of\ndata into a one-byte size member _config_ of the wrong structue\nFW_CONFIGURE_BUFFERS, in a single call to memcpy(). This causes a\nlegitimate compiler warning because memcpy() overruns the length\nof \u0026amp;com.cmd.ConfigureBuffers.config. It seems that the right\nstructure is FW_CONFIGURE_FREE_BUFFERS, instead, because it contains\n6 more members apart from the header _hdr_. Also, the name of\nthe function ngene_command_config_free_buf() suggests that the actual\nintention is to ConfigureFreeBuffers, instead of ConfigureBuffers\n(which takes place in the function ngene_command_config_buf(), above).\r\n\r\nFix this by enclosing those 6 members of struct FW_CONFIGURE_FREE_BUFFERS\ninto new struct config, and use \u0026amp;com.cmd.ConfigureFreeBuffers.config as\nthe destination address, instead of \u0026amp;com.cmd.ConfigureBuffers.config,\nwhen calling memcpy().\r\n\r\nThis also helps with the ongoing efforts to globally enable\n-Warray-bounds and get us closer to being able to tighten the\nFORTIFY_SOURCE routines on memcpy().(CVE-2021-47288)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncoresight: tmc-etf: Fix global-out-of-bounds in tmc_update_etf_buffer()\r\n\r\ncommit 6f755e85c332 (\u0026quot;coresight: Add helper for inserting synchronization\npackets\u0026quot;) removed trailing \u0026apos;\\0\u0026apos; from barrier_pkt array and updated the\ncall sites like etb_update_buffer() to have proper checks for barrier_pkt\nsize before read but missed updating tmc_update_etf_buffer() which still\nreads barrier_pkt past the array size resulting in KASAN out-of-bounds\nbug. Fix this by adding a check for barrier_pkt size before accessing\nlike it is done in etb_update_buffer().\r\n\r\n BUG: KASAN: global-out-of-bounds in tmc_update_etf_buffer+0x4b8/0x698\n Read of size 4 at addr ffffffd05b7d1030 by task perf/2629\r\n\r\n Call trace:\n  dump_backtrace+0x0/0x27c\n  show_stack+0x20/0x2c\n  dump_stack+0x11c/0x188\n  print_address_description+0x3c/0x4a4\n  __kasan_report+0x140/0x164\n  kasan_report+0x10/0x18\n  __asan_report_load4_noabort+0x1c/0x24\n  tmc_update_etf_buffer+0x4b8/0x698\n  etm_event_stop+0x248/0x2d8\n  etm_event_del+0x20/0x2c\n  event_sched_out+0x214/0x6f0\n  group_sched_out+0xd0/0x270\n  ctx_sched_out+0x2ec/0x518\n  __perf_event_task_sched_out+0x4fc/0xe6c\n  __schedule+0x1094/0x16a0\n  preempt_schedule_irq+0x88/0x170\n  arm64_preempt_schedule_irq+0xf0/0x18c\n  el1_irq+0xe8/0x180\n  perf_event_exec+0x4d8/0x56c\n  setup_new_exec+0x204/0x400\n  load_elf_binary+0x72c/0x18c0\n  search_binary_handler+0x13c/0x420\n  load_script+0x500/0x6c4\n  search_binary_handler+0x13c/0x420\n  exec_binprm+0x118/0x654\n  __do_execve_file+0x77c/0xba4\n  __arm64_compat_sys_execve+0x98/0xac\n  el0_svc_common+0x1f8/0x5e0\n  el0_svc_compat_handler+0x84/0xb0\n  el0_svc_compat+0x10/0x50\r\n\r\n The buggy address belongs to the variable:\n  barrier_pkt+0x10/0x40\r\n\r\n Memory state around the buggy address:\n  ffffffd05b7d0f00: fa fa fa fa 04 fa fa fa fa fa fa fa 00 00 00 00\n  ffffffd05b7d0f80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00\n \u0026gt;ffffffd05b7d1000: 00 00 00 00 00 00 fa fa fa fa fa fa 00 00 00 03\n                                      ^\n  ffffffd05b7d1080: fa fa fa fa 00 02 fa fa fa fa fa fa 03 fa fa fa\n  ffffffd05b7d1100: fa fa fa fa 00 00 00 00 05 fa fa fa fa fa fa fa\n ==================================================================(CVE-2021-47346)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwl1251: Fix possible buffer overflow in wl1251_cmd_scan\r\n\r\nFunction wl1251_cmd_scan calls memcpy without checking the length.\nHarden by checking the length is within the maximum allowed size.(CVE-2021-47347)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nxhci: Fix command ring pointer corruption while aborting a command\r\n\r\nThe command ring pointer is located at [6:63] bits of the command\nring control register (CRCR). All the control bits like command stop,\nabort are located at [0:3] bits. While aborting a command, we read the\nCRCR and set the abort bit and write to the CRCR. The read will always\ngive command ring pointer as all zeros. So we essentially write only\nthe control bits. Since we split the 64 bit write into two 32 bit writes,\nthere is a possibility of xHC command ring stopped before the upper\ndword (all zeros) is written. If that happens, xHC updates the upper\ndword of its internal command ring pointer with all zeros. Next time,\nwhen the command ring is restarted, we see xHC memory access failures.\nFix this issue by only writing to the lower dword of CRCR where all\ncontrol bits are located.(CVE-2021-47434)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmm, slub: fix potential memoryleak in kmem_cache_open()\r\n\r\nIn error path, the random_seq of slub cache might be leaked.  Fix this\nby using __kmem_cache_release() to release all the relevant resources.(CVE-2021-47466)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nspi: Fix deadlock when adding SPI controllers on SPI buses\r\n\r\nCurrently we have a global spi_add_lock which we take when adding new\ndevices so that we can check that we\u0026apos;re not trying to reuse a chip\nselect that\u0026apos;s already controlled.  This means that if the SPI device is\nitself a SPI controller and triggers the instantiation of further SPI\ndevices we trigger a deadlock as we try to register and instantiate\nthose devices while in the process of doing so for the parent controller\nand hence already holding the global spi_add_lock.  Since we only care\nabout concurrency within a single SPI bus move the lock to be per\ncontroller, avoiding the deadlock.\r\n\r\nThis can be easily triggered in the case of spi-mux.(CVE-2021-47469)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nocfs2: fix race between searching chunks and release journal_head from buffer_head\r\n\r\nEncountered a race between ocfs2_test_bg_bit_allocatable() and\njbd2_journal_put_journal_head() resulting in the below vmcore.\r\n\r\n  PID: 106879  TASK: ffff880244ba9c00  CPU: 2   COMMAND: \u0026quot;loop3\u0026quot;\n  Call trace:\n    panic\n    oops_end\n    no_context\n    __bad_area_nosemaphore\n    bad_area_nosemaphore\n    __do_page_fault\n    do_page_fault\n    page_fault\n      [exception RIP: ocfs2_block_group_find_clear_bits+316]\n    ocfs2_block_group_find_clear_bits [ocfs2]\n    ocfs2_cluster_group_search [ocfs2]\n    ocfs2_search_chain [ocfs2]\n    ocfs2_claim_suballoc_bits [ocfs2]\n    __ocfs2_claim_clusters [ocfs2]\n    ocfs2_claim_clusters [ocfs2]\n    ocfs2_local_alloc_slide_window [ocfs2]\n    ocfs2_reserve_local_alloc_bits [ocfs2]\n    ocfs2_reserve_clusters_with_limit [ocfs2]\n    ocfs2_reserve_clusters [ocfs2]\n    ocfs2_lock_refcount_allocators [ocfs2]\n    ocfs2_make_clusters_writable [ocfs2]\n    ocfs2_replace_cow [ocfs2]\n    ocfs2_refcount_cow [ocfs2]\n    ocfs2_file_write_iter [ocfs2]\n    lo_rw_aio\n    loop_queue_work\n    kthread_worker_fn\n    kthread\n    ret_from_fork\r\n\r\nWhen ocfs2_test_bg_bit_allocatable() called bh2jh(bg_bh), the\nbg_bh-\u0026gt;b_private NULL as jbd2_journal_put_journal_head() raced and\nreleased the jounal head from the buffer head.  Needed to take bit lock\nfor the bit \u0026apos;BH_JournalHead\u0026apos; to fix this race.(CVE-2021-47493)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\niio: mma8452: Fix trigger reference couting\r\n\r\nThe mma8452 driver directly assigns a trigger to the struct iio_dev. The\nIIO core when done using this trigger will call `iio_trigger_put()` to drop\nthe reference count by 1.\r\n\r\nWithout the matching `iio_trigger_get()` in the driver the reference count\ncan reach 0 too early, the trigger gets freed while still in use and a\nuse-after-free occurs.\r\n\r\nFix this by getting a reference to the trigger before assigning it to the\nIIO device.(CVE-2021-47500)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ncan: sja1000: fix use after free in ems_pcmcia_add_card()\r\n\r\nIf the last channel is not available then \u0026quot;dev\u0026quot; is freed.  Fortunately,\nwe can just use \u0026quot;pdev-\u0026gt;irq\u0026quot; instead.\r\n\r\nAlso we should check if at least one channel was set up.(CVE-2021-47521)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nscsi: mpt3sas: Fix kernel panic during drive powercycle test\r\n\r\nWhile looping over shost\u0026apos;s sdev list it is possible that one\nof the drives is getting removed and its sas_target object is\nfreed but its sdev object remains intact.\r\n\r\nConsequently, a kernel panic can occur while the driver is trying to access\nthe sas_address field of sas_target object without also checking the\nsas_target object for NULL.(CVE-2021-47565)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ninet_diag: fix kernel-infoleak for UDP sockets\r\n\r\nKMSAN reported a kernel-infoleak [1], that can exploited\nby unpriv users.\r\n\r\nAfter analysis it turned out UDP was not initializing\nr-\u0026gt;idiag_expires. Other users of inet_sk_diag_fill()\nmight make the same mistake in the future, so fix this\nin inet_sk_diag_fill().\r\n\r\n[1]\nBUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:121 [inline]\nBUG: KMSAN: kernel-infoleak in copyout lib/iov_iter.c:156 [inline]\nBUG: KMSAN: kernel-infoleak in _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n instrument_copy_to_user include/linux/instrumented.h:121 [inline]\n copyout lib/iov_iter.c:156 [inline]\n _copy_to_iter+0x69d/0x25c0 lib/iov_iter.c:670\n copy_to_iter include/linux/uio.h:155 [inline]\n simple_copy_to_iter+0xf3/0x140 net/core/datagram.c:519\n __skb_datagram_iter+0x2cb/0x1280 net/core/datagram.c:425\n skb_copy_datagram_iter+0xdc/0x270 net/core/datagram.c:533\n skb_copy_datagram_msg include/linux/skbuff.h:3657 [inline]\n netlink_recvmsg+0x660/0x1c60 net/netlink/af_netlink.c:1974\n sock_recvmsg_nosec net/socket.c:944 [inline]\n sock_recvmsg net/socket.c:962 [inline]\n sock_read_iter+0x5a9/0x630 net/socket.c:1035\n call_read_iter include/linux/fs.h:2156 [inline]\n new_sync_read fs/read_write.c:400 [inline]\n vfs_read+0x1631/0x1980 fs/read_write.c:481\n ksys_read+0x28c/0x520 fs/read_write.c:619\n __do_sys_read fs/read_write.c:629 [inline]\n __se_sys_read fs/read_write.c:627 [inline]\n __x64_sys_read+0xdb/0x120 fs/read_write.c:627\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nUninit was created at:\n slab_post_alloc_hook mm/slab.h:524 [inline]\n slab_alloc_node mm/slub.c:3251 [inline]\n __kmalloc_node_track_caller+0xe0c/0x1510 mm/slub.c:4974\n kmalloc_reserve net/core/skbuff.c:354 [inline]\n __alloc_skb+0x545/0xf90 net/core/skbuff.c:426\n alloc_skb include/linux/skbuff.h:1126 [inline]\n netlink_dump+0x3d5/0x16a0 net/netlink/af_netlink.c:2245\n __netlink_dump_start+0xd1c/0xee0 net/netlink/af_netlink.c:2370\n netlink_dump_start include/linux/netlink.h:254 [inline]\n inet_diag_handler_cmd+0x2e7/0x400 net/ipv4/inet_diag.c:1343\n sock_diag_rcv_msg+0x24a/0x620\n netlink_rcv_skb+0x447/0x800 net/netlink/af_netlink.c:2491\n sock_diag_rcv+0x63/0x80 net/core/sock_diag.c:276\n netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]\n netlink_unicast+0x1095/0x1360 net/netlink/af_netlink.c:1345\n netlink_sendmsg+0x16f3/0x1870 net/netlink/af_netlink.c:1916\n sock_sendmsg_nosec net/socket.c:704 [inline]\n sock_sendmsg net/socket.c:724 [inline]\n sock_write_iter+0x594/0x690 net/socket.c:1057\n do_iter_readv_writev+0xa7f/0xc70\n do_iter_write+0x52c/0x1500 fs/read_write.c:851\n vfs_writev fs/read_write.c:924 [inline]\n do_writev+0x63f/0xe30 fs/read_write.c:967\n __do_sys_writev fs/read_write.c:1040 [inline]\n __se_sys_writev fs/read_write.c:1037 [inline]\n __x64_sys_writev+0xe5/0x120 fs/read_write.c:1037\n do_syscall_x64 arch/x86/entry/common.c:51 [inline]\n do_syscall_64+0x54/0xd0 arch/x86/entry/common.c:82\n entry_SYSCALL_64_after_hwframe+0x44/0xae\r\n\r\nBytes 68-71 of 312 are uninitialized\nMemory access of size 312 starts at ffff88812ab54000\nData copied to user address 0000000020001440\r\n\r\nCPU: 1 PID: 6365 Comm: syz-executor801 Not tainted 5.16.0-rc3-syzkaller #0\nHardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011(CVE-2021-47597)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirmware: arm_scpi: Fix string overflow in SCPI genpd driver\r\n\r\nWithout the bound checks for scpi_pd-\u0026gt;name, it could result in the buffer\noverflow when copying the SCPI device name from the corresponding device\ntree node as the name string is set at maximum size of 30.\r\n\r\nLet us fix it by using devm_kasprintf so that the string buffer is\nallocated dynamically.(CVE-2021-47609)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nASoC: ops: Reject out of bounds values in snd_soc_put_volsw_sx()\r\n\r\nWe don\u0026apos;t currently validate that the values being set are within the range\nwe advertised to userspace as being valid, do so and reject any values\nthat are out of range.(CVE-2022-48737)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\npowerpc64/bpf: Limit \u0026apos;ldbrx\u0026apos; to processors compliant with ISA v2.06\r\n\r\nJohan reported the below crash with test_bpf on ppc64 e5500:\r\n\r\n  test_bpf: #296 ALU_END_FROM_LE 64: 0x0123456789abcdef -\u0026gt; 0x67452301 jited:1\n  Oops: Exception in kernel mode, sig: 4 [#1]\n  BE PAGE_SIZE=4K SMP NR_CPUS=24 QEMU e500\n  Modules linked in: test_bpf(+)\n  CPU: 0 PID: 76 Comm: insmod Not tainted 5.14.0-03771-g98c2059e008a-dirty #1\n  NIP:  8000000000061c3c LR: 80000000006dea64 CTR: 8000000000061c18\n  REGS: c0000000032d3420 TRAP: 0700   Not tainted (5.14.0-03771-g98c2059e008a-dirty)\n  MSR:  0000000080089000 \u0026lt;EE,ME\u0026gt;  CR: 88002822  XER: 20000000 IRQMASK: 0\n  \u0026lt;...\u0026gt;\n  NIP [8000000000061c3c] 0x8000000000061c3c\n  LR [80000000006dea64] .__run_one+0x104/0x17c [test_bpf]\n  Call Trace:\n   .__run_one+0x60/0x17c [test_bpf] (unreliable)\n   .test_bpf_init+0x6a8/0xdc8 [test_bpf]\n   .do_one_initcall+0x6c/0x28c\n   .do_init_module+0x68/0x28c\n   .load_module+0x2460/0x2abc\n   .__do_sys_init_module+0x120/0x18c\n   .system_call_exception+0x110/0x1b8\n   system_call_common+0xf0/0x210\n  --- interrupt: c00 at 0x101d0acc\n  \u0026lt;...\u0026gt;\n  ---[ end trace 47b2bf19090bb3d0 ]---\r\n\r\n  Illegal instruction\r\n\r\nThe illegal instruction turned out to be \u0026apos;ldbrx\u0026apos; emitted for\nBPF_FROM_[L|B]E, which was only introduced in ISA v2.06. Guard use of\nthe same and implement an alternative approach for older processors.(CVE-2022-48755)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/msm/dsi: invalid parameter check in msm_dsi_phy_enable\r\n\r\nThe function performs a check on the \u0026quot;phy\u0026quot; input parameter, however, it\nis used before the check.\r\n\r\nInitialize the \u0026quot;dev\u0026quot; variable after the sanity check to avoid a possible\nNULL pointer dereference.\r\n\r\nAddresses-Coverity-ID: 1493860 (\u0026quot;Null pointer dereference\u0026quot;)(CVE-2022-48756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nrpmsg: virtio: Free driver_override when rpmsg_remove()\r\n\r\nFree driver_override when rpmsg_remove(), otherwise\nthe following memory leak will occur:\r\n\r\nunreferenced object 0xffff0000d55d7080 (size 128):\n  comm \u0026quot;kworker/u8:2\u0026quot;, pid 56, jiffies 4294893188 (age 214.272s)\n  hex dump (first 32 bytes):\n    72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00  rpmsg_ns........\n    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................\n  backtrace:\n    [\u0026lt;000000009c94c9c1\u0026gt;] __kmem_cache_alloc_node+0x1f8/0x320\n    [\u0026lt;000000002300d89b\u0026gt;] __kmalloc_node_track_caller+0x44/0x70\n    [\u0026lt;00000000228a60c3\u0026gt;] kstrndup+0x4c/0x90\n    [\u0026lt;0000000077158695\u0026gt;] driver_set_override+0xd0/0x164\n    [\u0026lt;000000003e9c4ea5\u0026gt;] rpmsg_register_device_override+0x98/0x170\n    [\u0026lt;000000001c0c89a8\u0026gt;] rpmsg_ns_register_device+0x24/0x30\n    [\u0026lt;000000008bbf8fa2\u0026gt;] rpmsg_probe+0x2e0/0x3ec\n    [\u0026lt;00000000e65a68df\u0026gt;] virtio_dev_probe+0x1c0/0x280\n    [\u0026lt;00000000443331cc\u0026gt;] really_probe+0xbc/0x2dc\n    [\u0026lt;00000000391064b1\u0026gt;] __driver_probe_device+0x78/0xe0\n    [\u0026lt;00000000a41c9a5b\u0026gt;] driver_probe_device+0xd8/0x160\n    [\u0026lt;000000009c3bd5df\u0026gt;] __device_attach_driver+0xb8/0x140\n    [\u0026lt;0000000043cd7614\u0026gt;] bus_for_each_drv+0x7c/0xd4\n    [\u0026lt;000000003b929a36\u0026gt;] __device_attach+0x9c/0x19c\n    [\u0026lt;00000000a94e0ba8\u0026gt;] device_initial_probe+0x14/0x20\n    [\u0026lt;000000003c999637\u0026gt;] bus_probe_device+0xa0/0xac(CVE-2023-52670)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nFix page corruption caused by racy check in __free_pages\r\n\r\nWhen we upgraded our kernel, we started seeing some page corruption like\nthe following consistently:\r\n\r\n  BUG: Bad page state in process ganesha.nfsd  pfn:1304ca\n  page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca\n  flags: 0x17ffffc0000000()\n  raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000\n  raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000\n  page dumped because: nonzero mapcount\n  CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P    B      O      5.10.158-1.nutanix.20221209.el7.x86_64 #1\n  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016\n  Call Trace:\n   dump_stack+0x74/0x96\n   bad_page.cold+0x63/0x94\n   check_new_page_bad+0x6d/0x80\n   rmqueue+0x46e/0x970\n   get_page_from_freelist+0xcb/0x3f0\n   ? _cond_resched+0x19/0x40\n   __alloc_pages_nodemask+0x164/0x300\n   alloc_pages_current+0x87/0xf0\n   skb_page_frag_refill+0x84/0x110\n   ...\r\n\r\nSometimes, it would also show up as corruption in the free list pointer\nand cause crashes.\r\n\r\nAfter bisecting the issue, we found the issue started from commit\ne320d3012d25 (\u0026quot;mm/page_alloc.c: fix freeing non-compound pages\u0026quot;):\r\n\r\n\tif (put_page_testzero(page))\n\t\tfree_the_page(page, order);\n\telse if (!PageHead(page))\n\t\twhile (order-- \u0026gt; 0)\n\t\t\tfree_the_page(page + (1 \u0026lt;\u0026lt; order), order);\r\n\r\nSo the problem is the check PageHead is racy because at this point we\nalready dropped our reference to the page.  So even if we came in with\ncompound page, the page can already be freed and PageHead can return\nfalse and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\natl1c: Work around the DMA RX overflow issue\r\n\r\nThis is based on alx driver commit 881d0327db37 (\u0026quot;net: alx: Work around\nthe DMA RX overflow issue\u0026quot;).\r\n\r\nThe alx and atl1c drivers had RX overflow error which was why a custom\nallocator was created to avoid certain addresses. The simpler workaround\nthen created for alx driver, but not for atl1c due to lack of tester.\r\n\r\nInstead of using a custom allocator, check the allocated skb address and\nuse skb_reserve() to move away from problematic 0x...fc0 address.\r\n\r\nTested on AR8131 on Acer 4540.(CVE-2023-52834)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nhid: cp2112: Fix duplicate workqueue initialization\r\n\r\nPreviously the cp2112 driver called INIT_DELAYED_WORK within\ncp2112_gpio_irq_startup, resulting in duplicate initilizations of the\nworkqueue on subsequent IRQ startups following an initial request. This\nresulted in a warning in set_work_data in workqueue.c, as well as a rare\nNULL dereference within process_one_work in workqueue.c.\r\n\r\nInitialize the workqueue within _probe instead.(CVE-2023-52853)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nALSA: usb-audio: Stop parsing channels bits when all channels are found.\r\n\r\nIf a usb audio device sets more bits than the amount of channels\nit could write outside of the map array.(CVE-2024-27436)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmedia: tc358743: register v4l2 async device only after successful setup\r\n\r\nEnsure the device has been setup correctly before registering the v4l2\nasync device, thus allowing userspace to access.(CVE-2024-35830)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nusb: gadget: f_fs: Fix race between aio_cancel() and AIO request complete\r\n\r\nFFS based applications can utilize the aio_cancel() callback to dequeue\npending USB requests submitted to the UDC.  There is a scenario where the\nFFS application issues an AIO cancel call, while the UDC is handling a\nsoft disconnect.  For a DWC3 based implementation, the callstack looks\nlike the following:\r\n\r\n    DWC3 Gadget                               FFS Application\ndwc3_gadget_soft_disconnect()              ...\n  --\u0026gt; dwc3_stop_active_transfers()\n    --\u0026gt; dwc3_gadget_giveback(-ESHUTDOWN)\n      --\u0026gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()\n        --\u0026gt; usb_ep_free_request()            --\u0026gt; usb_ep_dequeue()\r\n\r\nThere is currently no locking implemented between the AIO completion\nhandler and AIO cancel, so the issue occurs if the completion routine is\nrunning in parallel to an AIO cancel call coming from the FFS application.\nAs the completion call frees the USB request (io_data-\u0026gt;req) the FFS\napplication is also referencing it for the usb_ep_dequeue() call.  This can\nlead to accessing a stale/hanging pointer.\r\n\r\ncommit b566d38857fc (\u0026quot;usb: gadget: f_fs: use io_data-\u0026gt;status consistently\u0026quot;)\nrelocated the usb_ep_free_request() into ffs_epfile_async_io_complete().\nHowever, in order to properly implement locking to mitigate this issue, the\nspinlock can\u0026apos;t be added to ffs_epfile_async_io_complete(), as\nusb_ep_dequeue() (if successfully dequeuing a USB request) will call the\nfunction driver\u0026apos;s completion handler in the same context.  Hence, leading\ninto a deadlock.\r\n\r\nFix this issue by moving the usb_ep_free_request() back to\nffs_user_copy_worker(), and ensuring that it explicitly sets io_data-\u0026gt;req\nto NULL after freeing it within the ffs-\u0026gt;eps_lock.  This resolves the race\ncondition above, as the ffs_aio_cancel() routine will not continue\nattempting to dequeue a request that has already been freed, or the\nffs_user_copy_work() not freeing the USB request until the AIO cancel is\ndone referencing it.\r\n\r\nThis fix depends on\n  commit b566d38857fc (\u0026quot;usb: gadget: f_fs: use io_data-\u0026gt;status\n  consistently\u0026quot;)(CVE-2024-36894)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: nl80211: don\u0026apos;t free NULL coalescing rule\r\n\r\nIf the parsing fails, we can dereference a NULL pointer here.(CVE-2024-36941)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfirewire: ohci: mask bus reset interrupts between ISR and bottom half\r\n\r\nIn the FireWire OHCI interrupt handler, if a bus reset interrupt has\noccurred, mask bus reset interrupts until bus_reset_work has serviced and\ncleared the interrupt.\r\n\r\nNormally, we always leave bus reset interrupts masked. We infer the bus\nreset from the self-ID interrupt that happens shortly thereafter. A\nscenario where we unmask bus reset interrupts was introduced in 2008 in\na007bb857e0b26f5d8b73c2ff90782d9c0972620: If\nOHCI_PARAM_DEBUG_BUSRESETS (8) is set in the debug parameter bitmask, we\nwill unmask bus reset interrupts so we can log them.\r\n\r\nirq_handler logs the bus reset interrupt. However, we can\u0026apos;t clear the bus\nreset event flag in irq_handler, because we won\u0026apos;t service the event until\nlater. irq_handler exits with the event flag still set. If the\ncorresponding interrupt is still unmasked, the first bus reset will\nusually freeze the system due to irq_handler being called again each\ntime it exits. This freeze can be reproduced by loading firewire_ohci\nwith \u0026quot;modprobe firewire_ohci debug=-1\u0026quot; (to enable all debugging output).\nApparently there are also some cases where bus_reset_work will get called\nsoon enough to clear the event, and operation will continue normally.\r\n\r\nThis freeze was first reported a few months after a007bb85 was committed,\nbut until now it was never fixed. The debug level could safely be set\nto -1 through sysfs after the module was loaded, but this would be\nineffectual in logging bus reset interrupts since they were only\nunmasked during initialization.\r\n\r\nirq_handler will now leave the event flag set but mask bus reset\ninterrupts, so irq_handler won\u0026apos;t be called again and there will be no\nfreeze. If OHCI_PARAM_DEBUG_BUSRESETS is enabled, bus_reset_work will\nunmask the interrupt after servicing the event, so future interrupts\nwill be caught as desired.\r\n\r\nAs a side effect to this change, OHCI_PARAM_DEBUG_BUSRESETS can now be\nenabled through sysfs in addition to during initial module loading.\nHowever, when enabled through sysfs, logging of bus reset interrupts will\nbe effective only starting with the second bus reset, after\nbus_reset_work has executed.(CVE-2024-36950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: fix __dst_negative_advice() race\r\n\r\n__dst_negative_advice() does not enforce proper RCU rules when\nsk-\u0026gt;dst_cache must be cleared, leading to possible UAF.\r\n\r\nRCU rules are that we must first clear sk-\u0026gt;sk_dst_cache,\nthen call dst_release(old_dst).\r\n\r\nNote that sk_dst_reset(sk) is implementing this protocol correctly,\nwhile __dst_negative_advice() uses the wrong order.\r\n\r\nGiven that ip6_negative_advice() has special logic\nagainst RTF_CACHE, this means each of the three -\u0026gt;negative_advice()\nexisting methods must perform the sk_dst_reset() themselves.\r\n\r\nNote the check against NULL dst is centralized in\n__dst_negative_advice(), there is no need to duplicate\nit in various callbacks.\r\n\r\nMany thanks to Clement Lecigne for tracking this issue.\r\n\r\nThis old bug became visible after the blamed commit, using UDP sockets.(CVE-2024-36971)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nnet: bridge: xmit: make sure we have at least eth header len bytes\r\n\r\nsyzbot triggered an uninit value[1] error in bridge device\u0026apos;s xmit path\nby sending a short (less than ETH_HLEN bytes) skb. To fix it check if\nwe can actually pull that amount instead of assuming.\r\n\r\nTested with dropwatch:\n drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)\n origin: software\n timestamp: Mon May 13 11:31:53 2024 778214037 nsec\n protocol: 0x88a8\n length: 2\n original length: 2\n drop reason: PKT_TOO_SMALL\r\n\r\n[1]\nBUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65\n __netdev_start_xmit include/linux/netdevice.h:4903 [inline]\n netdev_start_xmit include/linux/netdevice.h:4917 [inline]\n xmit_one net/core/dev.c:3531 [inline]\n dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547\n __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341\n dev_queue_xmit include/linux/netdevice.h:3091 [inline]\n __bpf_tx_skb net/core/filter.c:2136 [inline]\n __bpf_redirect_common net/core/filter.c:2180 [inline]\n __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187\n ____bpf_clone_redirect net/core/filter.c:2460 [inline]\n bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432\n ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997\n __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238\n bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]\n __bpf_prog_run include/linux/filter.h:657 [inline]\n bpf_prog_run include/linux/filter.h:664 [inline]\n bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425\n bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058\n bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269\n __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678\n __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]\n __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]\n __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765\n x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322\n do_syscall_x64 arch/x86/entry/common.c:52 [inline]\n do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83\n entry_SYSCALL_64_after_hwframe+0x77/0x7f(CVE-2024-38538)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nof: module: add buffer overflow check in of_modalias()\r\n\r\nIn of_modalias(), if the buffer happens to be too small even for the 1st\nsnprintf() call, the len parameter will become negative and str parameter\n(if not NULL initially) will point beyond the buffer\u0026apos;s end. Add the buffer\noverflow check after the 1st snprintf() call and fix such check after the\nstrlen() call (accounting for the terminating NUL char).(CVE-2024-38541)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Fix potential index out of bounds in color transformation function\r\n\r\nFixes index out of bounds issue in the color transformation function.\nThe issue could occur when the index \u0026apos;i\u0026apos; exceeds the number of transfer\nfunction points (TRANSFER_FUNC_POINTS).\r\n\r\nThe fix adds a check to ensure \u0026apos;i\u0026apos; is within bounds before accessing the\ntransfer function points. If \u0026apos;i\u0026apos; is out of bounds, an error message is\nlogged and the function returns false to indicate an error.\r\n\r\nReported by smatch:\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.red\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.green\u0026apos; 1025 \u0026lt;= s32max\ndrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow \u0026apos;output_tf-\u0026gt;tf_pts.blue\u0026apos; 1025 \u0026lt;= s32max(CVE-2024-38552)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nftrace: Fix possible use-after-free issue in ftrace_location()\r\n\r\nKASAN reports a bug:\r\n\r\n  BUG: KASAN: use-after-free in ftrace_location+0x90/0x120\n  Read of size 8 at addr ffff888141d40010 by task insmod/424\n  CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+\n  [...]\n  Call Trace:\n   \u0026lt;TASK\u0026gt;\n   dump_stack_lvl+0x68/0xa0\n   print_report+0xcf/0x610\n   kasan_report+0xb5/0xe0\n   ftrace_location+0x90/0x120\n   register_kprobe+0x14b/0xa40\n   kprobe_init+0x2d/0xff0 [kprobe_example]\n   do_one_initcall+0x8f/0x2d0\n   do_init_module+0x13a/0x3c0\n   load_module+0x3082/0x33d0\n   init_module_from_file+0xd2/0x130\n   __x64_sys_finit_module+0x306/0x440\n   do_syscall_64+0x68/0x140\n   entry_SYSCALL_64_after_hwframe+0x71/0x79\r\n\r\nThe root cause is that, in lookup_rec(), ftrace record of some address\nis being searched in ftrace pages of some module, but those ftrace pages\nat the same time is being freed in ftrace_release_mod() as the\ncorresponding module is being deleted:\r\n\r\n           CPU1                       |      CPU2\n  register_kprobes() {                | delete_module() {\n    check_kprobe_address_safe() {     |\n      arch_check_ftrace_location() {  |\n        ftrace_location() {           |\n          lookup_rec() // USE!        |   ftrace_release_mod() // Free!\r\n\r\nTo fix this issue:\n  1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();\n  2. Use ftrace_location_range() instead of lookup_rec() in\n     ftrace_location();\n  3. Call synchronize_rcu() before freeing any ftrace pages both in\n     ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().(CVE-2024-38588)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\naf_unix: Fix data races in unix_release_sock/unix_stream_sendmsg\r\n\r\nA data-race condition has been identified in af_unix. In one data path,\nthe write function unix_release_sock() atomically writes to\nsk-\u0026gt;sk_shutdown using WRITE_ONCE. However, on the reader side,\nunix_stream_sendmsg() does not read it atomically. Consequently, this\nissue is causing the following KCSAN splat to occur:\r\n\r\n\tBUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg\r\n\r\n\twrite (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:\n\tunix_release_sock (net/unix/af_unix.c:640)\n\tunix_release (net/unix/af_unix.c:1050)\n\tsock_close (net/socket.c:659 net/socket.c:1421)\n\t__fput (fs/file_table.c:422)\n\t__fput_sync (fs/file_table.c:508)\n\t__se_sys_close (fs/open.c:1559 fs/open.c:1541)\n\t__x64_sys_close (fs/open.c:1541)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n\tread to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:\n\tunix_stream_sendmsg (net/unix/af_unix.c:2273)\n\t__sock_sendmsg (net/socket.c:730 net/socket.c:745)\n\t____sys_sendmsg (net/socket.c:2584)\n\t__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)\n\t__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)\n\tx64_sys_call (arch/x86/entry/syscall_64.c:33)\n\tdo_syscall_64 (arch/x86/entry/common.c:?)\n\tentry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)\r\n\r\n\tvalue changed: 0x01 -\u0026gt; 0x03\r\n\r\nThe line numbers are related to commit dd5a440a31fa (\u0026quot;Linux 6.9-rc7\u0026quot;).\r\n\r\nCommit e1d09c2c2f57 (\u0026quot;af_unix: Fix data races around sk-\u0026gt;sk_shutdown.\u0026quot;)\naddressed a comparable issue in the past regarding sk-\u0026gt;sk_shutdown.\nHowever, it overlooked resolving this particular data path.\nThis patch only offending unix_stream_sendmsg() function, since the\nother reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmacintosh/via-macii: Fix \u0026quot;BUG: sleeping function called from invalid context\u0026quot;\r\n\r\nThe via-macii ADB driver calls request_irq() after disabling hard\ninterrupts. But disabling interrupts isn\u0026apos;t necessary here because the\nVIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)","affected":[{"package":{"ecosystem":"openEuler:20.03-LTS-SP4","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-20.03-LTS-SP4"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.19.90-2406.4.0.0283.oe2003sp4"}]}],"ecosystem_specific":{"aarch64":["perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","kernel-debugsource-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","kernel-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","python2-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","bpftool-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","kernel-tools-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","kernel-source-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","kernel-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","python2-perf-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","perf-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","python3-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","kernel-tools-devel-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","kernel-tools-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","bpftool-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","python3-perf-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm","kernel-devel-4.19.90-2406.4.0.0283.oe2003sp4.aarch64.rpm"],"src":["kernel-4.19.90-2406.4.0.0283.oe2003sp4.src.rpm"],"x86_64":["perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","kernel-devel-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","kernel-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","perf-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","bpftool-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","python2-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","kernel-source-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","python2-perf-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","kernel-tools-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","kernel-tools-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","python3-perf-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","bpftool-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","kernel-debuginfo-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","kernel-tools-devel-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","kernel-debugsource-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm","python3-perf-4.19.90-2406.4.0.0283.oe2003sp4.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/en/security/safety-bulletin/detail.html?id=openEuler-SA-2024-1767"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47231"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47232"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47252"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47288"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47346"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47347"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47434"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47466"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47469"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47493"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47500"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47521"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47565"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47597"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2021-47609"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48737"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48755"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48756"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52670"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52739"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52834"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2023-52853"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-27436"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-35830"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36894"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36941"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36950"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-36971"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38538"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38541"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38552"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38588"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38596"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-38607"}],"database_specific":{"severity":"High"}}