Linux-stable-mirror

linux-stable-mirror@lists.linaro.org

83 participants
123770 discussions

by Harshit Mogalapalli

Hi stable maintainers, I have tried backporting some fixes to stable kernel 6.12.y which also have CVE numbers and are fixing commits in 6.12.y. I am not a subsystem expert and have only done overall testing that we do for stable release candidate testing and not any patch specific testing. Note: All these patches are present backports from upstream. PATCH 1: The broken commit is in 6.12.y, and the fix is a clean cherry-pick and addresses CVE-2025-68206 PATCH 2: The broken commit is present in 6.12.y and the fix is a clean cherry-pick and addresses CVE-2025-40325. PATCH 3: The broken commit is present in 6.12.y and backport needed a minor conflict resolution due to missing commit fe69a3918084 ("drm/panthor: Fix UAF in panthor_gem_create_with_handle() debugfs in 6.12.y PATCH 4,5,6: Patch 4 and 5 are pulled in as prerequisites for PATCH 6 which is a fix for CVE-2025-40170 and needed a minor conflict resolution due to missing commit: 22d6c9eebf2e ("net: Unexport shared functions for DCCP.") in 6.12.y PATCH 7: The broken commit in present in 6.12.y and the backport of the fix needed a minor conflict resolution due to missing commit in 6.12.y. This is fix for CVE-2025-40164. Please let me know if there are any comments. Regards, Harshit Andrii Melnychenko (1): netfilter: nft_ct: add seqadj extension for natted connections Boris Brezillon (1): drm/panthor: Flush shmem writes before mapping buffers CPU-uncached Eric Dumazet (2): ipv6: adopt dst_dev() helper net: use dst_dev_rcu() in sk_setup_caps() Justin Iurman (1): net: ipv6: ioam6: use consistent dst names Xiao Ni (1): md/raid10: wait barrier before returning discard request with REQ_NOWAIT Zqiang (1): usbnet: Fix using smp_processor_id() in preemptible code warnings drivers/gpu/drm/panthor/panthor_gem.c | 18 +++++++++++++ drivers/md/raid10.c | 3 +-- drivers/net/usb/usbnet.c | 2 ++ include/net/ip.h | 6 +++-- include/net/ip6_route.h | 4 +-- include/net/route.h | 2 +- net/core/sock.c | 16 +++++++----- net/ipv6/exthdrs.c | 2 +- net/ipv6/icmp.c | 4 ++- net/ipv6/ila/ila_lwt.c | 2 +- net/ipv6/ioam6_iptunnel.c | 37 ++++++++++++++------------- net/ipv6/ip6_gre.c | 8 +++--- net/ipv6/ip6_output.c | 19 +++++++------- net/ipv6/ip6_tunnel.c | 4 +-- net/ipv6/ip6_udp_tunnel.c | 2 +- net/ipv6/ip6_vti.c | 2 +- net/ipv6/ndisc.c | 6 +++-- net/ipv6/netfilter/nf_dup_ipv6.c | 2 +- net/ipv6/output_core.c | 2 +- net/ipv6/route.c | 20 +++++++++------ net/ipv6/rpl_iptunnel.c | 4 +-- net/ipv6/seg6_iptunnel.c | 20 ++++++++------- net/ipv6/seg6_local.c | 2 +- net/netfilter/nft_ct.c | 5 ++++ 24 files changed, 118 insertions(+), 74 deletions(-) -- 2.50.1

2 days, 5 hours

[PATCH v3 0/3] Address page fault in ima_restore_measurement_list()

by Harshit Mogalapalli

On x86_64: When the second-stage kernel is booted via kexec with a limiting command line such as "mem=<size>" we observe a pafe fault that happens. BUG: unable to handle page fault for address: ffff97793ff47000 RIP: ima_restore_measurement_list+0xdc/0x45a #PF: error_code(0x0000) – not-present page This happens on x86_64 only, as this is already fixed in aarch64 in commit: cbf9c4b9617b ("of: check previous kernel's ima-kexec-buffer against memory bounds") V1: https://lore.kernel.org/all/20251112193005.3772542-1-harshit.m.mogalapalli@… V1 attempted to do a similar sanity check in x86_64. Borislav suggested to add a generic helper ima_validate_range() which could then be used for both OF based and x86_64. Testing information: -------------------- On x86_64: With latest 6.19-rc2 based, we could reproduce the issue, and patched kernel works fine. (with mem=8G on a 16G memory machine) Thanks to Yifei for finding enabling IMA_KEXEC is the cause. Thanks for the reviews on V1. V1 -> V2: - Patch 1: Add a generic helper "ima_validate_range()" - Patch 2: Use this new helper in drivers/of/kexec.c -> No functional change. - Patch 3: Fix the page fault by doing sanity check with "ima_validate_range()" V2: https://lore.kernel.org/all/20251229081523.622515-1-harshit.m.mogalapalli@o… V2 -> V3: Update subject of Patch 1 to more appropriate one (Suggested by Mimi Zohar) Thanks, Harshit Harshit Mogalapalli (3): ima: verify the previous kernel's IMA buffer lies in addressable RAM of/kexec: refactor ima_get_kexec_buffer() to use ima_validate_range() x86/kexec: Add a sanity check on previous kernel's ima kexec buffer arch/x86/kernel/setup.c | 6 +++++ drivers/of/kexec.c | 15 +++---------- include/linux/ima.h | 1 + security/integrity/ima/ima_kexec.c | 35 ++++++++++++++++++++++++++++++ 4 files changed, 45 insertions(+), 12 deletions(-) -- 2.50.1

2 days, 5 hours

[regression 5.10.y] Libvirt can no longer delete macvtap devices after backport of a6cec0bcd342 ("net: rtnetlink: add bulk delete support flag") to 5.10.y series (Debian 11)

by Salvatore Bonaccorso

Hi all, Roland Schwarzkopf reported to the Debian mailing list a problem which he encountered once updating in Debian from 5.10.244 to 5.10.247. The report is quoted below and found in https://lists.debian.org/debian-kernel/2025/12/msg00223.html Roland did bisect the changes between 5.10.244 to 5.10.247 and found that the issue is introduced with 1550f3673972 ("net: rtnetlink: add bulk delete support flag") which is the backport to the 5.10.y series. On Thu, Dec 18, 2025 at 02:59:55PM +0100, Roland Schwarzkopf wrote: > Hi Salvatore, > > On 12/17/25 20:28, Salvatore Bonaccorso wrote: > > Hi Roland, > > > > I'm CC'ing Ben Hutchings directly as well as he takes care of the > > Debian LTS kernel updates. Idellly we make this as well a proper bug > > for easier tracking. > > > > On Wed, Dec 17, 2025 at 01:35:54PM +0100, Roland Schwarzkopf wrote: > > > Hi there, > > > > > > after upgrading to the latest kernel on Debian 11 > > > (linux-image-5.10.0-37-amd64) I have an issue using libvirt with qemu/kvm > > > virtual machines and macvtap networking. When a machine is shut down, > > > libvirt can not delete the corresponding macvtap device. Thus, starting the > > > machine again is not possible. After manually removing the macvtap device > > > using `ip link delete` the vm can be started again. > > > > > > In the journal the following message is shown: > > > > > > Dec 17 13:19:27 iblis libvirtd[535]: error destroying network device macvtap0: Operation not supported > > > > > > After downgrading the kernel to linux-image-5.10.0-36-amd64, the problem > > > disappears. I tested this on a fresh minimal install of Debian 11 - to > > > exclude that anything else on my production machines is causing this issue. > > > > > > Since the older kernel does not have this issue, I assume this is related to > > > the kernel and not to libvirt? > > > > > > I tried to check for bug reports of the kernel package, but the bug tracker > > > finds no reports and even states that the package does not exist (I used the > > > "Bug reports" link on > > > https://packages.debian.org/bullseye/linux-image-5.10.0-37-amd64). This left > > > me a bit puzzled. Since I don't have experience with the debian bug > > > reporting process, I had no other idea than writing to this list. > > You would need to search for inhttps://bugs.debian.org/src:linux , > > but that said I'm not aware of any bug reports in that direction. > > > > Would you be in the position of bisecting the problem as you can say > > that 5.10.244 is good and 5.10.247 is bad and regressed? If you can do > > that that would involve compiling a couple of kernels to narrow down > > where the problem is introduced: > > > > git clone --single-branch -b linux-5.10.yhttps://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-st… > > cd linux-stable > > git checkout v5.10.244 > > cp /boot/config-$(uname -r) .config > > yes '' | make localmodconfig > > make savedefconfig > > mv defconfig arch/x86/configs/my_defconfig > > > > # test 5.10.244 to ensure this is "good" > > make my_defconfig > > make -j $(nproc) bindeb-pkg > > ... install the resulting .deb package and confirm it successfully boots / problem does not exist > > > > # test 5.10.247 to ensure this is "bad" > > git checkout v5.10.247 > > make my_defconfig > > make -j $(nproc) bindeb-pkg > > ... install the resulting .deb package and confirm it fails to boot / problem exists > > > > With that confirmed, the bisection can start: > > > > git bisect start > > git bisect good v5.10.244 > > git bisect bad v5.10.247 > > > > In each bisection step git checks out a state between the oldest > > known-bad and the newest known-good commit. In each step test using: > > > > make my_defconfig > > make -j $(nproc) bindeb-pkg > > ... install, try to boot / verify if problem exists > > > > and if the problem is hit run: > > > > git bisect bad > > > > and if the problem doesn't trigger run: > > > > git bisect good > > > > . Please pay attention to always select the just built kernel for > > booting, it won't always be the default kernel picked up by grub. > > > > Iterate until git announces to have identified the first bad commit. > > > > Then provide the output of > > > > git bisect log > > > > In the course of the bisection you might have to uninstall previous > > kernels again to not exhaust the disk space in /boot. Also in the end > > uninstall all self-built kernels again. > > I just did my first bisection \o/ (sorry) > > Here are the results: > > git bisect start > # bad: [f964b940099f9982d723d4c77988d4b0dda9c165] Linux 5.10.247 > git bisect bad f964b940099f9982d723d4c77988d4b0dda9c165 > # good: [863b76df7d1e327979946a2d3893479c3275bfa4] Linux 5.10.244 > git bisect good f52ee6ea810273e527a5d319e5f400be8c8424c1 > # good: [dc9fdb7586b90e33c766eac52b6f3d1c9ec365a1] net: usb: lan78xx: Add error handling to lan78xx_init_mac_address > git bisect good dc9fdb7586b90e33c766eac52b6f3d1c9ec365a1 > # bad: [2272d5757ce5d3fb416d9f2497b015678eb85c0d] phy: cadence: cdns-dphy: Enable lower resolutions in dphy > git bisect bad 2272d5757ce5d3fb416d9f2497b015678eb85c0d > # bad: [547539f08b9e3629ce68479889813e58c8087e70] ALSA: usb-audio: fix control pipe direction > git bisect bad 547539f08b9e3629ce68479889813e58c8087e70 > # bad: [3509c748e79435d09e730673c8c100b7f0ebc87c] most: usb: hdm_probe: Fix calling put_device() before device initialization > git bisect bad 3509c748e79435d09e730673c8c100b7f0ebc87c > # bad: [a6ebcafc2f5ff7f0d1ce0c6dc38ac09a16a56ec0] net: add ndo_fdb_del_bulk > git bisect bad a6ebcafc2f5ff7f0d1ce0c6dc38ac09a16a56ec0 > # good: [b8a72692aa42b7dcd179a96b90bc2763ac74576a] hfsplus: fix KMSAN uninit-value issue in __hfsplus_ext_cache_extent() > git bisect good b8a72692aa42b7dcd179a96b90bc2763ac74576a > # good: [2b42a595863556b394bd702d46f4a9d0d2985aaa] m68k: bitops: Fix find_*_bit() signatures > git bisect good 2b42a595863556b394bd702d46f4a9d0d2985aaa > # good: [9d9f7d71d46cff3491a443a3cf452cecf87d51ef] net: rtnetlink: use BIT for flag values > git bisect good 9d9f7d71d46cff3491a443a3cf452cecf87d51ef > # bad: [1550f3673972c5cfba714135f8bf26784e6f2b0f] net: rtnetlink: add bulk delete support flag > git bisect bad 1550f3673972c5cfba714135f8bf26784e6f2b0f > # good: [c8879afa24169e504f78c9ca43a4d0d7397049eb] net: netlink: add NLM_F_BULK delete request modifier > git bisect good c8879afa24169e504f78c9ca43a4d0d7397049eb > # first bad commit: [1550f3673972c5cfba714135f8bf26784e6f2b0f] net: rtnetlink: add bulk delete support flag > > Is there anything else I can do to help? Is there soemthing missing? Roland I think it would be helpful if you can test as well more recent stable series versions to confirm if the issue is present there as well or not, which might indicate a 5.10.y specific backporting problem. #regzbot introduced: 1550f3673972c5cfba714135f8bf26784e6f2b0f Regards, Salvatore

2 days, 5 hours

[PATCH 1/2] writeback: fix 100% CPU usage when dirtytime_expire_interval is 0

by Laveesh Bansal

When vm.dirtytime_expire_seconds is set to 0, wakeup_dirtytime_writeback() schedules delayed work with a delay of 0, causing immediate execution. The function then reschedules itself with 0 delay again, creating an infinite busy loop that causes 100% kworker CPU usage. Fix by: - Only scheduling delayed work in wakeup_dirtytime_writeback() when dirtytime_expire_interval is non-zero - Cancelling the delayed work in dirtytime_interval_handler() when the interval is set to 0 - Adding a guard in start_dirtytime_writeback() for defensive coding Tested by booting kernel in QEMU with virtme-ng: - Before fix: kworker CPU spikes to ~73% - After fix: CPU remains at normal levels - Setting interval back to non-zero correctly resumes writeback Fixes: a2f4870697a5 ("fs: make sure the timestamps for lazytime inodes eventually get written") Cc: stable(a)vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220227 Signed-off-by: Laveesh Bansal <laveeshb(a)laveeshbansal.com> --- fs/fs-writeback.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 6800886c4d10..cd21c74cd0e5 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2492,7 +2492,8 @@ static void wakeup_dirtytime_writeback(struct work_struct *w) wb_wakeup(wb); } rcu_read_unlock(); - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); } static int dirtytime_interval_handler(const struct ctl_table *table, int write, @@ -2501,8 +2502,12 @@ static int dirtytime_interval_handler(const struct ctl_table *table, int write, int ret; ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos); - if (ret == 0 && write) - mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + if (ret == 0 && write) { + if (dirtytime_expire_interval) + mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + else + cancel_delayed_work_sync(&dirtytime_work); + } return ret; } @@ -2519,7 +2524,8 @@ static const struct ctl_table vm_fs_writeback_table[] = { static int __init start_dirtytime_writeback(void) { - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); register_sysctl_init("vm", vm_fs_writeback_table); return 0; } -- 2.43.0

