yahoo-inc/cve-impacts huggingface dataset:
CVE-2024-26491: A cross-site scripting (XSS) vulnerability in the Addon JD Flusity 'Media Gallery with description' module of flusity-CMS v2.33 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Gallery name text field.
Key phrases: execute arbitrary web scripts or HTML, execute arbitrary web scripts or HTML via a, cross-site scripting (xss)
CVE-2024-26492: An issue in Online Diagnostic Lab Management System 1.0 allows a remote attacker to gain control of a 'Staff' user account via a crafted POST request using the id, email, password, and cpass parameters.
Key phrases: gain control, gain control of a 'Staff' user
CVE-2024-26495: Cross Site Scripting (XSS) vulnerability in Friendica versions after v.2023.12, allows a remote attacker to execute arbitrary code and obtain sensitive information via the BBCode tags in the post content and post comments function.
Key phrases: execute arbitrary code, obtain sensitive information, execute arbitrary code and obtain sensitive information via, cross site scripting (xss)
CVE-2024-26503: Unrestricted File Upload vulnerability in Greek Universities Network Open eClass v.3.15 and earlier allows attackers to run arbitrary code via upload of crafted file to certbadge.php endpoint.
Key phrases: run arbitrary code, run arbitrary code via upload of crafted file, unrestricted file upload
CVE-2024-26521: HTML Injection vulnerability in CE Phoenix v1.0.8.20 and before allows a remote attacker to execute arbitrary code, escalate privileges, and obtain sensitive information via a crafted payload to the english.php component.
Key phrases: execute arbitrary code, obtain sensitive information, html injection, escalate privileges
CVE-2024-26529: An issue in mz-automation libiec61850 v.1.5.3 and before, allows a remote attacker to cause a denial of service (DoS) via the mmsServer_handleDeleteNamedVariableListRequest function of src/mms/iso_mms/server/mms_named_variable_list_service.c.
Key phrases: denial of service (DoS), cause a denial of service (DoS), denial of service (dos)
CVE-2024-2653: amphp/http will collect CONTINUATION frames in an unbounded buffer and will not check a limit until it has received the set END_HEADERS flag, resulting in an OOM crash.
Key phrases: oom crash
CVE-2024-26540: A heap-based buffer overflow in Clmg before 3.3.3 can occur via a crafted file to cimg_library::CImg<unsigned char>::_load_analyze.
Key phrases: heap-based buffer overflow, heap based buffer overflow
CVE-2024-26542: Cross Site Scripting vulnerability in Bonitasoft, S.A v.7.14. and fixed in v.9.0.2, 8.0.3, 7.15.7, 7.14.8 allows attackers to execute arbitrary code via a crafted payload to the Groups Display name field.
Key phrases: execute arbitrary code, execute arbitrary code via a crafted payload to, cross site scripting
CVE-2024-26548: An issue in vivotek Network Camera v.FD8166A-VVTK-0204j allows a remote attacker to execute arbitrary code via a crafted payload to the upload_file.cgi component.
Key phrases: execute arbitrary code, execute arbitrary code via a crafted payload to
CVE-2024-26557: Codiad v2.8.4 allows reflected XSS via the components/market/dialog.php type parameter.
Key phrases: reflected XSS via the components/market/, xss
CVE-2024-26559: An issue in uverif v.2.0 allows a remote attacker to obtain sensitive information.
Key phrases: obtain sensitive information
CVE-2024-26566: An issue in Cute Http File Server v.3.1 allows a remote attacker to escalate privileges via the password verification component.
Key phrases: escalate privileges via the password verification component
CVE-2024-26577: VSeeFace through 1.13.38.c2 allows attackers to cause a denial of service (application hang) via a spoofed UDP packet containing at least 10 digits in JSON data.
Key phrases: denial of service (application hang), cause a denial of service (application hang, vseeface, spoofing
CVE-2024-26578: Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition') vulnerability in Apache Answer.This issue affects Apache Answer: through 1.2.1.Repeated submission during registration resulted in the registration of the same user. When users register, if they rapidly submit multiple registrations using scripts, it can result in the creation of multiple user accounts simultaneously with the same name.Users are recommended to upgrade to version [1.2.5], which fixes the issue.
Key phrases: concurrent execution using shared resource with improper synchronization
CVE-2024-26580: Deserialization of Untrusted Data vulnerability in Apache InLong.This issue affects Apache InLong: from 1.8.0 through 1.10.0, the attackers can use the specific payload to read from an arbitrary file. Users are advised to upgrade to Apache InLong's 1.11.0 or cherry-pick [1] to solve it.[1]  https://github.com/apache/inlong/pull/9673 
Key phrases: deserialization of untrusted data, arbitrary file
CVE-2024-26581: In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_rbtree: skip end interval element from gcrbtree lazy gc on insert might collect an end interval element that hasbeen just added in this transactions, skip end interval elements thatare not yet active.
CVE-2024-26582: In the Linux kernel, the following vulnerability has been resolved:net: tls: fix use-after-free with partial reads and async decrypttls_decrypt_sg doesn't take a reference on the pages from clear_skb,so the put_page() in tls_decrypt_done releases them, and we triggera use-after-free in process_rx_list when we try to read from thepartially-read skb.
Key phrases: use-after-free, partial reads, use after free
CVE-2024-26583: In the Linux kernel, the following vulnerability has been resolved:tls: fix race between async notify and socket closeThe submitting thread (one which called recvmsg/sendmsg)may exit as soon as the async crypto handler calls complete()so any code past that point risks touching already freed data.Try to avoid the locking and extra flags altogether.Have the main thread hold an extra reference, this waywe can depend solely on the atomic ref counter forsynchronization.Don't futz with reiniting the completion, either, we are nowtightly controlling when completion fires.
CVE-2024-26584: In the Linux kernel, the following vulnerability has been resolved:net: tls: handle backlogging of crypto requestsSince we're setting the CRYPTO_TFM_REQ_MAY_BACKLOG flag on ourrequests to the crypto API, crypto_aead_{encrypt,decrypt} can return -EBUSY instead of -EINPROGRESS in valid situations. For example, whenthe cryptd queue for AESNI is full (easy to trigger with anartificially low cryptd.cryptd_max_cpu_qlen), requests will be enqueuedto the backlog but still processed. In that case, the async callbackwill also be called twice: first with err == -EINPROGRESS, which itseems we can just ignore, then with err == 0.Compared to Sabrina's original patch this version uses the newtls_*crypt_async_wait() helpers and converts the EBUSY toEINPROGRESS to avoid having to modify all the error handlingpaths. The handling is identical.
CVE-2024-26585: In the Linux kernel, the following vulnerability has been resolved:tls: fix race between tx work scheduling and socket closeSimilarly to previous commit, the submitting thread (recvmsg/sendmsg)may exit as soon as the async crypto handler calls complete().Reorder scheduling the work before calling complete().This seems more logical in the first place, as it'sthe inverse order of what the submitting thread will do.
Key phrases: race
CVE-2024-26586: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix stack corruptionWhen tc filters are first added to a net device, the corresponding localport gets bound to an ACL group in the device. The group contains a listof ACLs. In turn, each ACL points to a different TCAM region where thefilters are stored. During forwarding, the ACLs are sequentiallyevaluated until a match is found.One reason to place filters in different regions is when they are addedwith decreasing priorities and in an alternating order so that twoconsecutive filters can never fit in the same region because of theirkey usage.In Spectrum-2 and newer ASICs the firmware started to report that themaximum number of ACLs in a group is more than 16, but the layout of theregister that configures ACL groups (PAGT) was not updated to accountfor that. It is therefore possible to hit stack corruption [1] in therare case where more than 16 ACLs in a group are required.Fix by limiting the maximum ACL group size to the minimum between whatthe firmware reports and the maximum ACLs that fit in the PAGT register.Add a test case to make sure the machine does not crash when thiscondition is hit.[1]Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120[...] dump_stack_lvl+0x36/0x50 panic+0x305/0x330 __stack_chk_fail+0x15/0x20 mlxsw_sp_acl_tcam_group_update+0x116/0x120 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Key phrases: stack corruption, crash
CVE-2024-26587: In the Linux kernel, the following vulnerability has been resolved:net: netdevsim: don't try to destroy PHC on VFsPHC gets initialized in nsim_init_netdevsim(), whichis only called if (nsim_dev_port_is_pf()).Create a counterpart of nsim_init_netdevsim() andmove the mock_phc_destroy() there.This fixes a crash trying to destroy netdevsim withVFs instantiated, as caught by running the devlink.sh test:    BUG: kernel NULL pointer dereference, address: 00000000000000b8    RIP: 0010:mock_phc_destroy+0xd/0x30    Call Trace:     <TASK>     nsim_destroy+0x4a/0x70 [netdevsim]     __nsim_dev_port_del+0x47/0x70 [netdevsim]     nsim_dev_reload_destroy+0x105/0x120 [netdevsim]     nsim_drv_remove+0x2f/0xb0 [netdevsim]     device_release_driver_internal+0x1a1/0x210     bus_remove_device+0xd5/0x120     device_del+0x159/0x490     device_unregister+0x12/0x30     del_device_store+0x11a/0x1a0 [netdevsim]     kernfs_fop_write_iter+0x130/0x1d0     vfs_write+0x30b/0x4b0     ksys_write+0x69/0xf0     do_syscall_64+0xcc/0x1e0     entry_SYSCALL_64_after_hwframe+0x6f/0x77
Key phrases: crash
CVE-2024-26589: In the Linux kernel, the following vulnerability has been resolved:bpf: Reject variable offset alu on PTR_TO_FLOW_KEYSFor PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed offfor validation. However, variable offset ptr alu is not prohibitedfor this ptr kind. So the variable offset is not checked.The following prog is accepted:  func#0 @0  0: R1=ctx() R10=fp0  0: (bf) r6 = r1                       ; R1=ctx() R6_w=ctx()  1: (79) r7 = *(u64 *)(r6 +144)        ; R6_w=ctx() R7_w=flow_keys()  2: (b7) r8 = 1024                     ; R8_w=1024  3: (37) r8 /= 1                       ; R8_w=scalar()  4: (57) r8 &= 1024                    ; R8_w=scalar(smin=smin32=0,  smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))  5: (0f) r7 += r8  mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1  mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &= 1024  mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1  mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024  6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off  =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,  var_off=(0x0; 0x400))  6: (79) r0 = *(u64 *)(r7 +0)          ; R0_w=scalar()  7: (95) exitThis prog loads flow_keys to r7, and adds the variable offset r8to r7, and finally causes out-of-bounds access:  BUG: unable to handle page fault for address: ffffc90014c80038  [...]  Call Trace:   <TASK>   bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]   __bpf_prog_run include/linux/filter.h:651 [inline]   bpf_prog_run include/linux/filter.h:658 [inline]   bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]   bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991   bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359   bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]   __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475   __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]   __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]   __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559   do_syscall_x64 arch/x86/entry/common.c:52 [inline]   do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83   entry_SYSCALL_64_after_hwframe+0x63/0x6bFix this by rejecting ptr alu with variable offset on flow_keys.Applying the patch rejects the program with "R7 pointer arithmeticon flow_keys prohibited".
Key phrases: out of bounds access
CVE-2024-26590: In the Linux kernel, the following vulnerability has been resolved:erofs: fix inconsistent per-file compression formatEROFS can select compression algorithms on a per-file basis, and eachper-file compression algorithm needs to be marked in the on-disksuperblock for initialization.However, syzkaller can generate inconsistent crafted images that usean unsupported algorithmtype for specific inodes, e.g. use MicroLZMAalgorithmtype even it's not set in `sbi->available_compr_algs`.  Thiscan lead to an unexpected "BUG: kernel NULL pointer dereference" ifthe corresponding decompressor isn't built-in.Fix this by checking against `sbi->available_compr_algs` for eachm_algorithmformat request.  Incorrect !erofs_sb_has_compr_cfgs presetbitmap is now fixed together since it was harmless previously.
Key phrases: bug: kernel null pointer dereference
CVE-2024-26591: In the Linux kernel, the following vulnerability has been resolved:bpf: Fix re-attachment branch in bpf_tracing_prog_attachThe following case can cause a crash due to missing attach_btf:1) load rawtp program2) load fentry program with rawtp as target_fd3) create tracing link for fentry program with target_fd = 04) repeat 3In the end we have:- prog->aux->dst_trampoline == NULL- tgt_prog == NULL (because we did not provide target_fd to link_create)- prog->aux->attach_btf == NULL (the program was loaded with attach_prog_fd=X)- the program was loaded for tgt_prog but we have no way to find out which one    BUG: kernel NULL pointer dereference, address: 0000000000000058    Call Trace:     <TASK>     ? __die+0x20/0x70     ? page_fault_oops+0x15b/0x430     ? fixup_exception+0x22/0x330     ? exc_page_fault+0x6f/0x170     ? asm_exc_page_fault+0x22/0x30     ? bpf_tracing_prog_attach+0x279/0x560     ? btf_obj_id+0x5/0x10     bpf_tracing_prog_attach+0x439/0x560     __sys_bpf+0x1cf4/0x2de0     __x64_sys_bpf+0x1c/0x30     do_syscall_64+0x41/0xf0     entry_SYSCALL_64_after_hwframe+0x6e/0x76Return -EINVAL in this situation.
Key phrases: crash
CVE-2024-26592: In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix UAF issue in ksmbd_tcp_new_connection()The race is between the handling of a new TCP connection andits disconnection. It leads to UAF on `struct tcp_transport` inksmbd_tcp_new_connection() function.
Key phrases: uaf
CVE-2024-26593: In the Linux kernel, the following vulnerability has been resolved:i2c: i801: Fix block process call transactionsAccording to the Intel datasheets, software must reset the blockbuffer index twice for block process call transactions: once beforewriting the outgoing data to the buffer, and once again beforereading the incoming data from the buffer.The driver is currently missing the second reset, causing the wrongportion of the block buffer to be read.
Key phrases: buffer over read
CVE-2024-26594: In the Linux kernel, the following vulnerability has been resolved:ksmbd: validate mech token in session setupIf client send invalid mech token in session setup request, ksmbdvalidate and make the error if it is invalid.
CVE-2024-26595: In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error pathWhen calling mlxsw_sp_acl_tcam_region_destroy() from an error path afterfailing to attach the region to an ACL group, we hit a NULL pointerdereference upon 'region->group->tcam' [1].Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().[1]BUG: kernel NULL pointer dereference, address: 0000000000000000[...]RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0[...]Call Trace: mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0 mlxsw_sp_acl_rule_add+0x47/0x240 mlxsw_sp_flower_replace+0x1a9/0x1d0 tc_setup_cb_add+0xdc/0x1c0 fl_hw_replace_filter+0x146/0x1f0 fl_change+0xc17/0x1360 tc_new_tfilter+0x472/0xb90 rtnetlink_rcv_msg+0x313/0x3b0 netlink_rcv_skb+0x58/0x100 netlink_unicast+0x244/0x390 netlink_sendmsg+0x1e4/0x440 ____sys_sendmsg+0x164/0x260 ___sys_sendmsg+0x9a/0xe0 __sys_sendmsg+0x7a/0xc0 do_syscall_64+0x40/0xe0 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Key phrases: null pointer dereference
CVE-2024-26596: In the Linux kernel, the following vulnerability has been resolved:net: dsa: fix netdev_priv() dereference before check on non-DSA netdevice eventsAfter the blamed commit, we started doing this dereference for everyNETDEV_CHANGEUPPER and NETDEV_PRECHANGEUPPER event in the system.static inline struct dsa_port *dsa_user_to_port(const struct net_device *dev){	struct dsa_user_priv *p = netdev_priv(dev);	return p->dp;}Which is obviously bogus, because not all net_devices have a netdev_priv()of type struct dsa_user_priv. But struct dsa_user_priv is fairly small,and p->dp means dereferencing 8 bytes starting with offset 16. Mostdrivers allocate that much private memory anyway, making our access notfault, and we discard the bogus data quickly afterwards, so this wasn'tcaught.But the dummy interface is somewhat special in that it callsalloc_netdev() with a priv size of 0. So every netdev_priv() dereferenceis invalid, and we get this when we emit a NETDEV_PRECHANGEUPPER eventwith a VLAN as its new upper:$ ip link add dummy1 type dummy$ ip link add link dummy1 name dummy1.100 type vlan id 100[   43.309174] ==================================================================[   43.316456] BUG: KASAN: slab-out-of-bounds in dsa_user_prechangeupper+0x30/0xe8[   43.323835] Read of size 8 at addr ffff3f86481d2990 by task ip/374[   43.330058][   43.342436] Call trace:[   43.366542]  dsa_user_prechangeupper+0x30/0xe8[   43.371024]  dsa_user_netdevice_event+0xb38/0xee8[   43.375768]  notifier_call_chain+0xa4/0x210[   43.379985]  raw_notifier_call_chain+0x24/0x38[   43.384464]  __netdev_upper_dev_link+0x3ec/0x5d8[   43.389120]  netdev_upper_dev_link+0x70/0xa8[   43.393424]  register_vlan_dev+0x1bc/0x310[   43.397554]  vlan_newlink+0x210/0x248[   43.401247]  rtnl_newlink+0x9fc/0xe30[   43.404942]  rtnetlink_rcv_msg+0x378/0x580Avoid the kernel oops by dereferencing after the type check, as customary.
CVE-2024-26598: In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cacheThere is a potential UAF scenario in the case of an LPI translationcache hit racing with an operation that invalidates the cache, suchas a DISCARD ITS command. The root of the problem is thatvgic_its_check_cache() does not elevate the refcount on the vgic_irqbefore dropping the lock that serializes refcount changes.Have vgic_its_check_cache() raise the refcount on the returned vgic_irqand add the corresponding decrement after queueing the interrupt.
Key phrases: uaf
CVE-2024-26599: In the Linux kernel, the following vulnerability has been resolved:pwm: Fix out-of-bounds access in of_pwm_single_xlate()With args->args_count == 2 args->args[2] is not defined. Actually theflags are contained in args->args[1].
Key phrases: out-of-bounds access, out of bounds access
CVE-2024-26600: In the Linux kernel, the following vulnerability has been resolved:phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRPIf the external phy working together with phy-omap-usb2 does not implementsend_srp(), we may still attempt to call it. This can happen on an idleEthernet gadget triggering a wakeup for example:configfs-gadget.g1 gadget.0: ECM Suspendconfigfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup...Unable to handle kernel NULL pointer dereference at virtual address00000000 when execute...PC is at 0x0LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]...musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24cdev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4sch_direct_xmit from __dev_queue_xmit+0x334/0xd88__dev_queue_xmit from arp_solicit+0xf0/0x268arp_solicit from neigh_probe+0x54/0x7cneigh_probe from __neigh_event_send+0x22c/0x47c__neigh_event_send from neigh_resolve_output+0x14c/0x1c0neigh_resolve_output from ip_finish_output2+0x1c8/0x628ip_finish_output2 from ip_send_skb+0x40/0xd8ip_send_skb from udp_send_skb+0x124/0x340udp_send_skb from udp_sendmsg+0x780/0x984udp_sendmsg from __sys_sendto+0xd8/0x158__sys_sendto from ret_fast_syscall+0x0/0x58Let's fix the issue by checking for send_srp() and set_vbus() beforecalling them. For USB peripheral only cases these both could be NULL.
CVE-2024-26601: In the Linux kernel, the following vulnerability has been resolved:ext4: regenerate buddy after block freeing failed if under fc replayThis mostly reverts commit 6bd97bf273bd ("ext4: remove redundantmb_regenerate_buddy()") and reintroduces mb_regenerate_buddy(). Based oncode in mb_free_blocks(), fast commit replay can end up marking as freeblocks that are already marked as such. This causes corruption of thebuddy bitmap so we need to regenerate it in that case.
CVE-2024-26602: In the Linux kernel, the following vulnerability has been resolved:sched/membarrier: reduce the ability to hammer on sys_membarrierOn some systems, sys_membarrier can be very expensive, causing overallslowdowns for everything.  So put a lock on the path in order toserialize the accesses to prevent the ability for this to be called attoo high of a frequency and saturate the machine.
Key phrases: sched membarrier
CVE-2024-26603: In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Stop relying on userspace for info to fault in xsave bufferBefore this change, the expected size of the user space buffer wastaken from fx_sw->xstate_size. fx_sw->xstate_size can be changedfrom user-space, so it is possible construct a sigreturn frame where: * fx_sw->xstate_size is smaller than the size required by valid bits in   fx_sw->xfeatures. * user-space unmaps parts of the sigrame fpu buffer so that not all of   the buffer required by xrstor is accessible.In this case, xrstor tries to restore and accesses the unmapped areawhich results in a fault. But fault_in_readable succeeds because buf +fx_sw->xstate_size is within the still mapped area, so it goes back andtries xrstor again. It will spin in this loop forever.Instead, fault in the maximum size which can be touched by XRSTOR (takenfrom fpstate->user_size).[ dhansen: tweak subject / changelog ]
CVE-2024-26604: In the Linux kernel, the following vulnerability has been resolved:Revert "kobject: Remove redundant checks for whether ktype is NULL"This reverts commit 1b28cb81dab7c1eedc6034206f4e8d644046ad31.It is reported to cause problems, so revert it for now until the rootcause can be found.
Key phrases: cause problems
CVE-2024-26605: In the Linux kernel, the following vulnerability has been resolved:PCI/ASPM: Fix deadlock when enabling ASPMA last minute revert in 6.7-final introduced a potential deadlock whenenabling ASPM during probe of Qualcomm PCIe controllers as reported bylockdep:  ============================================  WARNING: possible recursive locking detected  6.7.0 #40 Not tainted  --------------------------------------------  kworker/u16:5/90 is trying to acquire lock:  ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pcie_aspm_pm_state_change+0x58/0xdc              but task is already holding lock:  ffffacfa78ced000 (pci_bus_sem){++++}-{3:3}, at: pci_walk_bus+0x34/0xbc              other info that might help us debug this:   Possible unsafe locking scenario:         CPU0         ----    lock(pci_bus_sem);    lock(pci_bus_sem);               *** DEADLOCK ***  Call trace:   print_deadlock_bug+0x25c/0x348   __lock_acquire+0x10a4/0x2064   lock_acquire+0x1e8/0x318   down_read+0x60/0x184   pcie_aspm_pm_state_change+0x58/0xdc   pci_set_full_power_state+0xa8/0x114   pci_set_power_state+0xc4/0x120   qcom_pcie_enable_aspm+0x1c/0x3c [pcie_qcom]   pci_walk_bus+0x64/0xbc   qcom_pcie_host_post_init_2_7_0+0x28/0x34 [pcie_qcom]The deadlock can easily be reproduced on machines like the Lenovo ThinkPadX13s by adding a delay to increase the race window during asynchronousprobe where another thread can take a write lock.Add a new pci_set_power_state_locked() and associated helper functions thatcan be called with the PCI bus semaphore held to avoid taking the read locktwice.
CVE-2024-26606: In the Linux kernel, the following vulnerability has been resolved:binder: signal epoll threads of self-workIn (e)poll mode, threads often depend on I/O events to determine whendata is ready for consumption. Within binder, a thread may initiate acommand via BINDER_WRITE_READ without a read buffer and then make useof epoll_wait() or similar to consume any responses afterwards.It is then crucial that epoll threads are signaled via wakeup when theyqueue their own work. Otherwise, they risk waiting indefinitely for anevent leaving their work unhandled. What is worse, subsequent commandswon't trigger a wakeup either as the thread has pending work.
CVE-2024-26607: In the Linux kernel, the following vulnerability has been resolved:drm/bridge: sii902x: Fix probing race issueA null pointer dereference crash has been observed rarely on TIplatforms using sii9022 bridge:[   53.271356]  sii902x_get_edid+0x34/0x70 [sii902x][   53.276066]  sii902x_bridge_get_edid+0x14/0x20 [sii902x][   53.281381]  drm_bridge_get_edid+0x20/0x34 [drm][   53.286305]  drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper][   53.292955]  drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper][   53.300510]  drm_client_modeset_probe+0x1f0/0xbd4 [drm][   53.305958]  __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper][   53.313611]  drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper][   53.320039]  drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper][   53.326401]  drm_client_register+0x5c/0xa0 [drm][   53.331216]  drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper][   53.336881]  tidss_probe+0x128/0x264 [tidss][   53.341174]  platform_probe+0x68/0xc4[   53.344841]  really_probe+0x188/0x3c4[   53.348501]  __driver_probe_device+0x7c/0x16c[   53.352854]  driver_probe_device+0x3c/0x10c[   53.357033]  __device_attach_driver+0xbc/0x158[   53.361472]  bus_for_each_drv+0x88/0xe8[   53.365303]  __device_attach+0xa0/0x1b4[   53.369135]  device_initial_probe+0x14/0x20[   53.373314]  bus_probe_device+0xb0/0xb4[   53.377145]  deferred_probe_work_func+0xcc/0x124[   53.381757]  process_one_work+0x1f0/0x518[   53.385770]  worker_thread+0x1e8/0x3dc[   53.389519]  kthread+0x11c/0x120[   53.392750]  ret_from_fork+0x10/0x20The issue here is as follows:- tidss probes, but is deferred as sii902x is still missing.- sii902x starts probing and enters sii902x_init().- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from  DRM's perspective.- sii902x calls sii902x_audio_codec_init() and  platform_device_register_data()- The registration of the audio platform device causes probing of the  deferred devices.- tidss probes, which eventually causes sii902x_bridge_get_edid() to be  called.- sii902x_bridge_get_edid() tries to use the i2c to read the edid.  However, the sii902x driver has not set up the i2c part yet, leading  to the crash.Fix this by moving the drm_bridge_add() to the end of thesii902x_init(), which is also at the very end of sii902x_probe().
Key phrases: null pointer dereference crash
CVE-2024-26610: In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: fix a memory corruptioniwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means thatif we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is inbytes, we'll write past the buffer.
Key phrases: memory corruptioniwl_fw_ini_trigger_tlv
CVE-2024-26611: In the Linux kernel, the following vulnerability has been resolved:xsk: fix usage of multi-buffer BPF helpers for ZC XDPCurrently when packet is shrunk via bpf_xdp_adjust_tail() and memorytype is set to MEM_TYPE_XSK_BUFF_POOL, null ptr dereference happens:[1136314.192256] BUG: kernel NULL pointer dereference, address:0000000000000034[1136314.203943] #PF: supervisor read access in kernel mode[1136314.213768] #PF: error_code(0x0000) - not-present page[1136314.223550] PGD 0 P4D 0[1136314.230684] Oops: 0000 [#1] PREEMPT SMP NOPTI[1136314.239621] CPU: 8 PID: 54203 Comm: xdpsock Not tainted 6.6.0+ #257[1136314.250469] Hardware name: Intel Corporation S2600WFT/S2600WFT,BIOS SE5C620.86B.02.01.0008.031920191559 03/19/2019[1136314.265615] RIP: 0010:__xdp_return+0x6c/0x210[1136314.274653] Code: ad 00 48 8b 47 08 49 89 f8 a8 01 0f 85 9b 01 00 00 0f 1f 44 00 00 f0 41 ff 48 34 75 32 4c 89 c7 e9 79 cd 80 ff 83 fe 03 75 17 <f6> 41 34 01 0f 85 02 01 00 00 48 89 cf e9 22 cc 1e 00 e9 3d d2 86[1136314.302907] RSP: 0018:ffffc900089f8db0 EFLAGS: 00010246[1136314.312967] RAX: ffffc9003168aed0 RBX: ffff8881c3300000 RCX:0000000000000000[1136314.324953] RDX: 0000000000000000 RSI: 0000000000000003 RDI:ffffc9003168c000[1136314.336929] RBP: 0000000000000ae0 R08: 0000000000000002 R09:0000000000010000[1136314.348844] R10: ffffc9000e495000 R11: 0000000000000040 R12:0000000000000001[1136314.360706] R13: 0000000000000524 R14: ffffc9003168aec0 R15:0000000000000001[1136314.373298] FS:  00007f8df8bbcb80(0000) GS:ffff8897e0e00000(0000)knlGS:0000000000000000[1136314.386105] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[1136314.396532] CR2: 0000000000000034 CR3: 00000001aa912002 CR4:00000000007706f0[1136314.408377] DR0: 0000000000000000 DR1: 0000000000000000 DR2:0000000000000000[1136314.420173] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:0000000000000400[1136314.431890] PKRU: 55555554[1136314.439143] Call Trace:[1136314.446058]  <IRQ>[1136314.452465]  ? __die+0x20/0x70[1136314.459881]  ? page_fault_oops+0x15b/0x440[1136314.468305]  ? exc_page_fault+0x6a/0x150[1136314.476491]  ? asm_exc_page_fault+0x22/0x30[1136314.484927]  ? __xdp_return+0x6c/0x210[1136314.492863]  bpf_xdp_adjust_tail+0x155/0x1d0[1136314.501269]  bpf_prog_ccc47ae29d3b6570_xdp_sock_prog+0x15/0x60[1136314.511263]  ice_clean_rx_irq_zc+0x206/0xc60 [ice][1136314.520222]  ? ice_xmit_zc+0x6e/0x150 [ice][1136314.528506]  ice_napi_poll+0x467/0x670 [ice][1136314.536858]  ? ttwu_do_activate.constprop.0+0x8f/0x1a0[1136314.546010]  __napi_poll+0x29/0x1b0[1136314.553462]  net_rx_action+0x133/0x270[1136314.561619]  __do_softirq+0xbe/0x28e[1136314.569303]  do_softirq+0x3f/0x60This comes from __xdp_return() call with xdp_buff argument passed asNULL which is supposed to be consumed by xsk_buff_free() call.To address this properly, in ZC case, a node that represents the fragbeing removed has to be pulled out of xskb_list. Introduceappropriate xsk helpers to do such node operation and use themaccordingly within bpf_xdp_adjust_tail().
CVE-2024-26612: In the Linux kernel, the following vulnerability has been resolved:netfs, fscache: Prevent Oops in fscache_put_cache()This function dereferences "cache" and then checks if it'sIS_ERR_OR_NULL().  Check first, then dereference.
Key phrases: oops
CVE-2024-26615: In the Linux kernel, the following vulnerability has been resolved:net/smc: fix illegal rmb_desc access in SMC-D connection dumpA crash was found when dumping SMC-D connections. It can be reproducedby following steps:- run nginx/wrk test:  smc_run nginx  smc_run wrk -t 16 -c 1000 -d <duration> -H 'Connection: Close' <URL>- continuously dump SMC-D connections in parallel:  watch -n 1 'smcss -D' BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G	E      6.7.0+ #55 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag] Call Trace:  <TASK>  ? __die+0x24/0x70  ? page_fault_oops+0x66/0x150  ? exc_page_fault+0x69/0x140  ? asm_exc_page_fault+0x26/0x30  ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]  ? __kmalloc_node_track_caller+0x35d/0x430  ? __alloc_skb+0x77/0x170  smc_diag_dump_proto+0xd0/0xf0 [smc_diag]  smc_diag_dump+0x26/0x60 [smc_diag]  netlink_dump+0x19f/0x320  __netlink_dump_start+0x1dc/0x300  smc_diag_handler_dump+0x6a/0x80 [smc_diag]  ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]  sock_diag_rcv_msg+0x121/0x140  ? __pfx_sock_diag_rcv_msg+0x10/0x10  netlink_rcv_skb+0x5a/0x110  sock_diag_rcv+0x28/0x40  netlink_unicast+0x22a/0x330  netlink_sendmsg+0x1f8/0x420  __sock_sendmsg+0xb0/0xc0  ____sys_sendmsg+0x24e/0x300  ? copy_msghdr_from_user+0x62/0x80  ___sys_sendmsg+0x7c/0xd0  ? __do_fault+0x34/0x160  ? do_read_fault+0x5f/0x100  ? do_fault+0xb0/0x110  ? __handle_mm_fault+0x2b0/0x6c0  __sys_sendmsg+0x4d/0x80  do_syscall_64+0x69/0x180  entry_SYSCALL_64_after_hwframe+0x6e/0x76It is possible that the connection is in process of being establishedwhen we dump it. Assumed that the connection has been registered in alink group by smc_conn_create() but the rmb_desc has not yet beeninitialized by smc_buf_create(), thus causing the illegal access toconn->rmb_desc. So fix it by checking before dump.
Key phrases: crash
CVE-2024-26617: In the Linux kernel, the following vulnerability has been resolved:fs/proc/task_mmu: move mmu notification mechanism inside mm lockMove mmu notification mechanism inside mm lock to prevent race conditionin other components which depend on it.  The notifier will invalidatememory range.  Depending upon the number of iterations, different memoryranges would be invalidated.The following warning would be removed by this patch:WARNING: CPU: 0 PID: 5067 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:734 kvm_mmu_notifier_change_pte+0x860/0x960 arch/x86/kvm/../../../virt/kvm/kvm_main.c:734There is no behavioural and performance change with this patch whenthere is no component registered with the mmu notifier.[akpm@linux-foundation.org: narrow the scope of `range', per Sean]
Key phrases: race conditionin, performance change
CVE-2024-26618: In the Linux kernel, the following vulnerability has been resolved:arm64/sme: Always exit sme_alloc() early with existing storageWhen sme_alloc() is called with existing storage and we are not flushing wewill always allocate new storage, both leaking the existing storage andcorrupting the state. Fix this by separating the checks for flushing andfor existing storage as we do for SVE.Callers that reallocate (eg, due to changing the vector length) shouldcall sme_free() themselves.
Key phrases: sme
CVE-2024-26619: In the Linux kernel, the following vulnerability has been resolved:riscv: Fix module loading free orderReverse order of kfree calls to resolve use-after-free error.
Key phrases: riscv, use-after-free error, use after free
CVE-2024-26620: In the Linux kernel, the following vulnerability has been resolved:s390/vfio-ap: always filter entire AP matrixThe vfio_ap_mdev_filter_matrix function is called whenever a new adapter ordomain is assigned to the mdev. The purpose of the function is to updatethe guest's AP configuration by filtering the matrix of adapters anddomains assigned to the mdev. When an adapter or domain is assigned, onlythe APQNs associated with the APID of the new adapter or APQI of the newdomain are inspected. If an APQN does not reference a queue device bound tothe vfio_ap device driver, then it's APID will be filtered from the mdev'smatrix when updating the guest's AP configuration.Inspecting only the APID of the new adapter or APQI of the new domain willresult in passing AP queues through to a guest that are not bound to thevfio_ap device driver under certain circumstances. Consider the following:guest's AP configuration (all also assigned to the mdev's matrix):14.000414.000514.000616.000416.000516.0006unassign domain 4unbind queue 16.0005assign domain 4When domain 4 is re-assigned, since only domain 4 will be inspected, theAPQNs that will be examined will be:14.000416.0004Since both of those APQNs reference queue devices that are bound to thevfio_ap device driver, nothing will get filtered from the mdev's matrixwhen updating the guest's AP configuration. Consequently, queue 16.0005will get passed through despite not being bound to the driver. Thisviolates the linux device model requirement that a guest shall only begiven access to devices bound to the device driver facilitating theirpass-through.To resolve this problem, every adapter and domain assigned to the mdev willbe inspected when filtering the mdev's matrix.
CVE-2024-26621: In the Linux kernel, the following vulnerability has been resolved:mm: huge_memory: don't force huge page alignment on 32 bitcommit efa7df3e3bb5 ("mm: align larger anonymous mappings on THPboundaries") caused two issues [1] [2] reported on 32 bit system or compatuserspace.It doesn't make too much sense to force huge page alignment on 32 bitsystem due to the constrained virtual address space.[1] https://lore.kernel.org/linux-mm/d0a136a0-4a31-46bc-adf4-2db109a61672@kernel.org/[2] https://lore.kernel.org/linux-mm/CAJuCfpHXLdQy1a2B6xN2d7quTYwg2OoZseYPZTRpU0eHHKD-sQ@mail.gmail.com/
CVE-2024-26622: In the Linux kernel, the following vulnerability has been resolved:tomoyo: fix UAF write bug in tomoyo_write_control()Since tomoyo_write_control() updates head->write_buf when write()of long lines is requested, we need to fetch head->write_buf afterhead->io_sem is held.  Otherwise, concurrent write() requests cancause use-after-free-write and double-free problems.
Key phrases: uaf write bug, use-after-free-write, use after free, double free
CVE-2024-26623: In the Linux kernel, the following vulnerability has been resolved:pds_core: Prevent race issues involving the adminqThere are multiple paths that can result in using the pdsc'sadminq.[1] pdsc_adminq_isr and the resulting work from queue_work(),    i.e. pdsc_work_thread()->pdsc_process_adminq()[2] pdsc_adminq_post()When the device goes through reset via PCIe reset and/ora fw_down/fw_up cycle due to bad PCIe state or bad devicestate the adminq is destroyed and recreated.A NULL pointer dereference can happen if [1] or [2] happensafter the adminq is already destroyed.In order to fix this, add some further state checks andimplement reference counting for adminq uses. Referencecounting was used because multiple threads can attempt toaccess the adminq at the same time via [1] or [2]. Additionally,multiple clients (i.e. pds-vfio-pci) can be using [2]at the same time.The adminq_refcnt is initialized to 1 when the adminq has beenallocated and is ready to use. Users/clients of the adminq(i.e. [1] and [2]) will increment the refcnt when they are usingthe adminq. When the driver goes into a fw_down cycle it willset the PDSC_S_FW_DEAD bit and then wait for the adminq_refcntto hit 1. Setting the PDSC_S_FW_DEAD before waiting will preventany further adminq_refcnt increments. Waiting for theadminq_refcnt to hit 1 allows for any current users of the adminqto finish before the driver frees the adminq. Once theadminq_refcnt hits 1 the driver clears the refcnt to signify thatthe adminq is deleted and cannot be used. On the fw_up cycle thedriver will once again initialize the adminq_refcnt to 1 allowingthe adminq to be used again.
Key phrases: signify thatthe adminq is deleted and cannot, null pointer dereference
CVE-2024-26627: In the Linux kernel, the following vulnerability has been resolved:scsi: core: Move scsi_host_busy() out of host lock for waking up EH handlerInside scsi_eh_wakeup(), scsi_host_busy() is called & checked with hostlock every time for deciding if error handler kthread needs to be waken up.This can be too heavy in case of recovery, such as: - N hardware queues - queue depth is M for each hardware queue - each scsi_host_busy() iterates over (N * M) tag/requestsIf recovery is triggered in case that all requests are in-flight, eachscsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is calledfor the last in-flight request, scsi_host_busy() has been run for (N * M -1) times, and request has been iterated for (N*M - 1) * (N * M) times.If both N and M are big enough, hard lockup can be triggered on acquiringhost lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).Fix the issue by calling scsi_host_busy() outside the host lock. We don'tneed the host lock for getting busy count because host the lock nevercovers that.[mkp: Drop unnecessary 'busy' variables pointed out by Bart]
CVE-2024-26629: In the Linux kernel, the following vulnerability has been resolved:nfsd: fix RELEASE_LOCKOWNERThe test on so_count in nfsd4_release_lockowner() is nonsense andharmful.  Revert to using check_for_locks(), changing that to not sleep.First: harmful.As is documented in the kdoc comment for nfsd4_release_lockowner(), thetest on so_count can transiently return a false positive resulting in areturn of NFS4ERR_LOCKS_HELD when in fact no locks are held.  This isclearly a protocol violation and with the Linux NFS client it can causeincorrect behaviour.If RELEASE_LOCKOWNER is sent while some other thread is stillprocessing a LOCK request which failed because, at the time that requestwas received, the given owner held a conflicting lock, then the nfsdthread processing that LOCK request can hold a reference (conflock) tothe lock owner that causes nfsd4_release_lockowner() to return anincorrect error.The Linux NFS client ignores that NFS4ERR_LOCKS_HELD error because itnever sends NFS4_RELEASE_LOCKOWNER without first releasing any locks, soit knows that the error is impossible.  It assumes the lock owner was infact released so it feels free to use the same lock owner identifier insome later locking request.When it does reuse a lock owner identifier for which a previous RELEASEfailed, it will naturally use a lock_seqid of zero.  However the server,which didn't release the lock owner, will expect a larger lock_seqid andso will respond with NFS4ERR_BAD_SEQID.So clearly it is harmful to allow a false positive, which testingso_count allows.The test is nonsense because ... well... it doesn't mean anything.so_count is the sum of three different counts.1/ the set of states listed on so_stateids2/ the set of active vfs locks owned by any of those states3/ various transient counts such as for conflicting locks.When it is tested against '2' it is clear that one of these is thetransient reference obtained by find_lockowner_str_locked().  It is notclear what the other one is expected to be.In practice, the count is often 2 because there is precisely one stateon so_stateids.  If there were more, this would fail.In my testing I see two circumstances when RELEASE_LOCKOWNER is called.In one case, CLOSE is called before RELEASE_LOCKOWNER.  That results inall the lock states being removed, and so the lockowner being discarded(it is removed when there are no more references which usually happenswhen the lock state is discarded).  When nfsd4_release_lockowner() findsthat the lock owner doesn't exist, it returns success.The other case shows an so_count of '2' and precisely one state listedin so_stateid.  It appears that the Linux client uses a separate lockowner for each file resulting in one lock state per lock owner, so thistest on '2' is safe.  For another client it might not be safe.So this patch changes check_for_locks() to use the (newish)find_any_file_locked() so that it doesn't take a reference on thenfs4_file and so never calls nfsd_file_put(), and so never sleeps.  Withthis check is it safe to restore the use of check_for_locks() ratherthan testing so_count against the mysterious '2'.
Key phrases: be, protocol violation
CVE-2024-26630: In the Linux kernel, the following vulnerability has been resolved:mm: cachestat: fix folio read-after-free in cache walkIn cachestat, we access the folio from the page cache's xarray to computeits page offset, and check for its dirty and writeback flags.  However, wedo not hold a reference to the folio before performing these actions,which means the folio can concurrently be released and reused as anotherfolio/page/slab.Get around this altogether by just using xarray's existing machinery forthe folio page offsets and dirty/writeback states.This changes behavior for tmpfs files to now always report zeroes in theirdirty and writeback counters.  This is okay as tmpfs doesn't followconventional writeback cache behavior: its pages get "cleaned" duringswapout, after which they're no longer resident etc.
Key phrases: folio read-after-free
CVE-2024-26631: In the Linux kernel, the following vulnerability has been resolved:ipv6: mcast: fix data-race in ipv6_mc_down / mld_ifc_workidev->mc_ifc_count can be written over without proper locking.Originally found by syzbot [1], fix this issue by encapsulating callsto mld_ifc_stop_work() (and mld_gq_stop_work() for good measure) withmutex_lock() and mutex_unlock() accordingly as these functionsshould only be called with mc_lock per their declarations.[1]BUG: KCSAN: data-race in ipv6_mc_down / mld_ifc_workwrite to 0xffff88813a80c832 of 1 bytes by task 3771 on cpu 0: mld_ifc_stop_work net/ipv6/mcast.c:1080 [inline] ipv6_mc_down+0x10a/0x280 net/ipv6/mcast.c:2725 addrconf_ifdown+0xe32/0xf10 net/ipv6/addrconf.c:3949 addrconf_notify+0x310/0x980 notifier_call_chain kernel/notifier.c:93 [inline] raw_notifier_call_chain+0x6b/0x1c0 kernel/notifier.c:461 __dev_notify_flags+0x205/0x3d0 dev_change_flags+0xab/0xd0 net/core/dev.c:8685 do_setlink+0x9f6/0x2430 net/core/rtnetlink.c:2916 rtnl_group_changelink net/core/rtnetlink.c:3458 [inline] __rtnl_newlink net/core/rtnetlink.c:3717 [inline] rtnl_newlink+0xbb3/0x1670 net/core/rtnetlink.c:3754 rtnetlink_rcv_msg+0x807/0x8c0 net/core/rtnetlink.c:6558 netlink_rcv_skb+0x126/0x220 net/netlink/af_netlink.c:2545 rtnetlink_rcv+0x1c/0x20 net/core/rtnetlink.c:6576 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline] netlink_unicast+0x589/0x650 net/netlink/af_netlink.c:1368 netlink_sendmsg+0x66e/0x770 net/netlink/af_netlink.c:1910 ...write to 0xffff88813a80c832 of 1 bytes by task 22 on cpu 1: mld_ifc_work+0x54c/0x7b0 net/ipv6/mcast.c:2653 process_one_work kernel/workqueue.c:2627 [inline] process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2700 worker_thread+0x525/0x730 kernel/workqueue.c:2781 ...
CVE-2024-26632: In the Linux kernel, the following vulnerability has been resolved:block: Fix iterating over an empty bio with bio_for_each_folio_allIf the bio contains no data, bio_first_folio() calls page_folio() on aNULL pointer and oopses.  Move the test that we've reached the end ofthe bio from bio_next_folio() to bio_first_folio().[axboe: add unlikely() to error case]
CVE-2024-26634: In the Linux kernel, the following vulnerability has been resolved:net: fix removing a namespace with conflicting altnamesMark reports a BUG() when a net namespace is removed.    kernel BUG at net/core/dev.c:11520!Physical interfaces moved outside of init_net get "refunded"to init_net when that namespace disappears. The main interfacename may get overwritten in the process if it would haveconflicted. We need to also discard all conflicting altnames.Recent fixes addressed ensuring that altnames get movedwith the main interface, which surfaced this problem.