Kushalkhemka/embedding-cve-nvd-dataset huggingface dataset:
CVE ID: CVE-2023-53588 State: PUBLISHED Published: 2025-10-04T15:44:03.354Z Last Updated: 2025-10-04T15:44:03.354Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: mac80211: check for station first in client probe When probing a client, first check if we have it, and then check for the channel context, otherwise you can trigger the warning there easily by probing when the AP isn't even started yet. Since a client existing means the AP is also operating, we can then keep the warning. Also simplify the moved code a bit. References: - https://git.kernel.org/stable/c/7e1cda5cf07f848e6b50b4e5e7761ffbce905a3d - https://git.kernel
code a bit. References: - https://git.kernel.org/stable/c/7e1cda5cf07f848e6b50b4e5e7761ffbce905a3d - https://git.kernel.org/stable/c/7dce2deb0b03aaf46c87ceedea81ef4153e26c40 - https://git.kernel.org/stable/c/67dfa589aa8806c7959cbca2f4613b8d41c75a06
CVE ID: CVE-2023-53589 State: PUBLISHED Published: 2025-10-04T15:44:04.047Z Last Updated: 2025-10-04T15:44:04.047Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: wifi: iwlwifi: mvm: don't trust firmware n_channels If the firmware sends us a corrupted MCC response with n_channels much larger than the command response can be, we might copy far too much (uninitialized) memory and even crash if the n_channels is large enough to make it run out of the one page allocated for the FW response. Fix that by checking the lengths. Doing a < comparison would be sufficient, but the firmware should be doing it correctly, so check more strictl
lengths. Doing a < comparison would be sufficient, but the firmware should be doing it correctly, so check more strictly. References: - https://git.kernel.org/stable/c/e519a404a5bbba37693cb10fa61794a5fce4fd9b - https://git.kernel.org/stable/c/d0d39bed9e95f27a246be91c5929254ac043ed30 - https://git.kernel.org/stable/c/05ad5a4d421ce65652fcb24d46b7e273130240d6 - https://git.kernel.org/stable/c/557ba100d8cf3661ff8d71c0b4a2cba8db555ec2 - https://git.kernel.org/stable/c/c176f03350954b795322de0bfe1d7b514db41f45 - https://git.kernel.org/stable/c/682b6dc29d98e857e6ca4bbc077c7dc2899b7473
CVE ID: CVE-2023-53590 State: PUBLISHED Published: 2025-10-04T15:44:04.733Z Last Updated: 2025-10-04T15:44:04.733Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: sctp: add a refcnt in sctp_stream_priorities to avoid a nested loop With this refcnt added in sctp_stream_priorities, we don't need to traverse all streams to check if the prio is used by other streams when freeing one stream's prio in sctp_sched_prio_free_sid(). This can avoid a nested loop (up to 65535 * 65535), which may cause a stuck as Ying reported: watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136] Call Trace: <TASK> sctp_sched_prio_free_sid+0
ted: watchdog: BUG: soft lockup - CPU#23 stuck for 26s! [ksoftirqd/23:136] Call Trace: <TASK> sctp_sched_prio_free_sid+0xab/0x100 [sctp] sctp_stream_free_ext+0x64/0xa0 [sctp] sctp_stream_free+0x31/0x50 [sctp] sctp_association_free+0xa5/0x200 [sctp] Note that it doesn't need to use refcount_t type for this counter, as its accessing is always protected under the sock lock. v1->v2: - add a check in sctp_sched_prio_set to avoid the possible prio_head refcnt overflow. References: - https://git.kernel.org/stable/c/cec326443f01283ef68ea00c06ea073b1835a562 - https://git.kernel.org/stable/c/8ee401f89cdb10f39098c0656d695b2bc4052100 - https://git.kernel.org/stable/c/bf5540cbd20e2dae2c81ab9b31deef41ef14
stable/c/8ee401f89cdb10f39098c0656d695b2bc4052100 - https://git.kernel.org/stable/c/bf5540cbd20e2dae2c81ab9b31deef41ef147d0a - https://git.kernel.org/stable/c/03c3a5584a0a29821e59b7834635ce823050caaa - https://git.kernel.org/stable/c/6d529928ea212127851a2df8c40d822237ca946b - https://git.kernel.org/stable/c/68ba44639537de6f91fe32783766322d41848127
CVE ID: CVE-2023-53591 State: PUBLISHED Published: 2025-10-04T15:44:05.430Z Last Updated: 2025-10-04T15:44:05.430Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: net/mlx5e: Fix deadlock in tc route query code Cited commit causes ABBA deadlock[0] when peer flows are created while holding the devcom rw semaphore. Due to peer flows offload implementation the lock is taken much higher up the call chain and there is no obvious way to easily fix the deadlock. Instead, since tc route query code needs the peer eswitch structure only to perform a lookup in xarray and doesn't perform any sleeping operations with it, refactor the code for
structure only to perform a lookup in xarray and doesn't perform any sleeping operations with it, refactor the code for lockless execution in following ways: - RCUify the devcom 'data' pointer. When resetting the pointer synchronously wait for RCU grace period before returning. This is fine since devcom is currently only used for synchronization of pairing/unpairing of eswitches which is rare and already expensive as-is. - Wrap all usages of 'paired' boolean in {READ|WRITE}_ONCE(). The flag has already been used in some unlocked contexts without proper annotations (e.g. users of mlx5_devcom_is_paired() function), but it wasn't an issue since all relevant code paths checked it again after ob
ers of mlx5_devcom_is_paired() function), but it wasn't an issue since all relevant code paths checked it again after obtaining the devcom semaphore. Now it is also used by mlx5_devcom_get_peer_data_rcu() as "best effort" check to return NULL when devcom is being unpaired. Note that while RCU read lock doesn't prevent the unpaired flag from being changed concurrently it still guarantees that reader can continue to use 'data'. - Refactor mlx5e_tc_query_route_vport() function to use new mlx5_devcom_get_peer_data_rcu() API which fixes the deadlock. [0]: [ 164.599612] ====================================================== [ 164.600142] WARNING: possible circular locking dependency detected [ 164
============================================= [ 164.600142] WARNING: possible circular locking dependency detected [ 164.600667] 6.3.0-rc3+ #1 Not tainted [ 164.601021] ------------------------------------------------------ [ 164.601557] handler1/3456 is trying to acquire lock: [ 164.601998] ffff88811f1714b0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}, at: mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.603078] but task is already holding lock: [ 164.603617] ffff88810137fc98 (&comp->sem){++++}-{3:3}, at: mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.604459] which lock already depends on the new lock. [ 164.605190] the existing dependency chain (in reverse order) is: [ 164.605848] ->
ck already depends on the new lock. [ 164.605190] the existing dependency chain (in reverse order) is: [ 164.605848] -> #1 (&comp->sem){++++}-{3:3}: [ 164.606380] down_read+0x39/0x50 [ 164.606772] mlx5_devcom_get_peer_data+0x37/0x80 [mlx5_core] [ 164.607336] mlx5e_tc_query_route_vport+0x86/0xc0 [mlx5_core] [ 164.607914] mlx5e_tc_tun_route_lookup+0x1a4/0x1d0 [mlx5_core] [ 164.608495] mlx5e_attach_decap_route+0xc6/0x1e0 [mlx5_core] [ 164.609063] mlx5e_tc_add_fdb_flow+0x1ea/0x360 [mlx5_core] [ 164.609627] __mlx5e_add_fdb_flow+0x2d2/0x430 [mlx5_core] [ 164.610175] mlx5e_configure_flower+0x952/0x1a20 [mlx5_core] [ 164.610741] tc_setup_cb_add+0xd4/0x200 [ 164.611146] fl_hw_replace_filter+0x14c/0x1
re_flower+0x952/0x1a20 [mlx5_core] [ 164.610741] tc_setup_cb_add+0xd4/0x200 [ 164.611146] fl_hw_replace_filter+0x14c/0x1f0 [cls_flower] [ 164.611661] fl_change+0xc95/0x18a0 [cls_flower] [ 164.612116] tc_new_tfilter+0x3fc/0xd20 [ 164.612516] rtnetlink_rcv_msg+0x418/0x5b0 [ 164.612936] netlink_rcv_skb+0x54/0x100 [ 164.613339] netlink_unicast+0x190/0x250 [ 164.613746] netlink_sendmsg+0x245/0x4a0 [ 164.614150] sock_sendmsg+0x38/0x60 [ 164.614522] ____sys_sendmsg+0x1d0/0x1e0 [ 164.614934] ___sys_sendmsg+0x80/0xc0 [ 164.615320] __sys_sendmsg+0x51/0x90 [ 164.615701] do_syscall_64+0x3d/0x90 [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+
0x3d/0x90 [ 164.616083] entry_SYSCALL_64_after_hwframe+0x46/0xb0 [ 164.616568] -> #0 (&esw->offloads.encap_tbl_lock){+.+.}-{3:3}: [ 164.617210] __lock_acquire+0x159e/0x26e0 [ 164.617638] lock_acquire+0xc2/0x2a0 [ 164.618018] __mutex_lock+0x92/0xcd0 [ 164.618401] mlx5e_attach_encap+0xd8/0x8b0 [mlx5_core] [ 164.618943] post_process_attr+0x153/0x2d0 [ ---truncated--- References: - https://git.kernel.org/stable/c/69966bce28da6aadccfd968b75d128a79da32d17 - https://git.kernel.org/stable/c/362063df6ceec80b0b6798b61ae03504dcc125a5 - https://git.kernel.org/stable/c/a7236e420a7d8082b1df4b3e05c739dd2642a662 - https://git.kernel.org/stable/c/691c041bf20899fc13c793f92ba61ab660fa3a30
CVE ID: CVE-2023-53592 State: PUBLISHED Published: 2025-10-04T15:44:06.162Z Last Updated: 2025-10-04T15:44:06.162Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: gpio: sifive: Fix refcount leak in sifive_gpio_probe of_irq_find_parent() returns a node pointer with refcount incremented, We should use of_node_put() on it when not needed anymore. Add missing of_node_put() to avoid refcount leak. References: - https://git.kernel.org/stable/c/f4a2ad1002006548e235255c65a4f1d07312be9d - https://git.kernel.org/stable/c/95da1882ce9372ba20278f87cdb7a34f9812c4b5 - https://git.kernel.org/stable/c/f9fb4776ebbc16dfc512adbdc0fe218acb47c7cc - h
/95da1882ce9372ba20278f87cdb7a34f9812c4b5 - https://git.kernel.org/stable/c/f9fb4776ebbc16dfc512adbdc0fe218acb47c7cc - https://git.kernel.org/stable/c/9a402a210798662b04cbe6ca466e916a15efa03a - https://git.kernel.org/stable/c/694175cd8a1643cde3acb45c9294bca44a8e08e9
CVE ID: CVE-2023-53593 State: PUBLISHED Published: 2025-10-04T15:44:06.853Z Last Updated: 2025-10-04T15:44:06.853Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: Release folio lock on fscache read hit. Under the current code, when cifs_readpage_worker is called, the call contract is that the callee should unlock the page. This is documented in the read_folio section of Documentation/filesystems/vfs.rst as: > The filesystem should unlock the folio once the read has completed, > whether it was successful or not. Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producin
r not. Without this change, when fscache is in use and cache hit occurs during a read, the page lock is leaked, producing the following stack on subsequent reads (via mmap) to the page: $ cat /proc/3890/task/12864/stack [<0>] folio_wait_bit_common+0x124/0x350 [<0>] filemap_read_folio+0xad/0xf0 [<0>] filemap_fault+0x8b1/0xab0 [<0>] __do_fault+0x39/0x150 [<0>] do_fault+0x25c/0x3e0 [<0>] __handle_mm_fault+0x6ca/0xc70 [<0>] handle_mm_fault+0xe9/0x350 [<0>] do_user_addr_fault+0x225/0x6c0 [<0>] exc_page_fault+0x84/0x1b0 [<0>] asm_exc_page_fault+0x27/0x30 This requires a reboot to resolve; it is a deadlock. Note however that the call to cifs_readpage_from_fscache does mark the page clean, but does
resolve; it is a deadlock. Note however that the call to cifs_readpage_from_fscache does mark the page clean, but does not free the folio lock. This happens in __cifs_readpage_from_fscache on success. Releasing the lock at that point however is not appropriate as cifs_readahead also calls cifs_readpage_from_fscache and *does* unconditionally release the lock after its return. This change therefore effectively makes cifs_readpage_worker work like cifs_readahead. References: - https://git.kernel.org/stable/c/c3ac8323f2f5b50e32681c254b8318f7fa2dc3f4 - https://git.kernel.org/stable/c/5a87735675147f848445f05fd1f06168188f91af - https://git.kernel.org/stable/c/4259dd534245579c966c53c15187cc8e9461d
table/c/5a87735675147f848445f05fd1f06168188f91af - https://git.kernel.org/stable/c/4259dd534245579c966c53c15187cc8e9461d6e9 - https://git.kernel.org/stable/c/6e74926ede96470be84e66a1c576982fe4f8ea79 - https://git.kernel.org/stable/c/961f7ce16223aee2db583a43877d84e6d1f2b857 - https://git.kernel.org/stable/c/9e725386d4262ef23ae51993f04602bc535b5be2 - https://git.kernel.org/stable/c/7a9fb689c1a1dc373887621a3bfa3810df0abde4 - https://git.kernel.org/stable/c/69513dd669e243928f7450893190915a88f84a2b
CVE ID: CVE-2023-53594 State: PUBLISHED Published: 2025-10-04T15:44:07.533Z Last Updated: 2025-10-04T15:44:07.533Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: driver core: fix resource leak in device_add() When calling kobject_add() failed in device_add(), it will call cleanup_glue_dir() to free resource. But in kobject_add(), dev->kobj.parent has been set to NULL. This will cause resource leak. The process is as follows: device_add() get_device_parent() class_dir_create_and_add() kobject_add() //kobject_get() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir
t() ... dev->kobj.parent = kobj; ... kobject_add() //failed, but set dev->kobj.parent = NULL ... glue_dir = get_glue_dir(dev) //glue_dir = NULL, and goto //"Error" label ... cleanup_glue_dir() //becaues glue_dir is NULL, not call //kobject_put() The preceding problem may cause insmod mac80211_hwsim.ko to failed. sysfs: cannot create duplicate filename '/devices/virtual/mac80211_hwsim' Call Trace: <TASK> dump_stack_lvl+0x8e/0xd1 sysfs_warn_dup.cold+0x1c/0x29 sysfs_create_dir_ns+0x224/0x280 kobject_add_internal+0x2aa/0x880 kobject_add+0x135/0x1a0 get_device_parent+0x3d7/0x590 device_add+0x2aa/0x1cb0 device_create_groups_vargs+0x1eb/0x260 device_create+0xdc/0x110 mac80211_hwsim_new_radio+0x31e/
device_add+0x2aa/0x1cb0 device_create_groups_vargs+0x1eb/0x260 device_create+0xdc/0x110 mac80211_hwsim_new_radio+0x31e/0x4790 [mac80211_hwsim] init_mac80211_hwsim+0x48d/0x1000 [mac80211_hwsim] do_one_initcall+0x10f/0x630 do_init_module+0x19f/0x5e0 load_module+0x64b7/0x6eb0 __do_sys_finit_module+0x140/0x200 do_syscall_64+0x35/0x80 entry_SYSCALL_64_after_hwframe+0x46/0xb0 </TASK> kobject_add_internal failed for mac80211_hwsim with -EEXIST, don't try to register things with the same name in the same directory. References: - https://git.kernel.org/stable/c/8d389e363075c2e1deb84a560686ea92123e4b8b - https://git.kernel.org/stable/c/d1dbff10c6cd3b43457f3efd3c9c4950009635bf - https://git.kernel.org
4a560686ea92123e4b8b - https://git.kernel.org/stable/c/d1dbff10c6cd3b43457f3efd3c9c4950009635bf - https://git.kernel.org/stable/c/f39d21154db87545d8f0b25d13c326f37cc32239 - https://git.kernel.org/stable/c/6977b1a5d67097eaa4d02b0c126c04cc6e8917c0
CVE ID: CVE-2023-53595 State: PUBLISHED Published: 2025-10-04T15:44:08.261Z Last Updated: 2025-10-04T15:44:08.261Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: octeontx2-pf: mcs: Fix NULL pointer dereferences When system is rebooted after creating macsec interface below NULL pointer dereference crashes occurred. This patch fixes those crashes by using correct order of teardown [ 3324.406942] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 3324.415726] Mem abort info: [ 3324.418510] ESR = 0x96000006 [ 3324.421557] EC = 0x25: DABT (current EL), IL = 32 bits [ 3324.426865] SET = 0, FnV = 0
3324.418510] ESR = 0x96000006 [ 3324.421557] EC = 0x25: DABT (current EL), IL = 32 bits [ 3324.426865] SET = 0, FnV = 0 [ 3324.429913] EA = 0, S1PTW = 0 [ 3324.433047] Data abort info: [ 3324.435921] ISV = 0, ISS = 0x00000006 [ 3324.439748] CM = 0, WnR = 0 .... [ 3324.575915] Call trace: [ 3324.578353] cn10k_mdo_del_secy+0x24/0x180 [ 3324.582440] macsec_common_dellink+0xec/0x120 [ 3324.586788] macsec_notify+0x17c/0x1c0 [ 3324.590529] raw_notifier_call_chain+0x50/0x70 [ 3324.594965] call_netdevice_notifiers_info+0x34/0x7c [ 3324.599921] rollback_registered_many+0x354/0x5bc [ 3324.604616] unregister_netdevice_queue+0x88/0x10c [ 3324.609399] unregister_netdev+0x20/0x30 [ 3324.613313] otx2_remov
3324.604616] unregister_netdevice_queue+0x88/0x10c [ 3324.609399] unregister_netdev+0x20/0x30 [ 3324.613313] otx2_remove+0x8c/0x310 [ 3324.616794] pci_device_shutdown+0x30/0x70 [ 3324.620882] device_shutdown+0x11c/0x204 [ 966.664930] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000 [ 966.673712] Mem abort info: [ 966.676497] ESR = 0x96000006 [ 966.679543] EC = 0x25: DABT (current EL), IL = 32 bits [ 966.684848] SET = 0, FnV = 0 [ 966.687895] EA = 0, S1PTW = 0 [ 966.691028] Data abort info: [ 966.693900] ISV = 0, ISS = 0x00000006 [ 966.697729] CM = 0, WnR = 0 [ 966.833467] Call trace: [ 966.835904] cn10k_mdo_stop+0x20/0xa0 [ 966.839557] macsec_dev_stop+0xe
7729] CM = 0, WnR = 0 [ 966.833467] Call trace: [ 966.835904] cn10k_mdo_stop+0x20/0xa0 [ 966.839557] macsec_dev_stop+0xe8/0x11c [ 966.843384] __dev_close_many+0xbc/0x140 [ 966.847298] dev_close_many+0x84/0x120 [ 966.851039] rollback_registered_many+0x114/0x5bc [ 966.855735] unregister_netdevice_many.part.0+0x14/0xa0 [ 966.860952] unregister_netdevice_many+0x18/0x24 [ 966.865560] macsec_notify+0x1ac/0x1c0 [ 966.869303] raw_notifier_call_chain+0x50/0x70 [ 966.873738] call_netdevice_notifiers_info+0x34/0x7c [ 966.878694] rollback_registered_many+0x354/0x5bc [ 966.883390] unregister_netdevice_queue+0x88/0x10c [ 966.888173] unregister_netdev+0x20/0x30 [ 966.892090] otx2_remove+0x8c/0x310 [ 966.89
ister_netdevice_queue+0x88/0x10c [ 966.888173] unregister_netdev+0x20/0x30 [ 966.892090] otx2_remove+0x8c/0x310 [ 966.895571] pci_device_shutdown+0x30/0x70 [ 966.899660] device_shutdown+0x11c/0x204 [ 966.903574] __do_sys_reboot+0x208/0x290 [ 966.907487] __arm64_sys_reboot+0x20/0x30 [ 966.911489] el0_svc_handler+0x80/0x1c0 [ 966.915316] el0_svc+0x8/0x180 [ 966.918362] Code: f9400000 f9400a64 91220014 f94b3403 (f9400060) [ 966.924448] ---[ end trace 341778e799c3d8d7 ]--- References: - https://git.kernel.org/stable/c/a3dcc45eca017fca82ac47dbde6f41af960657e5 - https://git.kernel.org/stable/c/1152c0f947b76e7731e039185cbd00fdb4389f00 - https://git.kernel.org/stable/c/13ff119b17e5e2916435ce01a0156c
l.org/stable/c/1152c0f947b76e7731e039185cbd00fdb4389f00 - https://git.kernel.org/stable/c/13ff119b17e5e2916435ce01a0156c8698ad9e16 - https://git.kernel.org/stable/c/699af748c61574125d269db260dabbe20436d74e
CVE ID: CVE-2023-53596 State: PUBLISHED Published: 2025-10-04T15:44:08.942Z Last Updated: 2025-10-04T15:44:08.942Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: drivers: base: Free devm resources when unregistering a device In the current code, devres_release_all() only gets called if the device has a bus and has been probed. This leads to issues when using bus-less or driver-less devices where the device might never get freed if a managed resource holds a reference to the device. This is happening in the DRM framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the devi
framework for example. We should thus call devres_release_all() in the device_del() function to make sure that the device-managed actions are properly executed when the device is unregistered, even if it has neither a bus nor a driver. This is effectively the same change than commit 2f8d16a996da ("devres: release resources on device_del()") that got reverted by commit a525a3ddeaca ("driver core: free devres in device_release") over memory leaks concerns. This patch effectively combines the two commits mentioned above to release the resources both on device_del() and device_release() and get the best of both worlds. References: - https://git.kernel.org/stable/c/297992e5c63528e603666e36081836
_release() and get the best of both worlds. References: - https://git.kernel.org/stable/c/297992e5c63528e603666e36081836204fc36ec9 - https://git.kernel.org/stable/c/3bcc4c2a096e8342c8c719e595ce15de212694dd - https://git.kernel.org/stable/c/c8c426fae26086a0ca8ab6cc6da2de79810ec038 - https://git.kernel.org/stable/c/699fb50d99039a50e7494de644f96c889279aca3
CVE ID: CVE-2023-53597 State: PUBLISHED Published: 2025-10-04T15:44:09.616Z Last Updated: 2025-10-04T15:44:09.616Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: cifs: fix mid leak during reconnection after timeout threshold When the number of responses with status of STATUS_IO_TIMEOUT exceeds a specified threshold (NUM_STATUS_IO_TIMEOUT), we reconnect the connection. But we do not return the mid, or the credits returned for the mid, or reduce the number of in-flight requests. This bug could result in the server->in_flight count to go bad, and also cause a leak in the mids. This change moves the check to a few lines below where
er->in_flight count to go bad, and also cause a leak in the mids. This change moves the check to a few lines below where the response is decrypted, even of the response is read from the transform header. This way, the code for returning the mids can be reused. Also, the cifs_reconnect was reconnecting just the transport connection before. In case of multi-channel, this may not be what we want to do after several timeouts. Changed that to reconnect the session and the tree too. Also renamed NUM_STATUS_IO_TIMEOUT to a more appropriate name MAX_STATUS_IO_TIMEOUT. References: - https://git.kernel.org/stable/c/df31d05f0678cdd0796ea19983a2b93edca18bb0 - https://git.kernel.org/stable/c/c55901d381a2
https://git.kernel.org/stable/c/df31d05f0678cdd0796ea19983a2b93edca18bb0 - https://git.kernel.org/stable/c/c55901d381a22300c9922170e59704059f50977b - https://git.kernel.org/stable/c/57d25e9905c71133e201f6d06b56a3403d4ad433 - https://git.kernel.org/stable/c/69cba9d3c1284e0838ae408830a02c4a063104bc
CVE ID: CVE-2023-53598 State: PUBLISHED Published: 2025-10-04T15:44:10.380Z Last Updated: 2025-10-04T15:44:10.380Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: bus: mhi: host: Range check CHDBOFF and ERDBOFF If the value read from the CHDBOFF and ERDBOFF registers is outside the range of the MHI register space then an invalid address might be computed which later causes a kernel panic. Range check the read value to prevent a crash due to bad data from the device. References: - https://git.kernel.org/stable/c/372f1752b74572b0a9d2288841eab7db17daccae - https://git.kernel.org/stable/c/2343385fe6eed11d0432ab42a97b3ca4aef06a99 - h
/372f1752b74572b0a9d2288841eab7db17daccae - https://git.kernel.org/stable/c/2343385fe6eed11d0432ab42a97b3ca4aef06a99 - https://git.kernel.org/stable/c/a2cbb1a45a0c86ce77839c0875414efe1a89315e - https://git.kernel.org/stable/c/83bf6b87e2dd053d95d89eb2f01ae885f9e568db - https://git.kernel.org/stable/c/4e584127ec2bd42a37c88badb49df409f21fa40a - https://git.kernel.org/stable/c/6a0c637bfee69a74c104468544d9f2a6579626d0
CVE ID: CVE-2023-53599 State: PUBLISHED Published: 2025-10-04T15:44:11.096Z Last Updated: 2025-10-04T15:44:11.096Z Vendors: Linux Products: Linux Description: In the Linux kernel, the following vulnerability has been resolved: crypto: af_alg - Fix missing initialisation affecting gcm-aes-s390 Fix af_alg_alloc_areq() to initialise areq->first_rsgl.sgl.sgt.sgl to point to the scatterlist array in areq->first_rsgl.sgl.sgl. Without this, the gcm-aes-s390 driver will oops when it tries to do gcm_walk_start() on req->dst because req->dst is set to the value of areq->first_rsgl.sgl.sgl by _aead_recvmsg() calling aead_request_set_crypt(). The problem comes if an empty ciphertext is passed: the loop