2 days, 5 hours

[PATCH 1/2] writeback: fix 100% CPU usage when dirtytime_expire_interval is 0

by Laveesh Bansal

2 days, 5 hours

[PATCH 1/2] writeback: fix 100% CPU usage when dirtytime_expire_interval is 0

by Laveesh Bansal

From: Laveesh Bansal <laveeshbansal(a)gmail.com> When vm.dirtytime_expire_seconds is set to 0, wakeup_dirtytime_writeback() schedules delayed work with a delay of 0, causing immediate execution. The function then reschedules itself with 0 delay again, creating an infinite busy loop that causes 100% kworker CPU usage. Fix by: - Only scheduling delayed work in wakeup_dirtytime_writeback() when dirtytime_expire_interval is non-zero - Cancelling the delayed work in dirtytime_interval_handler() when the interval is set to 0 - Adding a guard in start_dirtytime_writeback() for defensive coding Tested by booting kernel in QEMU with virtme-ng: - Before fix: kworker CPU spikes to ~73% - After fix: CPU remains at normal levels - Setting interval back to non-zero correctly resumes writeback Fixes: a2f4870697a5 ("fs: make sure the timestamps for lazytime inodes eventually get written") Cc: stable(a)vger.kernel.org Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220227 Signed-off-by: Laveesh Bansal <laveeshbansal(a)gmail.com> --- fs/fs-writeback.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 6800886c4d10..cd21c74cd0e5 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -2492,7 +2492,8 @@ static void wakeup_dirtytime_writeback(struct work_struct *w) wb_wakeup(wb); } rcu_read_unlock(); - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); } static int dirtytime_interval_handler(const struct ctl_table *table, int write, @@ -2501,8 +2502,12 @@ static int dirtytime_interval_handler(const struct ctl_table *table, int write, int ret; ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos); - if (ret == 0 && write) - mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + if (ret == 0 && write) { + if (dirtytime_expire_interval) + mod_delayed_work(system_percpu_wq, &dirtytime_work, 0); + else + cancel_delayed_work_sync(&dirtytime_work); + } return ret; } @@ -2519,7 +2524,8 @@ static const struct ctl_table vm_fs_writeback_table[] = { static int __init start_dirtytime_writeback(void) { - schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); + if (dirtytime_expire_interval) + schedule_delayed_work(&dirtytime_work, dirtytime_expire_interval * HZ); register_sysctl_init("vm", vm_fs_writeback_table); return 0; } -- 2.43.0

