{"schema_version":"1.7.2","id":"OESA-2024-2371","modified":"2024-11-08T15:10:56Z","published":"2024-11-08T15:10:56Z","upstream":["CVE-2022-48956","CVE-2022-48958","CVE-2022-48960","CVE-2022-48961","CVE-2022-48962","CVE-2022-48966","CVE-2022-48972","CVE-2022-48975","CVE-2022-48981","CVE-2022-48982","CVE-2022-48992","CVE-2022-48995","CVE-2022-49004","CVE-2022-49005","CVE-2022-49011","CVE-2022-49017","CVE-2022-49020","CVE-2022-49021","CVE-2022-49023","CVE-2022-49031","CVE-2022-49032","CVE-2024-45021","CVE-2024-46677","CVE-2024-46809","CVE-2024-47659","CVE-2024-47660","CVE-2024-47668","CVE-2024-47673","CVE-2024-47690","CVE-2024-47691","CVE-2024-47692","CVE-2024-47693","CVE-2024-47696","CVE-2024-47699","CVE-2024-47701","CVE-2024-47703","CVE-2024-47705","CVE-2024-47723","CVE-2024-47739","CVE-2024-47742","CVE-2024-47748","CVE-2024-47756","CVE-2024-49855","CVE-2024-49858","CVE-2024-49860","CVE-2024-49863","CVE-2024-49877","CVE-2024-49879","CVE-2024-49881","CVE-2024-49882","CVE-2024-49883","CVE-2024-49884","CVE-2024-49886","CVE-2024-49889","CVE-2024-49913","CVE-2024-49917","CVE-2024-49922","CVE-2024-49924","CVE-2024-49933","CVE-2024-49934","CVE-2024-49936","CVE-2024-49940","CVE-2024-49950","CVE-2024-49954","CVE-2024-49955","CVE-2024-49958","CVE-2024-49965","CVE-2024-49973","CVE-2024-49975","CVE-2024-49978","CVE-2024-49981","CVE-2024-49992","CVE-2024-49995","CVE-2024-49996","CVE-2024-50008","CVE-2024-50015","CVE-2024-50016","CVE-2024-50028","CVE-2024-50033","CVE-2024-50035","CVE-2024-50046","CVE-2024-50047","CVE-2024-50058","CVE-2024-50059","CVE-2024-50060","CVE-2024-50063","CVE-2024-50067","CVE-2024-50074","CVE-2024-50083"],"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:  ipv6: avoid use-after-free in ip6_fragment()  Blamed commit claimed rcu_read_lock() was held by ip6_fragment() callers.  It seems to not be always true, at least for UDP stack.  syzbot reported:  BUG: KASAN: use-after-free in ip6_dst_idev include/net/ip6_fib.h:245 [inline] BUG: KASAN: use-after-free in ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951 Read of size 8 at addr ffff88801d403e80 by task syz-executor.3/7618  CPU: 1 PID: 7618 Comm: syz-executor.3 Not tainted 6.1.0-rc6-syzkaller-00012-g4312098baf37 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0xd1/0x138 lib/dump_stack.c:106  print_address_description mm/kasan/report.c:284 [inline]  print_report+0x15e/0x45d mm/kasan/report.c:395  kasan_report+0xbf/0x1f0 mm/kasan/report.c:495  ip6_dst_idev include/net/ip6_fib.h:245 [inline]  ip6_fragment+0x2724/0x2770 net/ipv6/ip6_output.c:951  __ip6_finish_output net/ipv6/ip6_output.c:193 [inline]  ip6_finish_output+0x9a3/0x1170 net/ipv6/ip6_output.c:206  NF_HOOK_COND include/linux/netfilter.h:291 [inline]  ip6_output+0x1f1/0x540 net/ipv6/ip6_output.c:227  dst_output include/net/dst.h:445 [inline]  ip6_local_out+0xb3/0x1a0 net/ipv6/output_core.c:161  ip6_send_skb+0xbb/0x340 net/ipv6/ip6_output.c:1966  udp_v6_send_skb+0x82a/0x18a0 net/ipv6/udp.c:1286  udp_v6_push_pending_frames+0x140/0x200 net/ipv6/udp.c:1313  udpv6_sendmsg+0x18da/0x2c80 net/ipv6/udp.c:1606  inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665  sock_sendmsg_nosec net/socket.c:714 [inline]  sock_sendmsg+0xd3/0x120 net/socket.c:734  sock_write_iter+0x295/0x3d0 net/socket.c:1108  call_write_iter include/linux/fs.h:2191 [inline]  new_sync_write fs/read_write.c:491 [inline]  vfs_write+0x9ed/0xdd0 fs/read_write.c:584  ksys_write+0x1ec/0x250 fs/read_write.c:637  do_syscall_x64 arch/x86/entry/common.c:50 [inline]  do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80  entry_SYSCALL_64_after_hwframe+0x63/0xcd RIP: 0033:0x7fde3588c0d9 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 f1 19 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fde365b6168 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 RAX: ffffffffffffffda RBX: 00007fde359ac050 RCX: 00007fde3588c0d9 RDX: 000000000000ffdc RSI: 00000000200000c0 RDI: 000000000000000a RBP: 00007fde358e7ae9 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 R13: 00007fde35acfb1f R14: 00007fde365b6300 R15: 0000000000022000  \u0026lt;/TASK\u0026gt;  Allocated by task 7618:  kasan_save_stack+0x22/0x40 mm/kasan/common.c:45  kasan_set_track+0x25/0x30 mm/kasan/common.c:52  __kasan_slab_alloc+0x82/0x90 mm/kasan/common.c:325  kasan_slab_alloc include/linux/kasan.h:201 [inline]  slab_post_alloc_hook mm/slab.h:737 [inline]  slab_alloc_node mm/slub.c:3398 [inline]  slab_alloc mm/slub.c:3406 [inline]  __kmem_cache_alloc_lru mm/slub.c:3413 [inline]  kmem_cache_alloc+0x2b4/0x3d0 mm/slub.c:3422  dst_alloc+0x14a/0x1f0 net/core/dst.c:92  ip6_dst_alloc+0x32/0xa0 net/ipv6/route.c:344  ip6_rt_pcpu_alloc net/ipv6/route.c:1369 [inline]  rt6_make_pcpu_route net/ipv6/route.c:1417 [inline]  ip6_pol_route+0x901/0x1190 net/ipv6/route.c:2254  pol_lookup_func include/net/ip6_fib.h:582 [inline]  fib6_rule_lookup+0x52e/0x6f0 net/ipv6/fib6_rules.c:121  ip6_route_output_flags_noref+0x2e6/0x380 net/ipv6/route.c:2625  ip6_route_output_flags+0x76/0x320 net/ipv6/route.c:2638  ip6_route_output include/net/ip6_route.h:98 [inline]  ip6_dst_lookup_tail+0x5ab/0x1620 net/ipv6/ip6_output.c:1092  ip6_dst_lookup_flow+0x90/0x1d0 net/ipv6/ip6_output.c:1222  ip6_sk_dst_lookup_flow+0x553/0x980 net/ipv6/ip6_output.c:1260  udpv6_sendmsg+0x151d/0x2c80 net/ipv6/udp.c:1554  inet6_sendmsg+0x9d/0xe0 net/ipv6/af_inet6.c:665  sock_sendmsg_nosec n ---truncated---(CVE-2022-48956)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ethernet: aeroflex: fix potential skb leak in greth_init_rings()  The greth_init_rings() function won\u0026apos;t free the newly allocated skb when dma_mapping_error() returns error, so add dev_kfree_skb() to fix it.  Compile tested only.(CVE-2022-48958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: hisilicon: Fix potential use-after-free in hix5hd2_rx()  The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48960)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: mdio: fix unbalanced fwnode reference count in mdio_device_release()  There is warning report about of_node refcount leak while probing mdio device:  OF: ERROR: memory leak, expected refcount 1 instead of 2, of_node_get()/of_node_put() unbalanced - destroy cset entry: attach overlay node /spi/soc@0/mdio@710700c0/ethernet@4  In of_mdiobus_register_device(), we increase fwnode refcount by fwnode_handle_get() before associating the of_node with mdio device, but it has never been decreased in normal path. Since that, in mdio_device_release(), it needs to call fwnode_handle_put() in addition instead of calling kfree() directly.  After above, just calling mdio_device_free() in the error handle path of of_mdiobus_register_device() is enough to keep the refcount balanced.(CVE-2022-48961)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: hisilicon: Fix potential use-after-free in hisi_femac_rx()  The skb is delivered to napi_gro_receive() which may free it, after calling this, dereferencing skb may trigger use-after-free.(CVE-2022-48962)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: mvneta: Prevent out of bounds read in mvneta_config_rss()  The pp-\u0026gt;indir[0] value comes from the user.  It is passed to:   if (cpu_online(pp-\u0026gt;rxq_def))  inside the mvneta_percpu_elect() function.  It needs bounds checkeding to ensure that it is not beyond the end of the cpu bitmap.(CVE-2022-48966)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  mac802154: fix missing INIT_LIST_HEAD in ieee802154_if_add()  Kernel fault injection test reports null-ptr-deref as follows:  BUG: kernel NULL pointer dereference, address: 0000000000000008 RIP: 0010:cfg802154_netdev_notifier_call+0x120/0x310 include/linux/list.h:114 Call Trace:  \u0026lt;TASK\u0026gt;  raw_notifier_call_chain+0x6d/0xa0 kernel/notifier.c:87  call_netdevice_notifiers_info+0x6e/0xc0 net/core/dev.c:1944  unregister_netdevice_many_notify+0x60d/0xcb0 net/core/dev.c:1982  unregister_netdevice_queue+0x154/0x1a0 net/core/dev.c:10879  register_netdevice+0x9a8/0xb90 net/core/dev.c:10083  ieee802154_if_add+0x6ed/0x7e0 net/mac802154/iface.c:659  ieee802154_register_hw+0x29c/0x330 net/mac802154/main.c:229  mcr20a_probe+0xaaa/0xcb1 drivers/net/ieee802154/mcr20a.c:1316  ieee802154_if_add() allocates wpan_dev as netdev\u0026apos;s private data, but not init the list in struct wpan_dev. cfg802154_netdev_notifier_call() manage the list when device register/unregister, and may lead to null-ptr-deref.  Use INIT_LIST_HEAD() on it to initialize it correctly.(CVE-2022-48972)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  gpiolib: fix memory leak in gpiochip_setup_dev()  Here is a backtrace report about memory leak detected in gpiochip_setup_dev():  unreferenced object 0xffff88810b406400 (size 512):   comm \u0026quot;python3\u0026quot;, pid 1682, jiffies 4295346908 (age 24.090s)   backtrace:     kmalloc_trace     device_add  device_private_init at drivers/base/core.c:3361    (inlined by) device_add at drivers/base/core.c:3411     cdev_device_add     gpiolib_cdev_register     gpiochip_setup_dev     gpiochip_add_data_with_key  gcdev_register() \u0026amp; gcdev_unregister() would call device_add() \u0026amp; device_del() (no matter CONFIG_GPIO_CDEV is enabled or not) to register/unregister device.  However, if device_add() succeeds, some resource (like struct device_private allocated by device_private_init()) is not released by device_del().  Therefore, after device_add() succeeds by gcdev_register(), it needs to call put_device() to release resource in the error handle path.  Here we move forward the register of release function, and let it release every piece of resource by put_device() instead of kfree().  While at it, fix another subtle issue, i.e. when gc-\u0026gt;ngpio is equal to 0, we still call kcalloc() and, in case of further error, kfree() on the ZERO_PTR pointer, which is not NULL. It\u0026apos;s not a bug per se, but rather waste of the resources and potentially wrong expectation about contents of the gdev-\u0026gt;descs variable.(CVE-2022-48975)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/shmem-helper: Remove errant put in error path  drm_gem_shmem_mmap() doesn\u0026apos;t own this reference, resulting in the GEM object getting prematurely freed leading to a later use-after-free.(CVE-2022-48981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: Fix crash when replugging CSR fake controllers  It seems fake CSR 5.0 clones can cause the suspend notifier to be registered twice causing the following kernel panic:  [   71.986122] Call Trace: [   71.986124]  \u0026lt;TASK\u0026gt; [   71.986125]  blocking_notifier_chain_register+0x33/0x60 [   71.986130]  hci_register_dev+0x316/0x3d0 [bluetooth 99b5497ea3d09708fa1366c1dc03288bf3cca8da] [   71.986154]  btusb_probe+0x979/0xd85 [btusb e1e0605a4f4c01984a4b9c8ac58c3666ae287477] [   71.986159]  ? __pm_runtime_set_status+0x1a9/0x300 [   71.986162]  ? ktime_get_mono_fast_ns+0x3e/0x90 [   71.986167]  usb_probe_interface+0xe3/0x2b0 [   71.986171]  really_probe+0xdb/0x380 [   71.986174]  ? pm_runtime_barrier+0x54/0x90 [   71.986177]  __driver_probe_device+0x78/0x170 [   71.986180]  driver_probe_device+0x1f/0x90 [   71.986183]  __device_attach_driver+0x89/0x110 [   71.986186]  ? driver_allows_async_probing+0x70/0x70 [   71.986189]  bus_for_each_drv+0x8c/0xe0 [   71.986192]  __device_attach+0xb2/0x1e0 [   71.986195]  bus_probe_device+0x92/0xb0 [   71.986198]  device_add+0x422/0x9a0 [   71.986201]  ? sysfs_merge_group+0xd4/0x110 [   71.986205]  usb_set_configuration+0x57a/0x820 [   71.986208]  usb_generic_driver_probe+0x4f/0x70 [   71.986211]  usb_probe_device+0x3a/0x110 [   71.986213]  really_probe+0xdb/0x380 [   71.986216]  ? pm_runtime_barrier+0x54/0x90 [   71.986219]  __driver_probe_device+0x78/0x170 [   71.986221]  driver_probe_device+0x1f/0x90 [   71.986224]  __device_attach_driver+0x89/0x110 [   71.986227]  ? driver_allows_async_probing+0x70/0x70 [   71.986230]  bus_for_each_drv+0x8c/0xe0 [   71.986232]  __device_attach+0xb2/0x1e0 [   71.986235]  bus_probe_device+0x92/0xb0 [   71.986237]  device_add+0x422/0x9a0 [   71.986239]  ? _dev_info+0x7d/0x98 [   71.986242]  ? blake2s_update+0x4c/0xc0 [   71.986246]  usb_new_device.cold+0x148/0x36d [   71.986250]  hub_event+0xa8a/0x1910 [   71.986255]  process_one_work+0x1c4/0x380 [   71.986259]  worker_thread+0x51/0x390 [   71.986262]  ? rescuer_thread+0x3b0/0x3b0 [   71.986264]  kthread+0xdb/0x110 [   71.986266]  ? kthread_complete_and_exit+0x20/0x20 [   71.986268]  ret_from_fork+0x1f/0x30 [   71.986273]  \u0026lt;/TASK\u0026gt; [   71.986274] ---[ end trace 0000000000000000 ]--- [   71.986284] btusb: probe of 2-1.6:1.0 failed with error -17(CVE-2022-48982)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: soc-pcm: Add NULL check in BE reparenting  Add NULL check in dpcm_be_reparent API, to handle kernel NULL pointer dereference error. The issue occurred in fuzzing test.(CVE-2022-48992)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Input: raydium_ts_i2c - fix memory leak in raydium_i2c_send()  There is a kmemleak when test the raydium_i2c_ts with bpf mock device:    unreferenced object 0xffff88812d3675a0 (size 8):     comm \u0026quot;python3\u0026quot;, pid 349, jiffies 4294741067 (age 95.695s)     hex dump (first 8 bytes):       11 0e 10 c0 01 00 04 00                          ........     backtrace:       [\u0026lt;0000000068427125\u0026gt;] __kmalloc+0x46/0x1b0       [\u0026lt;0000000090180f91\u0026gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]       [\u0026lt;000000006e631aee\u0026gt;] raydium_i2c_initialize.cold+0xbc/0x3e4 [raydium_i2c_ts]       [\u0026lt;00000000dc6fcf38\u0026gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]       [\u0026lt;00000000a310de16\u0026gt;] i2c_device_probe+0x651/0x680       [\u0026lt;00000000f5a96bf3\u0026gt;] really_probe+0x17c/0x3f0       [\u0026lt;00000000096ba499\u0026gt;] __driver_probe_device+0xe3/0x170       [\u0026lt;00000000c5acb4d9\u0026gt;] driver_probe_device+0x49/0x120       [\u0026lt;00000000264fe082\u0026gt;] __device_attach_driver+0xf7/0x150       [\u0026lt;00000000f919423c\u0026gt;] bus_for_each_drv+0x114/0x180       [\u0026lt;00000000e067feca\u0026gt;] __device_attach+0x1e5/0x2d0       [\u0026lt;0000000054301fc2\u0026gt;] bus_probe_device+0x126/0x140       [\u0026lt;00000000aad93b22\u0026gt;] device_add+0x810/0x1130       [\u0026lt;00000000c086a53f\u0026gt;] i2c_new_client_device+0x352/0x4e0       [\u0026lt;000000003c2c248c\u0026gt;] of_i2c_register_device+0xf1/0x110       [\u0026lt;00000000ffec4177\u0026gt;] of_i2c_notify+0x100/0x160   unreferenced object 0xffff88812d3675c8 (size 8):     comm \u0026quot;python3\u0026quot;, pid 349, jiffies 4294741070 (age 95.692s)     hex dump (first 8 bytes):       22 00 36 2d 81 88 ff ff                          \u0026quot;.6-....     backtrace:       [\u0026lt;0000000068427125\u0026gt;] __kmalloc+0x46/0x1b0       [\u0026lt;0000000090180f91\u0026gt;] raydium_i2c_send+0xd4/0x2bf [raydium_i2c_ts]       [\u0026lt;000000001d5c9620\u0026gt;] raydium_i2c_initialize.cold+0x223/0x3e4 [raydium_i2c_ts]       [\u0026lt;00000000dc6fcf38\u0026gt;] raydium_i2c_probe+0x3cd/0x6bc [raydium_i2c_ts]       [\u0026lt;00000000a310de16\u0026gt;] i2c_device_probe+0x651/0x680       [\u0026lt;00000000f5a96bf3\u0026gt;] really_probe+0x17c/0x3f0       [\u0026lt;00000000096ba499\u0026gt;] __driver_probe_device+0xe3/0x170       [\u0026lt;00000000c5acb4d9\u0026gt;] driver_probe_device+0x49/0x120       [\u0026lt;00000000264fe082\u0026gt;] __device_attach_driver+0xf7/0x150       [\u0026lt;00000000f919423c\u0026gt;] bus_for_each_drv+0x114/0x180       [\u0026lt;00000000e067feca\u0026gt;] __device_attach+0x1e5/0x2d0       [\u0026lt;0000000054301fc2\u0026gt;] bus_probe_device+0x126/0x140       [\u0026lt;00000000aad93b22\u0026gt;] device_add+0x810/0x1130       [\u0026lt;00000000c086a53f\u0026gt;] i2c_new_client_device+0x352/0x4e0       [\u0026lt;000000003c2c248c\u0026gt;] of_i2c_register_device+0xf1/0x110       [\u0026lt;00000000ffec4177\u0026gt;] of_i2c_notify+0x100/0x160  After BANK_SWITCH command from i2c BUS, no matter success or error happened, the tx_buf should be freed.(CVE-2022-48995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  riscv: Sync efi page table\u0026apos;s kernel mappings before switching  The EFI page table is initially created as a copy of the kernel page table. With VMAP_STACK enabled, kernel stacks are allocated in the vmalloc area: if the stack is allocated in a new PGD (one that was not present at the moment of the efi page table creation or not synced in a previous vmalloc fault), the kernel will take a trap when switching to the efi page table when the vmalloc kernel stack is accessed, resulting in a kernel panic.  Fix that by updating the efi kernel mappings before switching to the efi page table.(CVE-2022-49004)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ASoC: ops: Fix bounds check for _sx controls  For _sx controls the semantics of the max field is not the usual one, max is the number of steps rather than the maximum value. This means that our check in snd_soc_put_volsw_sx() needs to just check against the maximum value.(CVE-2022-49005)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  hwmon: (coretemp) fix pci device refcount leak in nv1a_ram_new()  As comment of pci_get_domain_bus_and_slot() says, it returns a pci device with refcount increment, when finish using it, the caller must decrement the reference count by calling pci_dev_put(). So call it after using to avoid refcount leak.(CVE-2022-49011)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tipc: re-fetch skb cb after tipc_msg_validate  As the call trace shows, the original skb was freed in tipc_msg_validate(), and dereferencing the old skb cb would cause an use-after-free crash.    BUG: KASAN: use-after-free in tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]   Call Trace:    \u0026lt;IRQ\u0026gt;    tipc_crypto_rcv_complete+0x1835/0x2240 [tipc]    tipc_crypto_rcv+0xd32/0x1ec0 [tipc]    tipc_rcv+0x744/0x1150 [tipc]   ...   Allocated by task 47078:    kmem_cache_alloc_node+0x158/0x4d0    __alloc_skb+0x1c1/0x270    tipc_buf_acquire+0x1e/0xe0 [tipc]    tipc_msg_create+0x33/0x1c0 [tipc]    tipc_link_build_proto_msg+0x38a/0x2100 [tipc]    tipc_link_timeout+0x8b8/0xef0 [tipc]    tipc_node_timeout+0x2a1/0x960 [tipc]    call_timer_fn+0x2d/0x1c0   ...   Freed by task 47078:    tipc_msg_validate+0x7b/0x440 [tipc]    tipc_crypto_rcv_complete+0x4b5/0x2240 [tipc]    tipc_crypto_rcv+0xd32/0x1ec0 [tipc]    tipc_rcv+0x744/0x1150 [tipc]  This patch fixes it by re-fetching the skb cb from the new allocated skb after calling tipc_msg_validate().(CVE-2022-49017)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/9p: Fix a potential socket leak in p9_socket_open  Both p9_fd_create_tcp() and p9_fd_create_unix() will call p9_socket_open(). If the creation of p9_trans_fd fails, p9_fd_create_tcp() and p9_fd_create_unix() will return an error directly instead of releasing the cscoket, which will result in a socket leak.  This patch adds sock_release() to fix the leak issue.(CVE-2022-49020)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net: phy: fix null-ptr-deref while probe() failed  I got a null-ptr-deref report as following when doing fault injection test:  BUG: kernel NULL pointer dereference, address: 0000000000000058 Oops: 0000 [#1] PREEMPT SMP KASAN PTI CPU: 1 PID: 253 Comm: 507-spi-dm9051 Tainted: G    B            N 6.1.0-rc3+ Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:klist_put+0x2d/0xd0 Call Trace:  \u0026lt;TASK\u0026gt;  klist_remove+0xf1/0x1c0  device_release_driver_internal+0x23e/0x2d0  bus_remove_device+0x1bd/0x240  device_del+0x357/0x770  phy_device_remove+0x11/0x30  mdiobus_unregister+0xa5/0x140  release_nodes+0x6a/0xa0  devres_release_all+0xf8/0x150  device_unbind_cleanup+0x19/0xd0  //probe path: phy_device_register()   device_add()  phy_connect   phy_attach_direct() //set device driver     probe() //it\u0026apos;s failed, driver is not bound     device_bind_driver() // probe failed, it\u0026apos;s not called  //remove path: phy_device_remove()   device_del()     device_release_driver_internal()       __device_release_driver() //dev-\u0026gt;drv is not NULL         klist_remove() \u0026lt;- knode_driver is not added yet, cause null-ptr-deref  In phy_attach_direct(), after setting the \u0026apos;dev-\u0026gt;driver\u0026apos;, probe() fails, device_bind_driver() is not called, so the knode_driver-\u0026gt;n_klist is not set, then it causes null-ptr-deref in __device_release_driver() while deleting device. Fix this by setting dev-\u0026gt;driver to NULL in the error path in phy_attach_direct().(CVE-2022-49021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: cfg80211: fix buffer overflow in elem comparison  For vendor elements, the code here assumes that 5 octets are present without checking. Since the element itself is already checked to fit, we only need to check the length.(CVE-2022-49023)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: health: afe4403: Fix oob read in afe4403_read_raw  KASAN report out-of-bounds read as follows:  BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0 Read of size 4 at addr ffffffffc02ac638 by task cat/279  Call Trace:  afe4403_read_raw  iio_read_channel_info  dev_attr_show  The buggy address belongs to the variable:  afe4403_channel_leds+0x18/0xffffffffffffe9e0  This issue can be reproduced by singe command:   $ cat /sys/bus/spi/devices/spi0.0/iio\\:device0/in_intensity6_raw  The array size of afe4403_channel_leds is less than channels, so access with chan-\u0026gt;address cause OOB read in afe4403_read_raw. Fix it by moving access before use it.(CVE-2022-49031)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  iio: health: afe4404: Fix oob read in afe4404_[read|write]_raw  KASAN report out-of-bounds read as follows:  BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380 Read of size 4 at addr ffffffffc00e4658 by task cat/278  Call Trace:  afe4404_read_raw  iio_read_channel_info  dev_attr_show  The buggy address belongs to the variable:  afe4404_channel_leds+0x18/0xffffffffffffe9c0  This issue can be reproduce by singe command:   $ cat /sys/bus/i2c/devices/0-0058/iio\\:device0/in_intensity6_raw  The array size of afe4404_channel_leds and afe4404_channel_offdacs are less than channels, so access with chan-\u0026gt;address cause OOB read in afe4404_[read|write]_raw. Fix it by moving access before use them.(CVE-2022-49032)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nmemcg_write_event_control(): fix a user-triggerable oops\r\n\r\nwe are *not* guaranteed that anything past the terminating NUL\nis mapped (let alone initialized with anything sane).(CVE-2024-45021)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ngtp: fix a potential NULL pointer dereference\r\n\r\nWhen sockfd_lookup() fails, gtp_encap_enable_socket() returns a\nNULL pointer, but its callers only check for error pointers thus miss\nthe NULL pointer case.\r\n\r\nFix it by returning an error pointer with the error code carried from\nsockfd_lookup().\r\n\r\n(I found this bug during code inspection.)(CVE-2024-46677)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\ndrm/amd/display: Check BIOS images before it is used\r\n\r\nBIOS images may fail to load and null checks are added before they are\nused.\r\n\r\nThis fixes 6 NULL_RETURNS issues reported by Coverity.(CVE-2024-46809)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nsmack: tcp: ipv4, fix incorrect labeling\r\n\r\nCurrently, Smack mirrors the label of incoming tcp/ipv4 connections:\nwhen a label \u0026apos;foo\u0026apos; connects to a label \u0026apos;bar\u0026apos; with tcp/ipv4,\n\u0026apos;foo\u0026apos; always gets \u0026apos;foo\u0026apos; in returned ipv4 packets. So,\n1) returned packets are incorrectly labeled (\u0026apos;foo\u0026apos; instead of \u0026apos;bar\u0026apos;)\n2) \u0026apos;bar\u0026apos; can write to \u0026apos;foo\u0026apos; without being authorized to write.\r\n\r\nHere is a scenario how to see this:\r\n\r\n* Take two machines, let\u0026apos;s call them C and S,\n   with active Smack in the default state\n   (no settings, no rules, no labeled hosts, only builtin labels)\r\n\r\n* At S, add Smack rule \u0026apos;foo bar w\u0026apos;\n   (labels \u0026apos;foo\u0026apos; and \u0026apos;bar\u0026apos; are instantiated at S at this moment)\r\n\r\n* At S, at label \u0026apos;bar\u0026apos;, launch a program\n   that listens for incoming tcp/ipv4 connections\r\n\r\n* From C, at label \u0026apos;foo\u0026apos;, connect to the listener at S.\n   (label \u0026apos;foo\u0026apos; is instantiated at C at this moment)\n   Connection succeedes and works.\r\n\r\n* Send some data in both directions.\n* Collect network traffic of this connection.\r\n\r\nAll packets in both directions are labeled with the CIPSO\nof the label \u0026apos;foo\u0026apos;. Hence, label \u0026apos;bar\u0026apos; writes to \u0026apos;foo\u0026apos; without\nbeing authorized, and even without ever being known at C.\r\n\r\nIf anybody cares: exactly the same happens with DCCP.\r\n\r\nThis behavior 1st manifested in release 2.6.29.4 (see Fixes below)\nand it looks unintentional. At least, no explanation was provided.\r\n\r\nI changed returned packes label into the \u0026apos;bar\u0026apos;,\nto bring it into line with the Smack documentation claims.(CVE-2024-47659)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nfsnotify: clear PARENT_WATCHED flags lazily\r\n\r\nIn some setups directories can have many (usually negative) dentries.\nHence __fsnotify_update_child_dentry_flags() function can take a\nsignificant amount of time. Since the bulk of this function happens\nunder inode-\u0026gt;i_lock this causes a significant contention on the lock\nwhen we remove the watch from the directory as the\n__fsnotify_update_child_dentry_flags() call from fsnotify_recalc_mask()\nraces with __fsnotify_update_child_dentry_flags() calls from\n__fsnotify_parent() happening on children. This can lead upto softlockup\nreports reported by users.\r\n\r\nFix the problem by calling fsnotify_update_children_dentry_flags() to\nset PARENT_WATCHED flags only when parent starts watching children.\r\n\r\nWhen parent stops watching children, clear false positive PARENT_WATCHED\nflags lazily in __fsnotify_parent() for each accessed child.(CVE-2024-47660)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nlib/generic-radix-tree.c: Fix rare race in __genradix_ptr_alloc()\r\n\r\nIf we need to increase the tree depth, allocate a new node, and then\nrace with another thread that increased the tree depth before us, we\u0026apos;ll\nstill have a preallocated node that might be used later.\r\n\r\nIf we then use that node for a new non-root node, it\u0026apos;ll still have a\npointer to the old root instead of being zeroed - fix this by zeroing it\nin the cmpxchg failure path.(CVE-2024-47668)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:\r\n\r\nwifi: iwlwifi: mvm: pause TCM when the firmware is stopped\r\n\r\nNot doing so will make us send a host command to the transport while the\nfirmware is not alive, which will trigger a WARNING.\r\n\r\nbad state = 0\nWARNING: CPU: 2 PID: 17434 at drivers/net/wireless/intel/iwlwifi/iwl-trans.c:115 iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nRIP: 0010:iwl_trans_send_cmd+0x1cb/0x1e0 [iwlwifi]\nCall Trace:\n \u0026lt;TASK\u0026gt;\n iwl_mvm_send_cmd+0x40/0xc0 [iwlmvm]\n iwl_mvm_config_scan+0x198/0x260 [iwlmvm]\n iwl_mvm_recalc_tcm+0x730/0x11d0 [iwlmvm]\n iwl_mvm_tcm_work+0x1d/0x30 [iwlmvm]\n process_one_work+0x29e/0x640\n worker_thread+0x2df/0x690\n ? rescuer_thread+0x540/0x540\n kthread+0x192/0x1e0\n ? set_kthread_struct+0x90/0x90\n ret_from_fork+0x22/0x30(CVE-2024-47673)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: get rid of online repaire on corrupted directory  syzbot reports a f2fs bug as below:  kernel BUG at fs/f2fs/inode.c:896! RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896 Call Trace:  evict+0x532/0x950 fs/inode.c:704  dispose_list fs/inode.c:747 [inline]  evict_inodes+0x5f9/0x690 fs/inode.c:797  generic_shutdown_super+0x9d/0x2d0 fs/super.c:627  kill_block_super+0x44/0x90 fs/super.c:1696  kill_f2fs_super+0x344/0x690 fs/f2fs/super.c:4898  deactivate_locked_super+0xc4/0x130 fs/super.c:473  cleanup_mnt+0x41f/0x4b0 fs/namespace.c:1373  task_work_run+0x24f/0x310 kernel/task_work.c:228  ptrace_notify+0x2d2/0x380 kernel/signal.c:2402  ptrace_report_syscall include/linux/ptrace.h:415 [inline]  ptrace_report_syscall_exit include/linux/ptrace.h:477 [inline]  syscall_exit_work+0xc6/0x190 kernel/entry/common.c:173  syscall_exit_to_user_mode_prepare kernel/entry/common.c:200 [inline]  __syscall_exit_to_user_mode_work kernel/entry/common.c:205 [inline]  syscall_exit_to_user_mode+0x279/0x370 kernel/entry/common.c:218  do_syscall_64+0x100/0x230 arch/x86/entry/common.c:89  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0010:f2fs_evict_inode+0x1598/0x15c0 fs/f2fs/inode.c:896  Online repaire on corrupted directory in f2fs_lookup() can generate dirty data/meta while racing w/ readonly remount, it may leave dirty inode after filesystem becomes readonly, however, checkpoint() will skips flushing dirty inode in a state of readonly mode, result in above panic.  Let\u0026apos;s get rid of online repaire in f2fs_lookup(), and leave the work to fsck.f2fs.(CVE-2024-47690)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  f2fs: fix to avoid use-after-free in f2fs_stop_gc_thread()  syzbot reports a f2fs bug as below:   __dump_stack lib/dump_stack.c:88 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114  print_report+0xe8/0x550 mm/kasan/report.c:491  kasan_report+0x143/0x180 mm/kasan/report.c:601  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189  instrument_atomic_read_write include/linux/instrumented.h:96 [inline]  atomic_fetch_add_relaxed include/linux/atomic/atomic-instrumented.h:252 [inline]  __refcount_add include/linux/refcount.h:184 [inline]  __refcount_inc include/linux/refcount.h:241 [inline]  refcount_inc include/linux/refcount.h:258 [inline]  get_task_struct include/linux/sched/task.h:118 [inline]  kthread_stop+0xca/0x630 kernel/kthread.c:704  f2fs_stop_gc_thread+0x65/0xb0 fs/f2fs/gc.c:210  f2fs_do_shutdown+0x192/0x540 fs/f2fs/file.c:2283  f2fs_ioc_shutdown fs/f2fs/file.c:2325 [inline]  __f2fs_ioctl+0x443a/0xbe60 fs/f2fs/file.c:4325  vfs_ioctl fs/ioctl.c:51 [inline]  __do_sys_ioctl fs/ioctl.c:907 [inline]  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  The root cause is below race condition, it may cause use-after-free issue in sbi-\u0026gt;gc_th pointer.  - remount  - f2fs_remount   - f2fs_stop_gc_thread    - kfree(gc_th)     - f2fs_ioc_shutdown      - f2fs_do_shutdown       - f2fs_stop_gc_thread        - kthread_stop(gc_th-\u0026gt;f2fs_gc_task)    : sbi-\u0026gt;gc_thread = NULL;  We will call f2fs_do_shutdown() in two paths: - for f2fs_ioc_shutdown() path, we should grab sb-\u0026gt;s_umount semaphore for fixing. - for f2fs_shutdown() path, it\u0026apos;s safe since caller has already grabbed sb-\u0026gt;s_umount semaphore.(CVE-2024-47691)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nfsd: return -EINVAL when namelen is 0  When we have a corrupted main.sqlite in /var/lib/nfs/nfsdcld/, it may result in namelen being 0, which will cause memdup_user() to return ZERO_SIZE_PTR. When we access the name.data that has been assigned the value of ZERO_SIZE_PTR in nfs4_client_to_reclaim(), null pointer dereference is triggered.  [ T1205] ================================================================== [ T1205] BUG: KASAN: null-ptr-deref in nfs4_client_to_reclaim+0xe9/0x260 [ T1205] Read of size 1 at addr 0000000000000010 by task nfsdcld/1205 [ T1205] [ T1205] CPU: 11 PID: 1205 Comm: nfsdcld Not tainted 5.10.0-00003-g2c1423731b8d #406 [ T1205] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 [ T1205] Call Trace: [ T1205]  dump_stack+0x9a/0xd0 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  __kasan_report.cold+0x34/0x84 [ T1205]  ? nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  kasan_report+0x3a/0x50 [ T1205]  nfs4_client_to_reclaim+0xe9/0x260 [ T1205]  ? nfsd4_release_lockowner+0x410/0x410 [ T1205]  cld_pipe_downcall+0x5ca/0x760 [ T1205]  ? nfsd4_cld_tracking_exit+0x1d0/0x1d0 [ T1205]  ? down_write_killable_nested+0x170/0x170 [ T1205]  ? avc_policy_seqno+0x28/0x40 [ T1205]  ? selinux_file_permission+0x1b4/0x1e0 [ T1205]  rpc_pipe_write+0x84/0xb0 [ T1205]  vfs_write+0x143/0x520 [ T1205]  ksys_write+0xc9/0x170 [ T1205]  ? __ia32_sys_read+0x50/0x50 [ T1205]  ? ktime_get_coarse_real_ts64+0xfe/0x110 [ T1205]  ? ktime_get_coarse_real_ts64+0xa2/0x110 [ T1205]  do_syscall_64+0x33/0x40 [ T1205]  entry_SYSCALL_64_after_hwframe+0x67/0xd1 [ T1205] RIP: 0033:0x7fdbdb761bc7 [ T1205] Code: 0f 00 f7 d8 64 89 02 48 c7 c0 ff ff ff ff eb b7 0f 1f 00 f3 0f 1e fa 64 8b 04 25 18 00 00 00 85 c0 75 10 b8 01 00 00 00 0f 05 \u0026lt;48\u0026gt; 3d 00 f0 ff ff 77 514 [ T1205] RSP: 002b:00007fff8c4b7248 EFLAGS: 00000246 ORIG_RAX: 0000000000000001 [ T1205] RAX: ffffffffffffffda RBX: 000000000000042b RCX: 00007fdbdb761bc7 [ T1205] RDX: 000000000000042b RSI: 00007fff8c4b75f0 RDI: 0000000000000008 [ T1205] RBP: 00007fdbdb761bb0 R08: 0000000000000000 R09: 0000000000000001 [ T1205] R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000042b [ T1205] R13: 0000000000000008 R14: 00007fff8c4b75f0 R15: 0000000000000000 [ T1205] ==================================================================  Fix it by checking namelen.(CVE-2024-47692)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  IB/core: Fix ib_cache_setup_one error flow cleanup  When ib_cache_update return an error, we exit ib_cache_setup_one instantly with no proper cleanup, even though before this we had already successfully done gid_table_setup_one, that results in the kernel WARN below.  Do proper cleanup using gid_table_cleanup_one before returning the err in order to fix the issue.  WARNING: CPU: 4 PID: 922 at drivers/infiniband/core/cache.c:806 gid_table_release_one+0x181/0x1a0 Modules linked in: CPU: 4 UID: 0 PID: 922 Comm: c_repro Not tainted 6.11.0-rc1+ #3 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:gid_table_release_one+0x181/0x1a0 Code: 44 8b 38 75 0c e8 2f cb 34 ff 4d 8b b5 28 05 00 00 e8 23 cb 34 ff 44 89 f9 89 da 4c 89 f6 48 c7 c7 d0 58 14 83 e8 4f de 21 ff \u0026lt;0f\u0026gt; 0b 4c 8b 75 30 e9 54 ff ff ff 48 8    3 c4 10 5b 5d 41 5c 41 5d 41 RSP: 0018:ffffc90002b835b0 EFLAGS: 00010286 RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff811c8527 RDX: 0000000000000000 RSI: ffffffff811c8534 RDI: 0000000000000001 RBP: ffff8881011b3d00 R08: ffff88810b3abe00 R09: 205d303839303631 R10: 666572207972746e R11: 72746e6520444947 R12: 0000000000000001 R13: ffff888106390000 R14: ffff8881011f2110 R15: 0000000000000001 FS:  00007fecc3b70800(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000020000340 CR3: 000000010435a001 CR4: 00000000003706b0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? show_regs+0x94/0xa0  ? __warn+0x9e/0x1c0  ? gid_table_release_one+0x181/0x1a0  ? report_bug+0x1f9/0x340  ? gid_table_release_one+0x181/0x1a0  ? handle_bug+0xa2/0x110  ? exc_invalid_op+0x31/0xa0  ? asm_exc_invalid_op+0x16/0x20  ? __warn_printk+0xc7/0x180  ? __warn_printk+0xd4/0x180  ? gid_table_release_one+0x181/0x1a0  ib_device_release+0x71/0xe0  ? __pfx_ib_device_release+0x10/0x10  device_release+0x44/0xd0  kobject_put+0x135/0x3d0  put_device+0x20/0x30  rxe_net_add+0x7d/0xa0  rxe_newlink+0xd7/0x190  nldev_newlink+0x1b0/0x2a0  ? __pfx_nldev_newlink+0x10/0x10  rdma_nl_rcv_msg+0x1ad/0x2e0  rdma_nl_rcv_skb.constprop.0+0x176/0x210  netlink_unicast+0x2de/0x400  netlink_sendmsg+0x306/0x660  __sock_sendmsg+0x110/0x120  ____sys_sendmsg+0x30e/0x390  ___sys_sendmsg+0x9b/0xf0  ? kstrtouint+0x6e/0xa0  ? kstrtouint_from_user+0x7c/0xb0  ? get_pid_task+0xb0/0xd0  ? proc_fail_nth_write+0x5b/0x140  ? __fget_light+0x9a/0x200  ? preempt_count_add+0x47/0xa0  __sys_sendmsg+0x61/0xd0  do_syscall_64+0x50/0x110  entry_SYSCALL_64_after_hwframe+0x76/0x7e(CVE-2024-47693)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  RDMA/iwcm: Fix WARNING:at_kernel/workqueue.c:#check_flush_dependency  In the commit aee2424246f9 (\u0026quot;RDMA/iwcm: Fix a use-after-free related to destroying CM IDs\u0026quot;), the function flush_workqueue is invoked to flush the work queue iwcm_wq.  But at that time, the work queue iwcm_wq was created via the function alloc_ordered_workqueue without the flag WQ_MEM_RECLAIM.  Because the current process is trying to flush the whole iwcm_wq, if iwcm_wq doesn\u0026apos;t have the flag WQ_MEM_RECLAIM, verify that the current process is not reclaiming memory or running on a workqueue which doesn\u0026apos;t have the flag WQ_MEM_RECLAIM as that can break forward-progress guarantee leading to a deadlock.  The call trace is as below:  [  125.350876][ T1430] Call Trace: [  125.356281][ T1430]  \u0026lt;TASK\u0026gt; [ 125.361285][ T1430] ? __warn (kernel/panic.c:693) [ 125.367640][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.375689][ T1430] ? report_bug (lib/bug.c:180 lib/bug.c:219) [ 125.382505][ T1430] ? handle_bug (arch/x86/kernel/traps.c:239) [ 125.388987][ T1430] ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) [ 125.395831][ T1430] ? asm_exc_invalid_op (arch/x86/include/asm/idtentry.h:621) [ 125.403125][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.410984][ T1430] ? check_flush_dependency (kernel/workqueue.c:3706 (discriminator 9)) [ 125.418764][ T1430] __flush_workqueue (kernel/workqueue.c:3970) [ 125.426021][ T1430] ? __pfx___might_resched (kernel/sched/core.c:10151) [ 125.433431][ T1430] ? destroy_cm_id (drivers/infiniband/core/iwcm.c:375) iw_cm [ 125.441209][ T1430] ? __pfx___flush_workqueue (kernel/workqueue.c:3910) [ 125.473900][ T1430] ? _raw_spin_lock_irqsave (arch/x86/include/asm/atomic.h:107 include/linux/atomic/atomic-arch-fallback.h:2170 include/linux/atomic/atomic-instrumented.h:1302 include/asm-generic/qspinlock.h:111 include/linux/spinlock.h:187 include/linux/spinlock_api_smp.h:111 kernel/locking/spinlock.c:162) [ 125.473909][ T1430] ? __pfx__raw_spin_lock_irqsave (kernel/locking/spinlock.c:161) [ 125.482537][ T1430] _destroy_id (drivers/infiniband/core/cma.c:2044) rdma_cm [ 125.495072][ T1430] nvme_rdma_free_queue (drivers/nvme/host/rdma.c:656 drivers/nvme/host/rdma.c:650) nvme_rdma [ 125.505827][ T1430] nvme_rdma_reset_ctrl_work (drivers/nvme/host/rdma.c:2180) nvme_rdma [ 125.505831][ T1430] process_one_work (kernel/workqueue.c:3231) [ 125.515122][ T1430] worker_thread (kernel/workqueue.c:3306 kernel/workqueue.c:3393) [ 125.515127][ T1430] ? __pfx_worker_thread (kernel/workqueue.c:3339) [ 125.531837][ T1430] kthread (kernel/kthread.c:389) [ 125.539864][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.550628][ T1430] ret_from_fork (arch/x86/kernel/process.c:147) [ 125.558840][ T1430] ? __pfx_kthread (kernel/kthread.c:342) [ 125.558844][ T1430] ret_from_fork_asm (arch/x86/entry/entry_64.S:257) [  125.566487][ T1430]  \u0026lt;/TASK\u0026gt; [  125.566488][ T1430] ---[ end trace 0000000000000000 ]---(CVE-2024-47696)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nilfs2: fix potential null-ptr-deref in nilfs_btree_insert()  Patch series \u0026quot;nilfs2: fix potential issues with empty b-tree nodes\u0026quot;.  This series addresses three potential issues with empty b-tree nodes that can occur with corrupted filesystem images, including one recently discovered by syzbot.   This patch (of 3):  If a b-tree is broken on the device, and the b-tree height is greater than 2 (the level of the root node is greater than 1) even if the number of child nodes of the b-tree root is 0, a NULL pointer dereference occurs in nilfs_btree_prepare_insert(), which is called from nilfs_btree_insert().  This is because, when the number of child nodes of the b-tree root is 0, nilfs_btree_do_lookup() does not set the block buffer head in any of path[x].bp_bh, leaving it as the initial value of NULL, but if the level of the b-tree root node is greater than 1, nilfs_btree_get_nonroot_node(), which accesses the buffer memory of path[x].bp_bh, is called.  Fix this issue by adding a check to nilfs_btree_root_broken(), which performs sanity checks when reading the root node from the device, to detect this inconsistency.  Thanks to Lizhi Xu for trying to solve the bug and clarifying the cause early on.(CVE-2024-47699)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid OOB when system.data xattr changes underneath the filesystem  When looking up for an entry in an inlined directory, if e_value_offs is changed underneath the filesystem by some change in the block device, it will lead to an out-of-bounds access that KASAN detects as an UAF.  EXT4-fs (loop0): mounted filesystem 00000000-0000-0000-0000-000000000000 r/w without journal. Quota mode: none. loop0: detected capacity change from 2048 to 2047 ================================================================== BUG: KASAN: use-after-free in ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500 Read of size 1 at addr ffff88803e91130f by task syz-executor269/5103  CPU: 0 UID: 0 PID: 5103 Comm: syz-executor269 Not tainted 6.11.0-rc4-syzkaller #0 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0x169/0x550 mm/kasan/report.c:488  kasan_report+0x143/0x180 mm/kasan/report.c:601  ext4_search_dir+0xf2/0x1c0 fs/ext4/namei.c:1500  ext4_find_inline_entry+0x4be/0x5e0 fs/ext4/inline.c:1697  __ext4_find_entry+0x2b4/0x1b30 fs/ext4/namei.c:1573  ext4_lookup_entry fs/ext4/namei.c:1727 [inline]  ext4_lookup+0x15f/0x750 fs/ext4/namei.c:1795  lookup_one_qstr_excl+0x11f/0x260 fs/namei.c:1633  filename_create+0x297/0x540 fs/namei.c:3980  do_symlinkat+0xf9/0x3a0 fs/namei.c:4587  __do_sys_symlinkat fs/namei.c:4610 [inline]  __se_sys_symlinkat fs/namei.c:4607 [inline]  __x64_sys_symlinkat+0x95/0xb0 fs/namei.c:4607  do_syscall_x64 arch/x86/entry/common.c:52 [inline]  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f RIP: 0033:0x7f3e73ced469 Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 21 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 \u0026lt;48\u0026gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48 RSP: 002b:00007fff4d40c258 EFLAGS: 00000246 ORIG_RAX: 000000000000010a RAX: ffffffffffffffda RBX: 0032656c69662f2e RCX: 00007f3e73ced469 RDX: 0000000020000200 RSI: 00000000ffffff9c RDI: 00000000200001c0 RBP: 0000000000000000 R08: 00007fff4d40c290 R09: 00007fff4d40c290 R10: 0023706f6f6c2f76 R11: 0000000000000246 R12: 00007fff4d40c27c R13: 0000000000000003 R14: 431bde82d7b634db R15: 00007fff4d40c2b0  \u0026lt;/TASK\u0026gt;  Calling ext4_xattr_ibody_find right after reading the inode with ext4_get_inode_loc will lead to a check of the validity of the xattrs, avoiding this problem.(CVE-2024-47701)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf, lsm: Add check for BPF LSM return value  A bpf prog returning a positive number attached to file_alloc_security hook makes kernel panic.  This happens because file system can not filter out the positive number returned by the LSM prog using IS_ERR, and misinterprets this positive number as a file pointer.  Given that hook file_alloc_security never returned positive number before the introduction of BPF LSM, and other BPF LSM hooks may encounter similar issues, this patch adds LSM return value check in verifier, to ensure no unexpected value is returned.(CVE-2024-47703)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  block: fix potential invalid pointer dereference in blk_add_partition  The blk_add_partition() function initially used a single if-condition (IS_ERR(part)) to check for errors when adding a partition. This was modified to handle the specific case of -ENXIO separately, allowing the function to proceed without logging the error in this case. However, this change unintentionally left a path where md_autodetect_dev() could be called without confirming that part is a valid pointer.  This commit separates the error handling logic by splitting the initial if-condition, improving code readability and handling specific error scenarios explicitly. The function now distinguishes the general error case from -ENXIO without altering the existing behavior of md_autodetect_dev() calls.(CVE-2024-47705)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  jfs: fix out-of-bounds in dbNextAG() and diAlloc()  In dbNextAG() , there is no check for the case where bmp-\u0026gt;db_numag is greater or same than MAXAG due to a polluted image, which causes an out-of-bounds. Therefore, a bounds check should be added in dbMount().  And in dbNextAG(), a check for the case where agpref is greater than bmp-\u0026gt;db_numag should be added, so an out-of-bounds exception should be prevented.  Additionally, a check for the case where agno is greater or same than MAXAG should be added in diAlloc() to prevent out-of-bounds.(CVE-2024-47723)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  padata: use integer wrap around to prevent deadlock on seq_nr overflow  When submitting more than 2^32 padata objects to padata_do_serial, the current sorting implementation incorrectly sorts padata objects with overflowed seq_nr, causing them to be placed before existing objects in the reorder list. This leads to a deadlock in the serialization process as padata_find_next cannot match padata-\u0026gt;seq_nr and pd-\u0026gt;processed because the padata instance with overflowed seq_nr will be selected next.  To fix this, we use an unsigned integer wrap around to correctly sort padata objects in scenarios with integer overflow.(CVE-2024-47739)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  firmware_loader: Block path traversal  Most firmware names are hardcoded strings, or are constructed from fairly constrained format strings where the dynamic parts are just some hex numbers or such.  However, there are a couple codepaths in the kernel where firmware file names contain string components that are passed through from a device or semi-privileged userspace; the ones I could find (not counting interfaces that require root privileges) are:   - lpfc_sli4_request_firmware_update() seems to construct the firmware    filename from \u0026quot;ModelName\u0026quot;, a string that was previously parsed out of    some descriptor (\u0026quot;Vital Product Data\u0026quot;) in lpfc_fill_vpd()  - nfp_net_fw_find() seems to construct a firmware filename from a model    name coming from nfp_hwinfo_lookup(pf-\u0026gt;hwinfo, \u0026quot;nffw.partno\u0026quot;), which I    think parses some descriptor that was read from the device.    (But this case likely isn\u0026apos;t exploitable because the format string looks    like \u0026quot;netronome/nic_%s\u0026quot;, and there shouldn\u0026apos;t be any *folders* starting    with \u0026quot;netronome/nic_\u0026quot;. The previous case was different because there,    the \u0026quot;%s\u0026quot; is *at the start* of the format string.)  - module_flash_fw_schedule() is reachable from the    ETHTOOL_MSG_MODULE_FW_FLASH_ACT netlink command, which is marked as    GENL_UNS_ADMIN_PERM (meaning CAP_NET_ADMIN inside a user namespace is    enough to pass the privilege check), and takes a userspace-provided    firmware name.    (But I think to reach this case, you need to have CAP_NET_ADMIN over a    network namespace that a special kind of ethernet device is mapped into,    so I think this is not a viable attack path in practice.)  Fix it by rejecting any firmware names containing \u0026quot;..\u0026quot; path components.  For what it\u0026apos;s worth, I went looking and haven\u0026apos;t found any USB device drivers that use the firmware loader dangerously.(CVE-2024-47742)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vhost_vdpa: assign irq bypass producer token correctly  We used to call irq_bypass_unregister_producer() in vhost_vdpa_setup_vq_irq() which is problematic as we don\u0026apos;t know if the token pointer is still valid or not.  Actually, we use the eventfd_ctx as the token so the life cycle of the token should be bound to the VHOST_SET_VRING_CALL instead of vhost_vdpa_setup_vq_irq() which could be called by set_status().  Fixing this by setting up irq bypass producer\u0026apos;s token when handling VHOST_SET_VRING_CALL and un-registering the producer before calling vhost_vring_ioctl() to prevent a possible use after free as eventfd could have been released in vhost_vring_ioctl(). And such registering and unregistering will only be done if DRIVER_OK is set.(CVE-2024-47748)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  PCI: keystone: Fix if-statement expression in ks_pcie_quirk()  This code accidentally uses \u0026amp;\u0026amp; where || was intended.  It potentially results in a NULL dereference.  Thus, fix the if-statement expression to use the correct condition.  [kwilczynski: commit log](CVE-2024-47756)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  nbd: fix race between timeout and normal completion  If request timetout is handled by nbd_requeue_cmd(), normal completion has to be stopped for avoiding to complete this requeued request, other use-after-free can be triggered.  Fix the race by clearing NBD_CMD_INFLIGHT in nbd_requeue_cmd(), meantime make sure that cmd-\u0026gt;lock is grabbed for clearing the flag and the requeue.(CVE-2024-49855)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  efistub/tpm: Use ACPI reclaim memory for event log to avoid corruption  The TPM event log table is a Linux specific construct, where the data produced by the GetEventLog() boot service is cached in memory, and passed on to the OS using an EFI configuration table.  The use of EFI_LOADER_DATA here results in the region being left unreserved in the E820 memory map constructed by the EFI stub, and this is the memory description that is passed on to the incoming kernel by kexec, which is therefore unaware that the region should be reserved.  Even though the utility of the TPM2 event log after a kexec is questionable, any corruption might send the parsing code off into the weeds and crash the kernel. So let\u0026apos;s use EFI_ACPI_RECLAIM_MEMORY instead, which is always treated as reserved by the E820 conversion logic.(CVE-2024-49858)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: sysfs: validate return type of _STR method  Only buffer objects are valid return values of _STR.  If something else is returned description_show() will access invalid memory.(CVE-2024-49860)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  vhost/scsi: null-ptr-dereference in vhost_scsi_get_req()  Since commit 3f8ca2e115e5 (\u0026quot;vhost/scsi: Extract common handling code from control queue handler\u0026quot;) a null pointer dereference bug can be triggered when guest sends an SCSI AN request.  In vhost_scsi_ctl_handle_vq(), `vc.target` is assigned with `\u0026amp;v_req.tmf.lun[1]` within a switch-case block and is then passed to vhost_scsi_get_req() which extracts `vc-\u0026gt;req` and `tpg`. However, for a `VIRTIO_SCSI_T_AN_*` request, tpg is not required, so `vc.target` is set to NULL in this branch. Later, in vhost_scsi_get_req(), `vc-\u0026gt;target` is dereferenced without being checked, leading to a null pointer dereference bug. This bug can be triggered from guest.  When this bug occurs, the vhost_worker process is killed while holding `vq-\u0026gt;mutex` and the corresponding tpg will remain occupied indefinitely.  Below is the KASAN report: Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007] CPU: 1 PID: 840 Comm: poc Not tainted 6.10.0+ #1 Hardware name: QEMU Ubuntu 24.04 PC (i440FX + PIIX, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014 RIP: 0010:vhost_scsi_get_req+0x165/0x3a0 Code: 00 fc ff df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 2b 02 00 00 48 b8 00 00 00 00 00 fc ff df 4d 8b 65 30 4c 89 e2 48 c1 ea 03 \u0026lt;0f\u0026gt; b6 04 02 4c 89 e2 83 e2 07 38 d0 7f 08 84 c0 0f 85 be 01 00 00 RSP: 0018:ffff888017affb50 EFLAGS: 00010246 RAX: dffffc0000000000 RBX: ffff88801b000000 RCX: 0000000000000000 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff888017affcb8 RBP: ffff888017affb80 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000 R13: ffff888017affc88 R14: ffff888017affd1c R15: ffff888017993000 FS:  000055556e076500(0000) GS:ffff88806b100000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00000000200027c0 CR3: 0000000010ed0004 CR4: 0000000000370ef0 Call Trace:  \u0026lt;TASK\u0026gt;  ? show_regs+0x86/0xa0  ? die_addr+0x4b/0xd0  ? exc_general_protection+0x163/0x260  ? asm_exc_general_protection+0x27/0x30  ? vhost_scsi_get_req+0x165/0x3a0  vhost_scsi_ctl_handle_vq+0x2a4/0xca0  ? __pfx_vhost_scsi_ctl_handle_vq+0x10/0x10  ? __switch_to+0x721/0xeb0  ? __schedule+0xda5/0x5710  ? __kasan_check_write+0x14/0x30  ? _raw_spin_lock+0x82/0xf0  vhost_scsi_ctl_handle_kick+0x52/0x90  vhost_run_work_list+0x134/0x1b0  vhost_task_fn+0x121/0x350 ...  \u0026lt;/TASK\u0026gt; ---[ end trace 0000000000000000 ]---  Let\u0026apos;s add a check in vhost_scsi_get_req.  [whitespace fixes](CVE-2024-49863)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: fix possible null-ptr-deref in ocfs2_set_buffer_uptodate  When doing cleanup, if flags without OCFS2_BH_READAHEAD, it may trigger NULL pointer dereference in the following ocfs2_set_buffer_uptodate() if bh is NULL.(CVE-2024-49877)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm: omapdrm: Add missing check for alloc_ordered_workqueue  As it may return NULL pointer and cause NULL pointer dereference. Add check for the return value of alloc_ordered_workqueue.(CVE-2024-49879)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: update orig_path in ext4_find_extent()  In ext4_find_extent(), if the path is not big enough, we free it and set *orig_path to NULL. But after reallocating and successfully initializing the path, we don\u0026apos;t update *orig_path, in which case the caller gets a valid path but a NULL ppath, and this may cause a NULL pointer dereference or a path memory leak. For example:  ext4_split_extent   path = *ppath = 2000   ext4_find_extent     if (depth \u0026gt; path[0].p_maxdepth)       kfree(path = 2000);       *orig_path = path = NULL;       path = kcalloc() = 3000   ext4_split_extent_at(*ppath = NULL)     path = *ppath;     ex = path[depth].p_ext;     // NULL pointer dereference!  ================================================================== BUG: kernel NULL pointer dereference, address: 0000000000000010 CPU: 6 UID: 0 PID: 576 Comm: fsstress Not tainted 6.11.0-rc2-dirty #847 RIP: 0010:ext4_split_extent_at+0x6d/0x560 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_split_extent.isra.0+0xcb/0x1b0  ext4_ext_convert_to_initialized+0x168/0x6c0  ext4_ext_handle_unwritten_extents+0x325/0x4d0  ext4_ext_map_blocks+0x520/0xdb0  ext4_map_blocks+0x2b0/0x690  ext4_iomap_begin+0x20e/0x2c0 [...] ==================================================================  Therefore, *orig_path is updated when the extent lookup succeeds, so that the caller can safely use path or *ppath.(CVE-2024-49881)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix double brelse() the buffer of the extents path  In ext4_ext_try_to_merge_up(), set path[1].p_bh to NULL after it has been released, otherwise it may be released twice. An example of what triggers this is as follows:    split2    map    split1 |--------|-------|--------|  ext4_ext_map_blocks  ext4_ext_handle_unwritten_extents   ext4_split_convert_extents    // path-\u0026gt;p_depth == 0    ext4_split_extent      // 1. do split1      ext4_split_extent_at        |ext4_ext_insert_extent        |  ext4_ext_create_new_leaf        |    ext4_ext_grow_indepth        |      le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)        |    ext4_find_extent        |      // return -ENOMEM        |// get error and try zeroout        |path = ext4_find_extent        |  path-\u0026gt;p_depth = 1        |ext4_ext_try_to_merge        |  ext4_ext_try_to_merge_up        |    path-\u0026gt;p_depth = 0        |    brelse(path[1].p_bh)  ---\u0026gt; not set to NULL here        |// zeroout success      // 2. update path      ext4_find_extent      // 3. do split2      ext4_split_extent_at        ext4_ext_insert_extent          ext4_ext_create_new_leaf            ext4_ext_grow_indepth              le16_add_cpu(\u0026amp;neh-\u0026gt;eh_depth, 1)            ext4_find_extent              path[0].p_bh = NULL;              path-\u0026gt;p_depth = 1              read_extent_tree_block  ---\u0026gt; return err              // path[1].p_bh is still the old value              ext4_free_ext_path                ext4_ext_drop_refs                  // path-\u0026gt;p_depth == 1                  brelse(path[1].p_bh)  ---\u0026gt; brelse a buffer twice  Finally got the following WARRNING when removing the buffer from lru:  ============================================ VFS: brelse: Trying to free free buffer WARNING: CPU: 2 PID: 72 at fs/buffer.c:1241 __brelse+0x58/0x90 CPU: 2 PID: 72 Comm: kworker/u19:1 Not tainted 6.9.0-dirty #716 RIP: 0010:__brelse+0x58/0x90 Call Trace:  \u0026lt;TASK\u0026gt;  __find_get_block+0x6e7/0x810  bdev_getblk+0x2b/0x480  __ext4_get_inode_loc+0x48a/0x1240  ext4_get_inode_loc+0xb2/0x150  ext4_reserve_inode_write+0xb7/0x230  __ext4_mark_inode_dirty+0x144/0x6a0  ext4_ext_insert_extent+0x9c8/0x3230  ext4_ext_map_blocks+0xf45/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ============================================(CVE-2024-49882)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: aovid use-after-free in ext4_ext_insert_extent()  As Ojaswin mentioned in Link, in ext4_ext_insert_extent(), if the path is reallocated in ext4_ext_create_new_leaf(), we\u0026apos;ll use the stale path and cause UAF. Below is a sample trace with dummy values:  ext4_ext_insert_extent   path = *ppath = 2000   ext4_ext_create_new_leaf(ppath)     ext4_find_extent(ppath)       path = *ppath = 2000       if (depth \u0026gt; path[0].p_maxdepth)             kfree(path = 2000);             *ppath = path = NULL;       path = kcalloc() = 3000       *ppath = 3000;       return path;   /* here path is still 2000, UAF! */   eh = path[depth].p_hdr  ================================================================== BUG: KASAN: slab-use-after-free in ext4_ext_insert_extent+0x26d4/0x3330 Read of size 8 at addr ffff8881027bf7d0 by task kworker/u36:1/179 CPU: 3 UID: 0 PID: 179 Comm: kworker/u6:1 Not tainted 6.11.0-rc2-dirty #866 Call Trace:  \u0026lt;TASK\u0026gt;  ext4_ext_insert_extent+0x26d4/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800 [...]  Allocated by task 179:  ext4_find_extent+0x81c/0x1f70  ext4_ext_map_blocks+0x146/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...]  Freed by task 179:  kfree+0xcb/0x240  ext4_find_extent+0x7c0/0x1f70  ext4_ext_insert_extent+0xa26/0x3330  ext4_ext_map_blocks+0xe22/0x2d40  ext4_map_blocks+0x71e/0x1700  ext4_do_writepages+0x1290/0x2800  ext4_writepages+0x26d/0x4e0  do_writepages+0x175/0x700 [...] ==================================================================  So use *ppath to update the path to avoid the above problem.(CVE-2024-49883)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: fix slab-use-after-free in ext4_split_extent_at()  We hit the following use-after-free:  ================================================================== BUG: KASAN: slab-use-after-free in ext4_split_extent_at+0xba8/0xcc0 Read of size 2 at addr ffff88810548ed08 by task kworker/u20:0/40 CPU: 0 PID: 40 Comm: kworker/u20:0 Not tainted 6.9.0-dirty #724 Call Trace:  \u0026lt;TASK\u0026gt;  kasan_report+0x93/0xc0  ext4_split_extent_at+0xba8/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Allocated by task 40:  __kmalloc_noprof+0x1ac/0x480  ext4_find_extent+0xf3b/0x1e70  ext4_ext_map_blocks+0x188/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...]  Freed by task 40:  kfree+0xf1/0x2b0  ext4_find_extent+0xa71/0x1e70  ext4_ext_insert_extent+0xa22/0x3260  ext4_split_extent_at+0x3ef/0xcc0  ext4_split_extent.isra.0+0x18f/0x500  ext4_split_convert_extents+0x275/0x750  ext4_ext_handle_unwritten_extents+0x73e/0x1580  ext4_ext_map_blocks+0xe20/0x2dc0  ext4_map_blocks+0x724/0x1700  ext4_do_writepages+0x12d6/0x2a70 [...] ==================================================================  The flow of issue triggering is as follows:  ext4_split_extent_at   path = *ppath   ext4_ext_insert_extent(ppath)     ext4_ext_create_new_leaf(ppath)       ext4_find_extent(orig_path)         path = *orig_path         read_extent_tree_block           // return -ENOMEM or -EIO         ext4_free_ext_path(path)           kfree(path)         *orig_path = NULL   a. If err is -ENOMEM:   ext4_ext_dirty(path + path-\u0026gt;p_depth)   // path use-after-free !!!   b. If err is -EIO and we have EXT_DEBUG defined:   ext4_ext_show_leaf(path)     eh = path[depth].p_hdr     // path also use-after-free !!!  So when trying to zeroout or fix the extent length, call ext4_find_extent() to update the path.  In addition we use *ppath directly as an ext4_ext_show_leaf() input to avoid possible use-after-free when EXT_DEBUG is defined, and to avoid unnecessary path updates.(CVE-2024-49884)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  platform/x86: ISST: Fix the KASAN report slab-out-of-bounds bug  Attaching SST PCI device to VM causes \u0026quot;BUG: KASAN: slab-out-of-bounds\u0026quot;. kasan report: [   19.411889] ================================================================== [   19.413702] BUG: KASAN: slab-out-of-bounds in _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.415634] Read of size 8 at addr ffff888829e65200 by task cpuhp/16/113 [   19.417368] [   19.418627] CPU: 16 PID: 113 Comm: cpuhp/16 Tainted: G            E      6.9.0 #10 [   19.420435] Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.20192059.B64.2207280713 07/28/2022 [   19.422687] Call Trace: [   19.424091]  \u0026lt;TASK\u0026gt; [   19.425448]  dump_stack_lvl+0x5d/0x80 [   19.426963]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.428694]  print_report+0x19d/0x52e [   19.430206]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10 [   19.431837]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.433539]  kasan_report+0xf0/0x170 [   19.435019]  ? _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.436709]  _isst_if_get_pci_dev+0x3d5/0x400 [isst_if_common] [   19.438379]  ? __pfx_sched_clock_cpu+0x10/0x10 [   19.439910]  isst_if_cpu_online+0x406/0x58f [isst_if_common] [   19.441573]  ? __pfx_isst_if_cpu_online+0x10/0x10 [isst_if_common] [   19.443263]  ? ttwu_queue_wakelist+0x2c1/0x360 [   19.444797]  cpuhp_invoke_callback+0x221/0xec0 [   19.446337]  cpuhp_thread_fun+0x21b/0x610 [   19.447814]  ? __pfx_cpuhp_thread_fun+0x10/0x10 [   19.449354]  smpboot_thread_fn+0x2e7/0x6e0 [   19.450859]  ? __pfx_smpboot_thread_fn+0x10/0x10 [   19.452405]  kthread+0x29c/0x350 [   19.453817]  ? __pfx_kthread+0x10/0x10 [   19.455253]  ret_from_fork+0x31/0x70 [   19.456685]  ? __pfx_kthread+0x10/0x10 [   19.458114]  ret_from_fork_asm+0x1a/0x30 [   19.459573]  \u0026lt;/TASK\u0026gt; [   19.460853] [   19.462055] Allocated by task 1198: [   19.463410]  kasan_save_stack+0x30/0x50 [   19.464788]  kasan_save_track+0x14/0x30 [   19.466139]  __kasan_kmalloc+0xaa/0xb0 [   19.467465]  __kmalloc+0x1cd/0x470 [   19.468748]  isst_if_cdev_register+0x1da/0x350 [isst_if_common] [   19.470233]  isst_if_mbox_init+0x108/0xff0 [isst_if_mbox_msr] [   19.471670]  do_one_initcall+0xa4/0x380 [   19.472903]  do_init_module+0x238/0x760 [   19.474105]  load_module+0x5239/0x6f00 [   19.475285]  init_module_from_file+0xd1/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.476506]  idempotent_init_module+0x23b/0x650 [   19.477725]  __x64_sys_finit_module+0xbe/0x130 [   19.478920]  do_syscall_64+0x82/0x160 [   19.480036]  entry_SYSCALL_64_after_hwframe+0x76/0x7e [   19.481292] [   19.482205] The buggy address belongs to the object at ffff888829e65000  which belongs to the cache kmalloc-512 of size 512 [   19.484818] The buggy address is located 0 bytes to the right of  allocated 512-byte region [ffff888829e65000, ffff888829e65200) [   19.487447] [   19.488328] The buggy address belongs to the physical page: [   19.489569] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888829e60c00 pfn:0x829e60 [   19.491140] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0 [   19.492466] anon flags: 0x57ffffc0000840(slab|head|node=1|zone=2|lastcpupid=0x1fffff) [   19.493914] page_type: 0xffffffff() [   19.494988] raw: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.496451] raw: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.497906] head: 0057ffffc0000840 ffff88810004cc80 0000000000000000 0000000000000001 [   19.499379] head: ffff888829e60c00 0000000080200018 00000001ffffffff 0000000000000000 [   19.500844] head: 0057ffffc0000003 ffffea0020a79801 ffffea0020a79848 00000000ffffffff [   19.502316] head: 0000000800000000 0000000000000000 00000000ffffffff 0000000000000000 [   19.503784] page dumped because: k ---truncated---(CVE-2024-49886)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: avoid use-after-free in ext4_ext_show_leaf()  In ext4_find_extent(), path may be freed by error or be reallocated, so using a previously saved *ppath may have been freed and thus may trigger use-after-free, as follows:  ext4_split_extent   path = *ppath;   ext4_split_extent_at(ppath)   path = ext4_find_extent(ppath)   ext4_split_extent_at(ppath)     // ext4_find_extent fails to free path     // but zeroout succeeds   ext4_ext_show_leaf(inode, path)     eh = path[depth].p_hdr     // path use-after-free !!!  Similar to ext4_split_extent_at(), we use *ppath directly as an input to ext4_ext_show_leaf(). Fix a spelling error by the way.  Same problem in ext4_ext_handle_unwritten_extents(). Since \u0026apos;path\u0026apos; is only used in ext4_ext_show_leaf(), remove \u0026apos;path\u0026apos; and use *ppath directly.  This issue is triggered only when EXT_DEBUG is defined and therefore does not affect functionality.(CVE-2024-49889)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add null check for top_pipe_to_program in commit_planes_for_stream  This commit addresses a null pointer dereference issue in the `commit_planes_for_stream` function at line 4140. The issue could occur when `top_pipe_to_program` is null.  The fix adds a check to ensure `top_pipe_to_program` is not null before accessing its stream_res. This prevents a null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4140 commit_planes_for_stream() error: we previously assumed \u0026apos;top_pipe_to_program\u0026apos; could be null (see line 3906)(CVE-2024-49913)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Add NULL check for clk_mgr and clk_mgr-\u0026gt;funcs in dcn30_init_hw  This commit addresses a potential null pointer dereference issue in the `dcn30_init_hw` function. The issue could occur when `dc-\u0026gt;clk_mgr` or `dc-\u0026gt;clk_mgr-\u0026gt;funcs` is null.  The fix adds a check to ensure `dc-\u0026gt;clk_mgr` and `dc-\u0026gt;clk_mgr-\u0026gt;funcs` is not null before accessing its functions. This prevents a potential null pointer dereference.  Reported by smatch: drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn30/dcn30_hwseq.c:789 dcn30_init_hw() error: we previously assumed \u0026apos;dc-\u0026gt;clk_mgr\u0026apos; could be null (see line 628)(CVE-2024-49917)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Check null pointers before using them  [WHAT \u0026amp; HOW] These pointers are null checked previously in the same function, indicating they might be null as reported by Coverity. As a result, they need to be checked when used again.  This fixes 3 FORWARD_NULL issue reported by Coverity.(CVE-2024-49922)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fbdev: pxafb: Fix possible use after free in pxafb_task()  In the pxafb_probe function, it calls the pxafb_init_fbinfo function, after which \u0026amp;fbi-\u0026gt;task is associated with pxafb_task. Moreover, within this pxafb_init_fbinfo function, the pxafb_blank function within the \u0026amp;pxafb_ops struct is capable of scheduling work.  If we remove the module which will call pxafb_remove to make cleanup, it will call unregister_framebuffer function which can call do_unregister_framebuffer to free fbi-\u0026gt;fb through put_fb_info(fb_info), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                                CPU1                                     | pxafb_task pxafb_remove                       | unregister_framebuffer(info)       | do_unregister_framebuffer(fb_info) | put_fb_info(fb_info)               | // free fbi-\u0026gt;fb                    | set_ctrlr_state(fbi, state)                                    | __pxafb_lcd_power(fbi, 0)                                    | fbi-\u0026gt;lcd_power(on, \u0026amp;fbi-\u0026gt;fb.var)                                    | //use fbi-\u0026gt;fb  Fix it by ensuring that the work is canceled before proceeding with the cleanup in pxafb_remove.  Note that only root user can remove the driver at runtime.(CVE-2024-49924)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  blk_iocost: fix more out of bound shifts  Recently running UBSAN caught few out of bound shifts in the ioc_forgive_debts() function:  UBSAN: shift-out-of-bounds in block/blk-iocost.c:2142:38 shift exponent 80 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;) ... UBSAN: shift-out-of-bounds in block/blk-iocost.c:2144:30 shift exponent 80 is too large for 64-bit type \u0026apos;u64\u0026apos; (aka \u0026apos;unsigned long long\u0026apos;) ... Call Trace: \u0026lt;IRQ\u0026gt; dump_stack_lvl+0xca/0x130 __ubsan_handle_shift_out_of_bounds+0x22c/0x280 ? __lock_acquire+0x6441/0x7c10 ioc_timer_fn+0x6cec/0x7750 ? blk_iocost_init+0x720/0x720 ? call_timer_fn+0x5d/0x470 call_timer_fn+0xfa/0x470 ? blk_iocost_init+0x720/0x720 __run_timer_base+0x519/0x700 ...  Actual impact of this issue was not identified but I propose to fix the undefined behaviour. The proposed fix to prevent those out of bound shifts consist of precalculating exponent before using it the shift operations by taking min value from the actual exponent and maximum possible number of bits.(CVE-2024-49933)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  fs/inode: Prevent dump_mapping() accessing invalid dentry.d_name.name  It\u0026apos;s observed that a crash occurs during hot-remove a memory device, in which user is accessing the hugetlb. See calltrace as following:  ------------[ cut here ]------------ WARNING: CPU: 1 PID: 14045 at arch/x86/mm/fault.c:1278 do_user_addr_fault+0x2a0/0x790 Modules linked in: kmem device_dax cxl_mem cxl_pmem cxl_port cxl_pci dax_hmem dax_pmem nd_pmem cxl_acpi nd_btt cxl_core crc32c_intel nvme virtiofs fuse nvme_core nfit libnvdimm dm_multipath scsi_dh_rdac scsi_dh_emc s mirror dm_region_hash dm_log dm_mod CPU: 1 PID: 14045 Comm: daxctl Not tainted 6.10.0-rc2-lizhijian+ #492 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014 RIP: 0010:do_user_addr_fault+0x2a0/0x790 Code: 48 8b 00 a8 04 0f 84 b5 fe ff ff e9 1c ff ff ff 4c 89 e9 4c 89 e2 be 01 00 00 00 bf 02 00 00 00 e8 b5 ef 24 00 e9 42 fe ff ff \u0026lt;0f\u0026gt; 0b 48 83 c4 08 4c 89 ea 48 89 ee 4c 89 e7 5b 5d 41 5c 41 5d 41 RSP: 0000:ffffc90000a575f0 EFLAGS: 00010046 RAX: ffff88800c303600 RBX: 0000000000000000 RCX: 0000000000000000 RDX: 0000000000001000 RSI: ffffffff82504162 RDI: ffffffff824b2c36 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000000 R12: ffffc90000a57658 R13: 0000000000001000 R14: ffff88800bc2e040 R15: 0000000000000000 FS:  00007f51cb57d880(0000) GS:ffff88807fd00000(0000) knlGS:0000000000000000 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000001000 CR3: 00000000072e2004 CR4: 00000000001706f0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace:  \u0026lt;TASK\u0026gt;  ? __warn+0x8d/0x190  ? do_user_addr_fault+0x2a0/0x790  ? report_bug+0x1c3/0x1d0  ? handle_bug+0x3c/0x70  ? exc_invalid_op+0x14/0x70  ? asm_exc_invalid_op+0x16/0x20  ? do_user_addr_fault+0x2a0/0x790  ? exc_page_fault+0x31/0x200  exc_page_fault+0x68/0x200 \u0026lt;...snip...\u0026gt; BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  ---[ end trace 0000000000000000 ]---  BUG: unable to handle page fault for address: 0000000000001000  #PF: supervisor read access in kernel mode  #PF: error_code(0x0000) - not-present page  PGD 800000000ad92067 P4D 800000000ad92067 PUD 7677067 PMD 0  Oops: Oops: 0000 [#1] PREEMPT SMP PTI  CPU: 1 PID: 14045 Comm: daxctl Kdump: loaded Tainted: G        W          6.10.0-rc2-lizhijian+ #492  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014  RIP: 0010:dentry_name+0x1f4/0x440 \u0026lt;...snip...\u0026gt; ? dentry_name+0x2fa/0x440 vsnprintf+0x1f3/0x4f0 vprintk_store+0x23a/0x540 vprintk_emit+0x6d/0x330 _printk+0x58/0x80 dump_mapping+0x10b/0x1a0 ? __pfx_free_object_rcu+0x10/0x10 __dump_page+0x26b/0x3e0 ? vprintk_emit+0xe0/0x330 ? _printk+0x58/0x80 ? dump_page+0x17/0x50 dump_page+0x17/0x50 do_migrate_range+0x2f7/0x7f0 ? do_migrate_range+0x42/0x7f0 ? offline_pages+0x2f4/0x8c0 offline_pages+0x60a/0x8c0 memory_subsys_offline+0x9f/0x1c0 ? lockdep_hardirqs_on+0x77/0x100 ? _raw_spin_unlock_irqrestore+0x38/0x60 device_offline+0xe3/0x110 state_store+0x6e/0xc0 kernfs_fop_write_iter+0x143/0x200 vfs_write+0x39f/0x560 ksys_write+0x65/0xf0 do_syscall_64+0x62/0x130  Previously, some sanity check have been done in dump_mapping() before the print facility parsing \u0026apos;%pd\u0026apos; though, it\u0026apos;s still possible to run into an invalid dentry.d_name.name.  Since dump_mapping() only needs to dump the filename only, retrieve it by itself in a safer way to prevent an unnecessary crash.  Note that either retrieving the filename with \u0026apos;%pd\u0026apos; or strncpy_from_kernel_nofault(), the filename could be unreliable.(CVE-2024-49934)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  net/xen-netback: prevent UAF in xenvif_flush_hash()  During the list_for_each_entry_rcu iteration call of xenvif_flush_hash, kfree_rcu does not exist inside the rcu read critical section, so if kfree_rcu is called when the rcu grace period ends during the iteration, UAF occurs when accessing head-\u0026gt;next after the entry becomes free.  Therefore, to solve this, you need to change it to list_for_each_entry_safe.(CVE-2024-49936)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  l2tp: prevent possible tunnel refcount underflow  When a session is created, it sets a backpointer to its tunnel. When the session refcount drops to 0, l2tp_session_free drops the tunnel refcount if session-\u0026gt;tunnel is non-NULL. However, session-\u0026gt;tunnel is set in l2tp_session_create, before the tunnel refcount is incremented by l2tp_session_register, which leaves a small window where session-\u0026gt;tunnel is non-NULL when the tunnel refcount hasn\u0026apos;t been bumped.  Moving the assignment to l2tp_session_register is trivial but l2tp_session_create calls l2tp_session_set_header_len which uses session-\u0026gt;tunnel to get the tunnel\u0026apos;s encap. Add an encap arg to l2tp_session_set_header_len to avoid using session-\u0026gt;tunnel.  If l2tpv3 sessions have colliding IDs, it is possible for l2tp_v3_session_get to race with l2tp_session_register and fetch a session which doesn\u0026apos;t yet have session-\u0026gt;tunnel set. Add a check for this case.(CVE-2024-49940)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  Bluetooth: L2CAP: Fix uaf in l2cap_connect  [Syzbot reported] BUG: KASAN: slab-use-after-free in l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949 Read of size 8 at addr ffff8880241e9800 by task kworker/u9:0/54  CPU: 0 UID: 0 PID: 54 Comm: kworker/u9:0 Not tainted 6.11.0-rc6-syzkaller-00268-g788220eee30d #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024 Workqueue: hci2 hci_rx_work Call Trace:  \u0026lt;TASK\u0026gt;  __dump_stack lib/dump_stack.c:93 [inline]  dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:119  print_address_description mm/kasan/report.c:377 [inline]  print_report+0xc3/0x620 mm/kasan/report.c:488  kasan_report+0xd9/0x110 mm/kasan/report.c:601  l2cap_connect.constprop.0+0x10d8/0x1270 net/bluetooth/l2cap_core.c:3949  l2cap_connect_req net/bluetooth/l2cap_core.c:4080 [inline]  l2cap_bredr_sig_cmd net/bluetooth/l2cap_core.c:4772 [inline]  l2cap_sig_channel net/bluetooth/l2cap_core.c:5543 [inline]  l2cap_recv_frame+0xf0b/0x8eb0 net/bluetooth/l2cap_core.c:6825  l2cap_recv_acldata+0x9b4/0xb70 net/bluetooth/l2cap_core.c:7514  hci_acldata_packet net/bluetooth/hci_core.c:3791 [inline]  hci_rx_work+0xaab/0x1610 net/bluetooth/hci_core.c:4028  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 ...  Freed by task 5245:  kasan_save_stack+0x33/0x60 mm/kasan/common.c:47  kasan_save_track+0x14/0x30 mm/kasan/common.c:68  kasan_save_free_info+0x3b/0x60 mm/kasan/generic.c:579  poison_slab_object+0xf7/0x160 mm/kasan/common.c:240  __kasan_slab_free+0x32/0x50 mm/kasan/common.c:256  kasan_slab_free include/linux/kasan.h:184 [inline]  slab_free_hook mm/slub.c:2256 [inline]  slab_free mm/slub.c:4477 [inline]  kfree+0x12a/0x3b0 mm/slub.c:4598  l2cap_conn_free net/bluetooth/l2cap_core.c:1810 [inline]  kref_put include/linux/kref.h:65 [inline]  l2cap_conn_put net/bluetooth/l2cap_core.c:1822 [inline]  l2cap_conn_del+0x59d/0x730 net/bluetooth/l2cap_core.c:1802  l2cap_connect_cfm+0x9e6/0xf80 net/bluetooth/l2cap_core.c:7241  hci_connect_cfm include/net/bluetooth/hci_core.h:1960 [inline]  hci_conn_failed+0x1c3/0x370 net/bluetooth/hci_conn.c:1265  hci_abort_conn_sync+0x75a/0xb50 net/bluetooth/hci_sync.c:5583  abort_conn_sync+0x197/0x360 net/bluetooth/hci_conn.c:2917  hci_cmd_sync_work+0x1a4/0x410 net/bluetooth/hci_sync.c:328  process_one_work+0x9c5/0x1b40 kernel/workqueue.c:3231  process_scheduled_works kernel/workqueue.c:3312 [inline]  worker_thread+0x6c8/0xed0 kernel/workqueue.c:3389  kthread+0x2c1/0x3a0 kernel/kthread.c:389  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244(CVE-2024-49950)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  static_call: Replace pointless WARN_ON() in static_call_module_notify()  static_call_module_notify() triggers a WARN_ON(), when memory allocation fails in __static_call_add_module().  That\u0026apos;s not really justified, because the failure case must be correctly handled by the well known call chain and the error code is passed through to the initiating userspace application.  A memory allocation fail is not a fatal problem, but the WARN_ON() takes the machine out when panic_on_warn is set.  Replace it with a pr_warn().(CVE-2024-49954)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ACPI: battery: Fix possible crash when unregistering a battery hook  When a battery hook returns an error when adding a new battery, then the battery hook is automatically unregistered. However the battery hook provider cannot know that, so it will later call battery_hook_unregister() on the already unregistered battery hook, resulting in a crash.  Fix this by using the list head to mark already unregistered battery hooks as already being unregistered so that they can be ignored by battery_hook_unregister().(CVE-2024-49955)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: reserve space for inline xattr before attaching reflink tree  One of our customers reported a crash and a corrupted ocfs2 filesystem.  The crash was due to the detection of corruption.  Upon troubleshooting, the fsck -fn output showed the below corruption  [EXTENT_LIST_FREE] Extent list in owner 33080590 claims 230 as the next free chain record, but fsck believes the largest valid value is 227.  Clamp the next record value? n  The stat output from the debugfs.ocfs2 showed the following corruption where the \u0026quot;Next Free Rec:\u0026quot; had overshot the \u0026quot;Count:\u0026quot; in the root metadata block.          Inode: 33080590   Mode: 0640   Generation: 2619713622 (0x9c25a856)         FS Generation: 904309833 (0x35e6ac49)         CRC32: 00000000   ECC: 0000         Type: Regular   Attr: 0x0   Flags: Valid         Dynamic Features: (0x16) HasXattr InlineXattr Refcounted         Extended Attributes Block: 0  Extended Attributes Inline Size: 256         User: 0 (root)   Group: 0 (root)   Size: 281320357888         Links: 1   Clusters: 141738         ctime: 0x66911b56 0x316edcb8 -- Fri Jul 12 06:02:30.829349048 2024         atime: 0x66911d6b 0x7f7a28d -- Fri Jul 12 06:11:23.133669517 2024         mtime: 0x66911b56 0x12ed75d7 -- Fri Jul 12 06:02:30.317552087 2024         dtime: 0x0 -- Wed Dec 31 17:00:00 1969         Refcount Block: 2777346         Last Extblk: 2886943   Orphan Slot: 0         Sub Alloc Slot: 0   Sub Alloc Bit: 14         Tree Depth: 1   Count: 227   Next Free Rec: 230         ## Offset        Clusters       Block#         0  0             2310           2776351         1  2310          2139           2777375         2  4449          1221           2778399         3  5670          731            2779423         4  6401          566            2780447         .......          ....           .......         .......          ....           .......  The issue was in the reflink workfow while reserving space for inline xattr.  The problematic function is ocfs2_reflink_xattr_inline().  By the time this function is called the reflink tree is already recreated at the destination inode from the source inode.  At this point, this function reserves space for inline xattrs at the destination inode without even checking if there is space at the root metadata block.  It simply reduces the l_count from 243 to 227 thereby making space of 256 bytes for inline xattr whereas the inode already has extents beyond this index (in this case up to 230), thereby causing corruption.  The fix for this is to reserve space for inline metadata at the destination inode before the reflink tree gets recreated. The customer has verified the fix.(CVE-2024-49958)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ocfs2: remove unreasonable unlock in ocfs2_read_blocks  Patch series \u0026quot;Misc fixes for ocfs2_read_blocks\u0026quot;, v5.  This series contains 2 fixes for ocfs2_read_blocks().  The first patch fix the issue reported by syzbot, which detects bad unlock balance in ocfs2_read_blocks().  The second patch fixes an issue reported by Heming Zhao when reviewing above fix.   This patch (of 2):  There was a lock release before exiting, so remove the unreasonable unlock.(CVE-2024-49965)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  r8169: add tally counter fields added with RTL8125  RTL8125 added fields to the tally counter, what may result in the chip dma\u0026apos;ing these new fields to unallocated memory. Therefore make sure that the allocated memory area is big enough to hold all of the tally counter values, even if we use only parts of it.(CVE-2024-49973)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  uprobes: fix kernel info leak via \u0026quot;[uprobes]\u0026quot; vma  xol_add_vma() maps the uninitialized page allocated by __create_xol_area() into userspace. On some architectures (x86) this memory is readable even without VM_READ, VM_EXEC results in the same pgprot_t as VM_EXEC|VM_READ, although this doesn\u0026apos;t really matter, debugger can read this memory anyway.(CVE-2024-49975)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  gso: fix udp gso fraglist segmentation after pull from frag_list  Detect gso fraglist skbs with corrupted geometry (see below) and pass these to skb_segment instead of skb_segment_list, as the first can segment them correctly.  Valid SKB_GSO_FRAGLIST skbs - consist of two or more segments - the head_skb holds the protocol headers plus first gso_size - one or more frag_list skbs hold exactly one segment - all but the last must be gso_size  Optional datapath hooks such as NAT and BPF (bpf_skb_pull_data) can modify these skbs, breaking these invariants.  In extreme cases they pull all data into skb linear. For UDP, this causes a NULL ptr deref in __udpv4_gso_segment_list_csum at udp_hdr(seg-\u0026gt;next)-\u0026gt;dest.  Detect invalid geometry due to pull, by checking head_skb size. Don\u0026apos;t just drop, as this may blackhole a destination. Convert to be able to pass to regular skb_segment.(CVE-2024-49978)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  media: venus: fix use after free bug in venus_remove due to race condition  in venus_probe, core-\u0026gt;work is bound with venus_sys_error_handler, which is used to handle error. The code use core-\u0026gt;sys_err_done to make sync work. The core-\u0026gt;work is started in venus_event_notify.  If we call venus_remove, there might be an unfished work. The possible sequence is as follows:  CPU0                  CPU1                       |venus_sys_error_handler venus_remove         | hfi_destroy     | venus_hfi_destroy  | kfree(hdev);      |                      |hfi_reinit       |venus_hfi_queues_reinit                      |//use hdev  Fix it by canceling the work in venus_remove.(CVE-2024-49981)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/stm: Avoid use-after-free issues with crtc and plane  ltdc_load() calls functions drm_crtc_init_with_planes(), drm_universal_plane_init() and drm_encoder_init(). These functions should not be called with parameters allocated with devm_kzalloc() to avoid use-after-free issues [1].  Use allocations managed by the DRM framework.  Found by Linux Verification Center (linuxtesting.org).  [1] https://lore.kernel.org/lkml/u366i76e3qhh3ra5oxrtngjtm2u5lterkekcz6y2jkndhuxzli@diujon4h7qwb/(CVE-2024-49992)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tipc: guard against string buffer overrun  Smatch reports that copying media_name and if_name to name_parts may overwrite the destination.   .../bearer.c:166 bearer_name_validate() error: strcpy() \u0026apos;media_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;media_name\u0026apos; (32 vs 16)  .../bearer.c:167 bearer_name_validate() error: strcpy() \u0026apos;if_name\u0026apos; too large for \u0026apos;name_parts-\u0026gt;if_name\u0026apos; (1010102 vs 16)  This does seem to be the case so guard against this possibility by using strscpy() and failing if truncation occurs.  Introduced by commit b97bf3fd8f6a (\u0026quot;[TIPC] Initial merge\u0026quot;)  Compile tested only.(CVE-2024-49995)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  cifs: Fix buffer overflow when parsing NFS reparse points  ReparseDataLength is sum of the InodeType size and DataBuffer size. So to get DataBuffer size it is needed to subtract InodeType\u0026apos;s size from ReparseDataLength.  Function cifs_strndup_from_utf16() is currentlly accessing buf-\u0026gt;DataBuffer at position after the end of the buffer because it does not subtract InodeType size from the length. Fix this problem and correctly subtract variable len.  Member InodeType is present only when reparse buffer is large enough. Check for ReparseDataLength before accessing InodeType to prevent another invalid memory access.  Major and minor rdev values are present also only when reparse buffer is large enough. Check for reparse buffer size before calling reparse_mkdev().(CVE-2024-49996)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  wifi: mwifiex: Fix memcpy() field-spanning write warning in mwifiex_cmd_802_11_scan_ext()  Replace one-element array with a flexible-array member in `struct host_cmd_ds_802_11_scan_ext`.  With this, fix the following warning:  elo 16 17:51:58 surfacebook kernel: ------------[ cut here ]------------ elo 16 17:51:58 surfacebook kernel: memcpy: detected field-spanning write (size 243) of single field \u0026quot;ext_scan-\u0026gt;tlv_buffer\u0026quot; at drivers/net/wireless/marvell/mwifiex/scan.c:2239 (size 1) elo 16 17:51:58 surfacebook kernel: WARNING: CPU: 0 PID: 498 at drivers/net/wireless/marvell/mwifiex/scan.c:2239 mwifiex_cmd_802_11_scan_ext+0x83/0x90 [mwifiex](CVE-2024-50008)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ext4: dax: fix overflowing extents beyond inode size when partially writing  The dax_iomap_rw() does two things in each iteration: map written blocks and copy user data to blocks. If the process is killed by user(See signal handling in dax_iomap_iter()), the copied data will be returned and added on inode size, which means that the length of written extents may exceed the inode size, then fsck will fail. An example is given as:  dd if=/dev/urandom of=file bs=4M count=1  dax_iomap_rw   iomap_iter // round 1    ext4_iomap_begin     ext4_iomap_alloc // allocate 0~2M extents(written flag)   dax_iomap_iter // copy 2M data   iomap_iter // round 2    iomap_iter_advance     iter-\u0026gt;pos += iter-\u0026gt;processed // iter-\u0026gt;pos = 2M    ext4_iomap_begin     ext4_iomap_alloc // allocate 2~4M extents(written flag)   dax_iomap_iter    fatal_signal_pending   done = iter-\u0026gt;pos - iocb-\u0026gt;ki_pos // done = 2M  ext4_handle_inode_extension   ext4_update_inode_size // inode size = 2M  fsck reports: Inode 13, i_size is 2097152, should be 4194304.  Fix?  Fix the problem by truncating extents if the written length is smaller than expected.(CVE-2024-50015)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  drm/amd/display: Avoid overflow assignment in link_dp_cts  sampling_rate is an uint8_t but is assigned an unsigned int, and thus it can overflow. As a result, sampling_rate is changed to uint32_t.  Similarly, LINK_QUAL_PATTERN_SET has a size of 2 bits, and it should only be assigned to a value less or equal than 4.  This fixes 2 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-50016)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  thermal: core: Reference count the zone in thermal_zone_get_by_id()  There are places in the thermal netlink code where nothing prevents the thermal zone object from going away while being accessed after it has been returned by thermal_zone_get_by_id().  To address this, make thermal_zone_get_by_id() get a reference on the thermal zone device object to be returned with the help of get_device(), under thermal_list_lock, and adjust all of its callers to this change with the help of the cleanup.h infrastructure.(CVE-2024-50028)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  slip: make slhc_remember() more robust against malicious packets  syzbot found that slhc_remember() was missing checks against malicious packets [1].  slhc_remember() only checked the size of the packet was at least 20, which is not good enough.  We need to make sure the packet includes the IPv4 and TCP header that are supposed to be carried.  Add iph and th pointers to make the code more readable.  [1]  BUG: KMSAN: uninit-value in slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   slhc_remember+0x2e8/0x7b0 drivers/net/slip/slhc.c:666   ppp_receive_nonmp_frame+0xe45/0x35e0 drivers/net/ppp/ppp_generic.c:2455   ppp_receive_frame drivers/net/ppp/ppp_generic.c:2372 [inline]   ppp_do_recv+0x65f/0x40d0 drivers/net/ppp/ppp_generic.c:2212   ppp_input+0x7dc/0xe60 drivers/net/ppp/ppp_generic.c:2327   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4091 [inline]   slab_alloc_node mm/slub.c:4134 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4186   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 0 UID: 0 PID: 5460 Comm: syz.2.33 Not tainted 6.12.0-rc2-syzkaller-00006-g87d6aab2389e #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50033)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ppp: fix ppp_async_encode() illegal access  syzbot reported an issue in ppp_async_encode() [1]  In this case, pppoe_sendmsg() is called with a zero size. Then ppp_async_encode() is called with an empty skb.  BUG: KMSAN: uninit-value in ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]  BUG: KMSAN: uninit-value in ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_encode drivers/net/ppp/ppp_async.c:545 [inline]   ppp_async_push+0xb4f/0x2660 drivers/net/ppp/ppp_async.c:675   ppp_async_send+0x130/0x1b0 drivers/net/ppp/ppp_async.c:634   ppp_channel_bridge_input drivers/net/ppp/ppp_generic.c:2280 [inline]   ppp_input+0x1f1/0xe60 drivers/net/ppp/ppp_generic.c:2304   pppoe_rcv_core+0x1d3/0x720 drivers/net/ppp/pppoe.c:379   sk_backlog_rcv+0x13b/0x420 include/net/sock.h:1113   __release_sock+0x1da/0x330 net/core/sock.c:3072   release_sock+0x6b/0x250 net/core/sock.c:3626   pppoe_sendmsg+0x2b8/0xb90 drivers/net/ppp/pppoe.c:903   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  Uninit was created at:   slab_post_alloc_hook mm/slub.c:4092 [inline]   slab_alloc_node mm/slub.c:4135 [inline]   kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4187   kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:587   __alloc_skb+0x363/0x7b0 net/core/skbuff.c:678   alloc_skb include/linux/skbuff.h:1322 [inline]   sock_wmalloc+0xfe/0x1a0 net/core/sock.c:2732   pppoe_sendmsg+0x3a7/0xb90 drivers/net/ppp/pppoe.c:867   sock_sendmsg_nosec net/socket.c:729 [inline]   __sock_sendmsg+0x30f/0x380 net/socket.c:744   ____sys_sendmsg+0x903/0xb60 net/socket.c:2602   ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2656   __sys_sendmmsg+0x3c1/0x960 net/socket.c:2742   __do_sys_sendmmsg net/socket.c:2771 [inline]   __se_sys_sendmmsg net/socket.c:2768 [inline]   __x64_sys_sendmmsg+0xbc/0x120 net/socket.c:2768   x64_sys_call+0xb6e/0x3ba0 arch/x86/include/generated/asm/syscalls_64.h:308   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83  entry_SYSCALL_64_after_hwframe+0x77/0x7f  CPU: 1 UID: 0 PID: 5411 Comm: syz.1.14 Not tainted 6.12.0-rc1-syzkaller-00165-g360c1f1f24c6 #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024(CVE-2024-50035)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  NFSv4: Prevent NULL-pointer dereference in nfs42_complete_copies()  On the node of an NFS client, some files saved in the mountpoint of the NFS server were copied to another location of the same NFS server. Accidentally, the nfs42_complete_copies() got a NULL-pointer dereference crash with the following syslog:  [232064.838881] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232064.839360] NFSv4: state recovery failed for open file nfs/pvc-12b5200d-cd0f-46a3-b9f0-af8f4fe0ef64.qcow2, error = -116 [232066.588183] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000058 [232066.588586] Mem abort info: [232066.588701]   ESR = 0x0000000096000007 [232066.588862]   EC = 0x25: DABT (current EL), IL = 32 bits [232066.589084]   SET = 0, FnV = 0 [232066.589216]   EA = 0, S1PTW = 0 [232066.589340]   FSC = 0x07: level 3 translation fault [232066.589559] Data abort info: [232066.589683]   ISV = 0, ISS = 0x00000007 [232066.589842]   CM = 0, WnR = 0 [232066.589967] user pgtable: 64k pages, 48-bit VAs, pgdp=00002000956ff400 [232066.590231] [0000000000000058] pgd=08001100ae100003, p4d=08001100ae100003, pud=08001100ae100003, pmd=08001100b3c00003, pte=0000000000000000 [232066.590757] Internal error: Oops: 96000007 [#1] SMP [232066.590958] Modules linked in: rpcsec_gss_krb5 auth_rpcgss nfsv4 dns_resolver nfs lockd grace fscache netfs ocfs2_dlmfs ocfs2_stack_o2cb ocfs2_dlm vhost_net vhost vhost_iotlb tap tun ipt_rpfilter xt_multiport ip_set_hash_ip ip_set_hash_net xfrm_interface xfrm6_tunnel tunnel4 tunnel6 esp4 ah4 wireguard libcurve25519_generic veth xt_addrtype xt_set nf_conntrack_netlink ip_set_hash_ipportnet ip_set_hash_ipportip ip_set_bitmap_port ip_set_hash_ipport dummy ip_set ip_vs_sh ip_vs_wrr ip_vs_rr ip_vs iptable_filter sch_ingress nfnetlink_cttimeout vport_gre ip_gre ip_tunnel gre vport_geneve geneve vport_vxlan vxlan ip6_udp_tunnel udp_tunnel openvswitch nf_conncount dm_round_robin dm_service_time dm_multipath xt_nat xt_MASQUERADE nft_chain_nat nf_nat xt_mark xt_conntrack xt_comment nft_compat nft_counter nf_tables nfnetlink ocfs2 ocfs2_nodemanager ocfs2_stackglue iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi ipmi_ssif nbd overlay 8021q garp mrp bonding tls rfkill sunrpc ext4 mbcache jbd2 [232066.591052]  vfat fat cas_cache cas_disk ses enclosure scsi_transport_sas sg acpi_ipmi ipmi_si ipmi_devintf ipmi_msghandler ip_tables vfio_pci vfio_pci_core vfio_virqfd vfio_iommu_type1 vfio dm_mirror dm_region_hash dm_log dm_mod nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 br_netfilter bridge stp llc fuse xfs libcrc32c ast drm_vram_helper qla2xxx drm_kms_helper syscopyarea crct10dif_ce sysfillrect ghash_ce sysimgblt sha2_ce fb_sys_fops cec sha256_arm64 sha1_ce drm_ttm_helper ttm nvme_fc igb sbsa_gwdt nvme_fabrics drm nvme_core i2c_algo_bit i40e scsi_transport_fc megaraid_sas aes_neon_bs [232066.596953] CPU: 6 PID: 4124696 Comm: 10.253.166.125- Kdump: loaded Not tainted 5.15.131-9.cl9_ocfs2.aarch64 #1 [232066.597356] Hardware name: Great Wall .\\x93\\x8e...RF6260 V5/GWMSSE2GL1T, BIOS T656FBE_V3.0.18 2024-01-06 [232066.597721] pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [232066.598034] pc : nfs4_reclaim_open_state+0x220/0x800 [nfsv4] [232066.598327] lr : nfs4_reclaim_open_state+0x12c/0x800 [nfsv4] [232066.598595] sp : ffff8000f568fc70 [232066.598731] x29: ffff8000f568fc70 x28: 0000000000001000 x27: ffff21003db33000 [232066.599030] x26: ffff800005521ae0 x25: ffff0100f98fa3f0 x24: 0000000000000001 [232066.599319] x23: ffff800009920008 x22: ffff21003db33040 x21: ffff21003db33050 [232066.599628] x20: ffff410172fe9e40 x19: ffff410172fe9e00 x18: 0000000000000000 [232066.599914] x17: 0000000000000000 x16: 0000000000000004 x15: 0000000000000000 [232066.600195] x14: 0000000000000000 x13: ffff800008e685a8 x12: 00000000eac0c6e6 [232066.600498] x11: 00000000000000 ---truncated---(CVE-2024-50046)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  smb: client: fix UAF in async decryption  Doing an async decryption (large read) crashes with a slab-use-after-free way down in the crypto API.  Reproducer:     # mount.cifs -o ...,seal,esize=1 //srv/share /mnt     # dd if=/mnt/largefile of=/dev/null     ...     [  194.196391] ==================================================================     [  194.196844] BUG: KASAN: slab-use-after-free in gf128mul_4k_lle+0xc1/0x110     [  194.197269] Read of size 8 at addr ffff888112bd0448 by task kworker/u77:2/899     [  194.197707]     [  194.197818] CPU: 12 UID: 0 PID: 899 Comm: kworker/u77:2 Not tainted 6.11.0-lku-00028-gfca3ca14a17a-dirty #43     [  194.198400] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.2-3-gd478f380-prebuilt.qemu.org 04/01/2014     [  194.199046] Workqueue: smb3decryptd smb2_decrypt_offload [cifs]     [  194.200032] Call Trace:     [  194.200191]  \u0026lt;TASK\u0026gt;     [  194.200327]  dump_stack_lvl+0x4e/0x70     [  194.200558]  ? gf128mul_4k_lle+0xc1/0x110     [  194.200809]  print_report+0x174/0x505     [  194.201040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10     [  194.201352]  ? srso_return_thunk+0x5/0x5f     [  194.201604]  ? __virt_addr_valid+0xdf/0x1c0     [  194.201868]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202128]  kasan_report+0xc8/0x150     [  194.202361]  ? gf128mul_4k_lle+0xc1/0x110     [  194.202616]  gf128mul_4k_lle+0xc1/0x110     [  194.202863]  ghash_update+0x184/0x210     [  194.203103]  shash_ahash_update+0x184/0x2a0     [  194.203377]  ? __pfx_shash_ahash_update+0x10/0x10     [  194.203651]  ? srso_return_thunk+0x5/0x5f     [  194.203877]  ? crypto_gcm_init_common+0x1ba/0x340     [  194.204142]  gcm_hash_assoc_remain_continue+0x10a/0x140     [  194.204434]  crypt_message+0xec1/0x10a0 [cifs]     [  194.206489]  ? __pfx_crypt_message+0x10/0x10 [cifs]     [  194.208507]  ? srso_return_thunk+0x5/0x5f     [  194.209205]  ? srso_return_thunk+0x5/0x5f     [  194.209925]  ? srso_return_thunk+0x5/0x5f     [  194.210443]  ? srso_return_thunk+0x5/0x5f     [  194.211037]  decrypt_raw_data+0x15f/0x250 [cifs]     [  194.212906]  ? __pfx_decrypt_raw_data+0x10/0x10 [cifs]     [  194.214670]  ? srso_return_thunk+0x5/0x5f     [  194.215193]  smb2_decrypt_offload+0x12a/0x6c0 [cifs]  This is because TFM is being used in parallel.  Fix this by allocating a new AEAD TFM for async decryption, but keep the existing one for synchronous READ cases (similar to what is done in smb3_calc_signature()).  Also remove the calls to aead_request_set_callback() and crypto_wait_req() since it\u0026apos;s always going to be a synchronous operation.(CVE-2024-50047)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  serial: protect uart_port_dtr_rts() in uart_shutdown() too  Commit af224ca2df29 (serial: core: Prevent unsafe uart port access, part 3) added few uport == NULL checks. It added one to uart_shutdown(), so the commit assumes, uport can be NULL in there. But right after that protection, there is an unprotected \u0026quot;uart_port_dtr_rts(uport, false);\u0026quot; call. That is invoked only if HUPCL is set, so I assume that is the reason why we do not see lots of these reports.  Or it cannot be NULL at this point at all for some reason :P.  Until the above is investigated, stay on the safe side and move this dereference to the if too.  I got this inconsistency from Coverity under CID 1585130. Thanks.(CVE-2024-50058)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  ntb: ntb_hw_switchtec: Fix use after free vulnerability in switchtec_ntb_remove due to race condition  In the switchtec_ntb_add function, it can call switchtec_ntb_init_sndev function, then \u0026amp;sndev-\u0026gt;check_link_status_work is bound with check_link_status_work. switchtec_ntb_link_notification may be called to start the work.  If we remove the module which will call switchtec_ntb_remove to make cleanup, it will free sndev through kfree(sndev), while the work mentioned above will be used. The sequence of operations that may lead to a UAF bug is as follows:  CPU0                                 CPU1                          | check_link_status_work switchtec_ntb_remove    | kfree(sndev);           |                         | if (sndev-\u0026gt;link_force_down)                         | // use sndev  Fix it by ensuring that the work is canceled before proceeding with the cleanup in switchtec_ntb_remove.(CVE-2024-50059)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  io_uring: check if we need to reschedule during overflow flush  In terms of normal application usage, this list will always be empty. And if an application does overflow a bit, it\u0026apos;ll have a few entries. However, nothing obviously prevents syzbot from running a test case that generates a ton of overflow entries, and then flushing them can take quite a while.  Check for needing to reschedule while flushing, and drop our locks and do so if necessary. There\u0026apos;s no state to maintain here as overflows always prune from head-of-list, hence it\u0026apos;s fine to drop and reacquire the locks at the end of the loop.(CVE-2024-50060)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  bpf: Prevent tail call between progs attached to different hooks  bpf progs can be attached to kernel functions, and the attached functions can take different parameters or return different return values. If prog attached to one kernel function tail calls prog attached to another kernel function, the ctx access or return value verification could be bypassed.  For example, if prog1 is attached to func1 which takes only 1 parameter and prog2 is attached to func2 which takes two parameters. Since verifier assumes the bpf ctx passed to prog2 is constructed based on func2\u0026apos;s prototype, verifier allows prog2 to access the second parameter from the bpf ctx passed to it. The problem is that verifier does not prevent prog1 from passing its bpf ctx to prog2 via tail call. In this case, the bpf ctx passed to prog2 is constructed from func1 instead of func2, that is, the assumption for ctx access verification is bypassed.  Another example, if BPF LSM prog1 is attached to hook file_alloc_security, and BPF LSM prog2 is attached to hook bpf_lsm_audit_rule_known. Verifier knows the return value rules for these two hooks, e.g. it is legal for bpf_lsm_audit_rule_known to return positive number 1, and it is illegal for file_alloc_security to return positive number. So verifier allows prog2 to return positive number 1, but does not allow prog1 to return positive number. The problem is that verifier does not prevent prog1 from calling prog2 via tail call. In this case, prog2\u0026apos;s return value 1 will be used as the return value for prog1\u0026apos;s hook file_alloc_security. That is, the return value rule is bypassed.  This patch adds restriction for tail call to prevent such bypasses.(CVE-2024-50063)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  uprobe: avoid out-of-bounds memory access of fetching args  Uprobe needs to fetch args into a percpu buffer, and then copy to ring buffer to avoid non-atomic context problem.  Sometimes user-space strings, arrays can be very large, but the size of percpu buffer is only page size. And store_trace_args() won\u0026apos;t check whether these data exceeds a single page or not, caused out-of-bounds memory access.  It could be reproduced by following steps: 1. build kernel with CONFIG_KASAN enabled 2. save follow program as test.c  ``` \\#include \u0026lt;stdio.h\u0026gt; \\#include \u0026lt;stdlib.h\u0026gt; \\#include \u0026lt;string.h\u0026gt;  // If string length large than MAX_STRING_SIZE, the fetch_store_strlen() // will return 0, cause __get_data_size() return shorter size, and // store_trace_args() will not trigger out-of-bounds access. // So make string length less than 4096. \\#define STRLEN 4093  void generate_string(char *str, int n) {     int i;     for (i = 0; i \u0026lt; n; ++i)     {         char c = i % 26 + \u0026apos;a\u0026apos;;         str[i] = c;     }     str[n-1] = \u0026apos;\\0\u0026apos;; }  void print_string(char *str) {     printf(\u0026quot;%s\\n\u0026quot;, str); }  int main() {     char tmp[STRLEN];      generate_string(tmp, STRLEN);     print_string(tmp);      return 0; } ``` 3. compile program `gcc -o test test.c`  4. get the offset of `print_string()` ``` objdump -t test | grep -w print_string 0000000000401199 g     F .text  000000000000001b              print_string ```  5. configure uprobe with offset 0x1199 ``` off=0x1199  cd /sys/kernel/debug/tracing/ echo \u0026quot;p /root/test:${off} arg1=+0(%di):ustring arg2=\\$comm arg3=+0(%di):ustring\u0026quot;  \u0026gt; uprobe_events echo 1 \u0026gt; events/uprobes/enable echo 1 \u0026gt; tracing_on ```  6. run `test`, and kasan will report error. ================================================================== BUG: KASAN: use-after-free in strncpy_from_user+0x1d6/0x1f0 Write of size 8 at addr ffff88812311c004 by task test/499CPU: 0 UID: 0 PID: 499 Comm: test Not tainted 6.12.0-rc3+ #18 Hardware name: Red Hat KVM, BIOS 1.16.0-4.al8 04/01/2014 Call Trace:  \u0026lt;TASK\u0026gt;  dump_stack_lvl+0x55/0x70  print_address_description.constprop.0+0x27/0x310  kasan_report+0x10f/0x120  ? strncpy_from_user+0x1d6/0x1f0  strncpy_from_user+0x1d6/0x1f0  ? rmqueue.constprop.0+0x70d/0x2ad0  process_fetch_insn+0xb26/0x1470  ? __pfx_process_fetch_insn+0x10/0x10  ? _raw_spin_lock+0x85/0xe0  ? __pfx__raw_spin_lock+0x10/0x10  ? __pte_offset_map+0x1f/0x2d0  ? unwind_next_frame+0xc5f/0x1f80  ? arch_stack_walk+0x68/0xf0  ? is_bpf_text_address+0x23/0x30  ? kernel_text_address.part.0+0xbb/0xd0  ? __kernel_text_address+0x66/0xb0  ? unwind_get_return_address+0x5e/0xa0  ? __pfx_stack_trace_consume_entry+0x10/0x10  ? arch_stack_walk+0xa2/0xf0  ? _raw_spin_lock_irqsave+0x8b/0xf0  ? __pfx__raw_spin_lock_irqsave+0x10/0x10  ? depot_alloc_stack+0x4c/0x1f0  ? _raw_spin_unlock_irqrestore+0xe/0x30  ? stack_depot_save_flags+0x35d/0x4f0  ? kasan_save_stack+0x34/0x50  ? kasan_save_stack+0x24/0x50  ? mutex_lock+0x91/0xe0  ? __pfx_mutex_lock+0x10/0x10  prepare_uprobe_buffer.part.0+0x2cd/0x500  uprobe_dispatcher+0x2c3/0x6a0  ? __pfx_uprobe_dispatcher+0x10/0x10  ? __kasan_slab_alloc+0x4d/0x90  handler_chain+0xdd/0x3e0  handle_swbp+0x26e/0x3d0  ? __pfx_handle_swbp+0x10/0x10  ? uprobe_pre_sstep_notifier+0x151/0x1b0  irqentry_exit_to_user_mode+0xe2/0x1b0  asm_exc_int3+0x39/0x40 RIP: 0033:0x401199 Code: 01 c2 0f b6 45 fb 88 02 83 45 fc 01 8b 45 fc 3b 45 e4 7c b7 8b 45 e4 48 98 48 8d 50 ff 48 8b 45 e8 48 01 d0 ce RSP: 002b:00007ffdf00576a8 EFLAGS: 00000206 RAX: 00007ffdf00576b0 RBX: 0000000000000000 RCX: 0000000000000ff2 RDX: 0000000000000ffc RSI: 0000000000000ffd RDI: 00007ffdf00576b0 RBP: 00007ffdf00586b0 R08: 00007feb2f9c0d20 R09: 00007feb2f9c0d20 R10: 0000000000000001 R11: 0000000000000202 R12: 0000000000401040 R13: 00007ffdf0058780 R14: 0000000000000000 R15: 0000000000000000  \u0026lt;/TASK\u0026gt;  This commit enforces the buffer\u0026apos;s maxlen less than a page-size to avoid store_trace_args() out-of-memory access.(CVE-2024-50067)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  parport: Proper fix for array out-of-bounds access  The recent fix for array out-of-bounds accesses replaced sprintf() calls blindly with snprintf().  However, since snprintf() returns the would-be-printed size, not the actually output size, the length calculation can still go over the given limit.  Use scnprintf() instead of snprintf(), which returns the actually output letters, for addressing the potential out-of-bounds access properly.(CVE-2024-50074)\r\n\r\nIn the Linux kernel, the following vulnerability has been resolved:  tcp: fix mptcp DSS corruption due to large pmtu xmit  Syzkaller was able to trigger a DSS corruption:    TCP: request_sock_subflow_v4: Possible SYN flooding on port [::]:20002. Sending cookies.   ------------[ cut here ]------------   WARNING: CPU: 0 PID: 5227 at net/mptcp/protocol.c:695 __mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Modules linked in:   CPU: 0 UID: 0 PID: 5227 Comm: syz-executor350 Not tainted 6.11.0-syzkaller-08829-gaf9c191ac2a0 #0   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024   RIP: 0010:__mptcp_move_skbs_from_subflow+0x20a9/0x21f0 net/mptcp/protocol.c:695   Code: 0f b6 dc 31 ff 89 de e8 b5 dd ea f5 89 d8 48 81 c4 50 01 00 00 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 98 da ea f5 90 \u0026lt;0f\u0026gt; 0b 90 e9 47 ff ff ff e8 8a da ea f5 90 0f 0b 90 e9 99 e0 ff ff   RSP: 0018:ffffc90000006db8 EFLAGS: 00010246   RAX: ffffffff8ba9df18 RBX: 00000000000055f0 RCX: ffff888030023c00   RDX: 0000000000000100 RSI: 00000000000081e5 RDI: 00000000000055f0   RBP: 1ffff110062bf1ae R08: ffffffff8ba9cf12 R09: 1ffff110062bf1b8   R10: dffffc0000000000 R11: ffffed10062bf1b9 R12: 0000000000000000   R13: dffffc0000000000 R14: 00000000700cec61 R15: 00000000000081e5   FS:  000055556679c380(0000) GS:ffff8880b8600000(0000) knlGS:0000000000000000   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033   CR2: 0000000020287000 CR3: 0000000077892000 CR4: 00000000003506f0   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400   Call Trace:    \u0026lt;IRQ\u0026gt;    move_skbs_to_msk net/mptcp/protocol.c:811 [inline]    mptcp_data_ready+0x29c/0xa90 net/mptcp/protocol.c:854    subflow_data_ready+0x34a/0x920 net/mptcp/subflow.c:1490    tcp_data_queue+0x20fd/0x76c0 net/ipv4/tcp_input.c:5283    tcp_rcv_established+0xfba/0x2020 net/ipv4/tcp_input.c:6237    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    tcp_v4_rcv+0x2dc0/0x37f0 net/ipv4/tcp_ipv4.c:2350    ip_protocol_deliver_rcu+0x22e/0x440 net/ipv4/ip_input.c:205    ip_local_deliver_finish+0x341/0x5f0 net/ipv4/ip_input.c:233    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    NF_HOOK+0x3a4/0x450 include/linux/netfilter.h:314    __netif_receive_skb_one_core net/core/dev.c:5662 [inline]    __netif_receive_skb+0x2bf/0x650 net/core/dev.c:5775    process_backlog+0x662/0x15b0 net/core/dev.c:6107    __napi_poll+0xcb/0x490 net/core/dev.c:6771    napi_poll net/core/dev.c:6840 [inline]    net_rx_action+0x89b/0x1240 net/core/dev.c:6962    handle_softirqs+0x2c5/0x980 kernel/softirq.c:554    do_softirq+0x11b/0x1e0 kernel/softirq.c:455    \u0026lt;/IRQ\u0026gt;    \u0026lt;TASK\u0026gt;    __local_bh_enable_ip+0x1bb/0x200 kernel/softirq.c:382    local_bh_enable include/linux/bottom_half.h:33 [inline]    rcu_read_unlock_bh include/linux/rcupdate.h:919 [inline]    __dev_queue_xmit+0x1764/0x3e80 net/core/dev.c:4451    dev_queue_xmit include/linux/netdevice.h:3094 [inline]    neigh_hh_output include/net/neighbour.h:526 [inline]    neigh_output include/net/neighbour.h:540 [inline]    ip_finish_output2+0xd41/0x1390 net/ipv4/ip_output.c:236    ip_local_out net/ipv4/ip_output.c:130 [inline]    __ip_queue_xmit+0x118c/0x1b80 net/ipv4/ip_output.c:536    __tcp_transmit_skb+0x2544/0x3b30 net/ipv4/tcp_output.c:1466    tcp_transmit_skb net/ipv4/tcp_output.c:1484 [inline]    tcp_mtu_probe net/ipv4/tcp_output.c:2547 [inline]    tcp_write_xmit+0x641d/0x6bf0 net/ipv4/tcp_output.c:2752    __tcp_push_pending_frames+0x9b/0x360 net/ipv4/tcp_output.c:3015    tcp_push_pending_frames include/net/tcp.h:2107 [inline]    tcp_data_snd_check net/ipv4/tcp_input.c:5714 [inline]    tcp_rcv_established+0x1026/0x2020 net/ipv4/tcp_input.c:6239    tcp_v4_do_rcv+0x96d/0xc70 net/ipv4/tcp_ipv4.c:1915    sk_backlog_rcv include/net/sock.h:1113 [inline]    __release_sock+0x214/0x350 net/core/sock.c:3072    release_sock+0x61/0x1f0 net/core/sock.c:3626    mptcp_push_ ---truncated---(CVE-2024-50083)","affected":[{"package":{"ecosystem":"openEuler:22.03-LTS-SP1","name":"kernel","purl":"pkg:rpm/openEuler/kernel\u0026distro=openEuler-22.03-LTS-SP1"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"5.10.0-136.100.0.181.oe2203sp1"}]}],"ecosystem_specific":{"aarch64":["kernel-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","kernel-debuginfo-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","kernel-debugsource-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","kernel-devel-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","kernel-headers-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","kernel-source-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","kernel-tools-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","kernel-tools-debuginfo-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","kernel-tools-devel-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","perf-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","perf-debuginfo-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","python3-perf-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm","python3-perf-debuginfo-5.10.0-136.100.0.181.oe2203sp1.aarch64.rpm"],"src":["kernel-5.10.0-136.100.0.181.oe2203sp1.src.rpm"],"x86_64":["kernel-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","kernel-debuginfo-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","kernel-debugsource-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","kernel-devel-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","kernel-headers-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","kernel-source-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","kernel-tools-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","kernel-tools-debuginfo-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","kernel-tools-devel-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","perf-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","perf-debuginfo-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","python3-perf-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm","python3-perf-debuginfo-5.10.0-136.100.0.181.oe2203sp1.x86_64.rpm"]}}],"references":[{"type":"ADVISORY","url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2024-2371"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48956"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48958"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48960"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48961"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48962"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48966"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48972"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48975"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48982"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48992"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-48995"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49004"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49005"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49011"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49017"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49020"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49023"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49031"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2022-49032"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-45021"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46677"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-46809"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47659"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47660"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47668"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47673"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47690"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47691"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47692"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47693"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47696"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47699"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47701"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47703"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47705"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47723"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47739"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47742"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47748"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-47756"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49855"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49858"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49860"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49863"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49877"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49879"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49881"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49882"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49883"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49884"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49886"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49889"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49913"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49917"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49922"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49924"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49933"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49934"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49936"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49940"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49950"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49954"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49955"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49958"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49965"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49973"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49975"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49978"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49981"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49992"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49995"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-49996"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50008"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50015"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50016"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50028"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50033"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50035"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50046"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50047"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50058"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50059"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50060"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50063"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50067"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50074"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2024-50083"}],"database_specific":{"severity":"High"}}