2 days, 5 hours

Re: NRF 2026 Retail's Big Show more information

by Amy Giles

Hi, I wanted to see if you had time to review the email I sent earlier. Should you need any other details, don't hesitate to reach out. Best Amy Giles Please reply with REMOVE if you don't wish to receive further emails -----Original Message----- Hi, Hope you're having a great day! Are you looking for leads from NRF 2026 Retail's Big Show? Attendees count: 30,000 Leads Data Fields: Company Name, Web URL, Contact Name, Title, Direct Email, Phone Number, Mailing Address, Industry, Employee Size, Annual Sales. If you're interested in these leads, I'd be glad to share the pricing. Let me know! Thanks for the quick reply. I'm excited to get your thoughts. Best Amy Giles Demand Generation Manager Zoom Connect, Inc Please reply with REMOVE if you don't wish to receive further emails

2 days, 5 hours

[PATCH] cacheinfo: Remove of_node_put() for fw_token

by Petr Malat

fw_token is used for DT/ACPI systems to identify CPUs sharing caches. For DT based systems, fw_token is set to a pointer to a DT node. Commit 22def0b492e6 ("arch_topology: Build cacheinfo from primary CPU") removed clearing of per_cpu_cacheinfo(cpu), which leads to reference underrun in cache_shared_cpu_map_remove() during repeated cpu offline/online as the reference is no longer incremented, because allocate_cache_info() is now skipped in the online path. The same problem existed on upstream but had a different root cause, see 2613cc29c572 ("cacheinfo: Remove of_node_put() for fw_token"). Fixes the following splat: OF: ERROR: Bad of_node_put() on /cpus/l2-cache0 CPU: 3 PID: 29 Comm: cpuhp/3 Tainted: G O 6.1.159-arm64 #1 Hardware name: AXM56xx Victoria (DT) Call trace: dump_backtrace+0xd8/0x12c show_stack+0x1c/0x34 dump_stack_lvl+0x70/0x88 dump_stack+0x14/0x2c of_node_release+0x134/0x138 kobject_put+0xa8/0x21c of_node_put+0x1c/0x28 cache_shared_cpu_map_remove+0x19c/0x220 cacheinfo_cpu_pre_down+0x60/0xa0 cpuhp_invoke_callback+0x140/0x570 cpuhp_thread_fun+0xc8/0x19c smpboot_thread_fn+0x218/0x23c kthread+0x108/0x118 ret_from_fork+0x10/0x20 Fixes: 22def0b492e6 ("arch_topology: Build cacheinfo from primary CPU") Signed-off-by: Petr Malat <oss(a)malat.biz> --- drivers/base/cacheinfo.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/base/cacheinfo.c b/drivers/base/cacheinfo.c index 9e11d42b0d64..b57f64725f25 100644 --- a/drivers/base/cacheinfo.c +++ b/drivers/base/cacheinfo.c @@ -404,8 +404,6 @@ static void cache_shared_cpu_map_remove(unsigned int cpu) } } } - if (of_have_populated_dt()) - of_node_put(this_leaf->fw_token); } /* cpu is no longer populated in the shared map */ -- 2.39.5

2 days, 6 hours

[PATCH v2] arm64: kernel: initialize missing kexec_buf->random field

by Yeoreum Yun

Commit bf454ec31add ("kexec_file: allow to place kexec_buf randomly") introduced the kexec_buf->random field to enable random placement of kexec_buf. However, this field was never properly initialized for kexec images that do not need to be placed randomly, leading to the following UBSAN warning: [ +0.364528] ------------[ cut here ]------------ [ +0.000019] UBSAN: invalid-load in ./include/linux/kexec.h:210:12 [ +0.000131] load of value 2 is not a valid value for type 'bool' (aka '_Bool') [ +0.000003] CPU: 4 UID: 0 PID: 927 Comm: kexec Not tainted 6.18.0-rc7+ #3 PREEMPT(full) [ +0.000002] Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 [ +0.000000] Call trace: [ +0.000001] show_stack+0x24/0x40 (C) [ +0.000006] __dump_stack+0x28/0x48 [ +0.000002] dump_stack_lvl+0x7c/0xb0 [ +0.000002] dump_stack+0x18/0x34 [ +0.000001] ubsan_epilogue+0x10/0x50 [ +0.000002] __ubsan_handle_load_invalid_value+0xc8/0xd0 [ +0.000003] locate_mem_hole_callback+0x28c/0x2a0 [ +0.000003] kexec_locate_mem_hole+0xf4/0x2f0 [ +0.000001] kexec_add_buffer+0xa8/0x178 [ +0.000002] image_load+0xf0/0x258 [ +0.000001] __arm64_sys_kexec_file_load+0x510/0x718 [ +0.000002] invoke_syscall+0x68/0xe8 [ +0.000001] el0_svc_common+0xb0/0xf8 [ +0.000002] do_el0_svc+0x28/0x48 [ +0.000001] el0_svc+0x40/0xe8 [ +0.000002] el0t_64_sync_handler+0x84/0x140 [ +0.000002] el0t_64_sync+0x1bc/0x1c0 To address this, initialise kexec_buf->random field properly. Fixes: bf454ec31add ("kexec_file: allow to place kexec_buf randomly") Suggested-by: Breno Leitao <leitao(a)debian.org> Cc: <stable(a)vger.kernel.org> Signed-off-by: Yeoreum Yun <yeoreum.yun(a)arm.com> --- arch/arm64/kernel/kexec_image.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arm64/kernel/kexec_image.c b/arch/arm64/kernel/kexec_image.c index 532d72ea42ee..b70f4df15a1a 100644 --- a/arch/arm64/kernel/kexec_image.c +++ b/arch/arm64/kernel/kexec_image.c @@ -41,7 +41,7 @@ static void *image_load(struct kimage *image, struct arm64_image_header *h; u64 flags, value; bool be_image, be_kernel; - struct kexec_buf kbuf; + struct kexec_buf kbuf = {}; unsigned long text_offset, kernel_segment_number; struct kexec_segment *kernel_segment; int ret; -- LEVI:{C3F47F37-75D8-414A-A8BA-3980EC8A46D7}

2 days, 6 hours

RE: CES 2026: Audience Breakdown & Leads

by Jessica Garcia

Hi , Just touching base to see if you're available to discuss this further. If you have any uncertainties, I'm happy to help. Regards Jessica Marketing Manager Campaign Data Leads., Please reply with REMOVE if you don't wish to receive further emails -----Original Message----- From: Jessica Garcia Subject: CES 2026: Audience Breakdown & Leads Hi , Trust you're in good spirits. Is the idea of buying the CES 2026 attendees' details for your marketing efforts something you'd like to explore? Expo Name: Consumer Electronics Show 2026 Total Number of records: 40,000 records List includes: Company Name, Contact Name, Job Title, Mailing Address, Phone, Emails, etc. Best chance to connect with participants Feel free to contact me if you are interested in acquiring this list so that I can share pricing information with you Hoping for your prompt feedback. Regards Jessica Marketing Manager Campaign Data Leads., Please reply with REMOVE if you don't wish to receive further emails

2 days, 8 hours

← Newer
1
2
3
4
5
6
7
8
...
12377
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror