| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
| In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject negative offsets for ALU ops
When verifying BPF programs, the check_alu_op() function validates
instructions with ALU operations. The 'offset' field in these
instructions is a signed 16-bit integer.
The existing check 'insn->off > 1' was intended to ensure the offset is
either 0, or 1 for BPF_MOD/BPF_DIV. However, because 'insn->off' is
signed, this check incorrectly accepts all negative values (e.g., -1).
This commit tightens the validation by changing the condition to
'(insn->off != 0 && insn->off != 1)'. This ensures that any value
other than the explicitly permitted 0 and 1 is rejected, hardening the
verifier against malformed BPF programs. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: amd/sdw_utils: avoid NULL deref when devm_kasprintf() fails
devm_kasprintf() may return NULL on memory allocation failure,
but the debug message prints cpus->dai_name before checking it.
Move the dev_dbg() call after the NULL check to prevent potential
NULL pointer dereference. |
| In the Linux kernel, the following vulnerability has been resolved:
ext4: verify orphan file size is not too big
In principle orphan file can be arbitrarily large. However orphan replay
needs to traverse it all and we also pin all its buffers in memory. Thus
filesystems with absurdly large orphan files can lead to big amounts of
memory consumed. Limit orphan file size to a sane value and also use
kvmalloc() for allocating array of block descriptor structures to avoid
large order allocations for sane but large orphan files. |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not assert we found block group item when creating free space tree
Currently, when building a free space tree at populate_free_space_tree(),
if we are not using the block group tree feature, we always expect to find
block group items (either extent items or a block group item with key type
BTRFS_BLOCK_GROUP_ITEM_KEY) when we search the extent tree with
btrfs_search_slot_for_read(), so we assert that we found an item. However
this expectation is wrong since we can have a new block group created in
the current transaction which is still empty and for which we still have
not added the block group's item to the extent tree, in which case we do
not have any items in the extent tree associated to the block group.
The insertion of a new block group's block group item in the extent tree
happens at btrfs_create_pending_block_groups() when it calls the helper
insert_block_group_item(). This typically is done when a transaction
handle is released, committed or when running delayed refs (either as
part of a transaction commit or when serving tickets for space reservation
if we are low on free space).
So remove the assertion at populate_free_space_tree() even when the block
group tree feature is not enabled and update the comment to mention this
case.
Syzbot reported this with the following stack trace:
BTRFS info (device loop3 state M): rebuilding free space tree
assertion failed: ret == 0 :: 0, in fs/btrfs/free-space-tree.c:1115
------------[ cut here ]------------
kernel BUG at fs/btrfs/free-space-tree.c:1115!
Oops: invalid opcode: 0000 [#1] SMP KASAN PTI
CPU: 1 UID: 0 PID: 6352 Comm: syz.3.25 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/18/2025
RIP: 0010:populate_free_space_tree+0x700/0x710 fs/btrfs/free-space-tree.c:1115
Code: ff ff e8 d3 (...)
RSP: 0018:ffffc9000430f780 EFLAGS: 00010246
RAX: 0000000000000043 RBX: ffff88805b709630 RCX: fea61d0e2e79d000
RDX: 0000000000000000 RSI: 0000000080000000 RDI: 0000000000000000
RBP: ffffc9000430f8b0 R08: ffffc9000430f4a7 R09: 1ffff92000861e94
R10: dffffc0000000000 R11: fffff52000861e95 R12: 0000000000000001
R13: 1ffff92000861f00 R14: dffffc0000000000 R15: 0000000000000000
FS: 00007f424d9fe6c0(0000) GS:ffff888125afc000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fd78ad212c0 CR3: 0000000076d68000 CR4: 00000000003526f0
Call Trace:
<TASK>
btrfs_rebuild_free_space_tree+0x1ba/0x6d0 fs/btrfs/free-space-tree.c:1364
btrfs_start_pre_rw_mount+0x128f/0x1bf0 fs/btrfs/disk-io.c:3062
btrfs_remount_rw fs/btrfs/super.c:1334 [inline]
btrfs_reconfigure+0xaed/0x2160 fs/btrfs/super.c:1559
reconfigure_super+0x227/0x890 fs/super.c:1076
do_remount fs/namespace.c:3279 [inline]
path_mount+0xd1a/0xfe0 fs/namespace.c:4027
do_mount fs/namespace.c:4048 [inline]
__do_sys_mount fs/namespace.c:4236 [inline]
__se_sys_mount+0x313/0x410 fs/namespace.c:4213
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0xfa/0xfa0 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f424e39066a
Code: d8 64 89 02 (...)
RSP: 002b:00007f424d9fde68 EFLAGS: 00000246 ORIG_RAX: 00000000000000a5
RAX: ffffffffffffffda RBX: 00007f424d9fdef0 RCX: 00007f424e39066a
RDX: 0000200000000180 RSI: 0000200000000380 RDI: 0000000000000000
RBP: 0000200000000180 R08: 00007f424d9fdef0 R09: 0000000000000020
R10: 0000000000000020 R11: 0000000000000246 R12: 0000200000000380
R13: 00007f424d9fdeb0 R14: 0000000000000000 R15: 00002000000002c0
</TASK>
Modules linked in:
---[ end trace 0000000000000000 ]--- |
| In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: use dst_dev_net_rcu()
Replace three dst_dev() with a lockdep enabled helper. |
| In the Linux kernel, the following vulnerability has been resolved:
ptp: Add a upper bound on max_vclocks
syzbot reported WARNING in max_vclocks_store.
This occurs when the argument max is too large for kcalloc to handle.
Extend the guard to guard against values that are too large for
kcalloc |
| In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix crypto buffers in non-linear memory
The crypto API, through the scatterlist API, expects input buffers to be
in linear memory. We handle this with the cifs_sg_set_buf() helper
that converts vmalloc'd memory to their corresponding pages.
However, when we allocate our aead_request buffer (@creq in
smb2ops.c::crypt_message()), we do so with kvzalloc(), which possibly
puts aead_request->__ctx in vmalloc area.
AEAD algorithm then uses ->__ctx for its private/internal data and
operations, and uses sg_set_buf() for such data on a few places.
This works fine as long as @creq falls into kmalloc zone (small
requests) or vmalloc'd memory is still within linear range.
Tasks' stacks are vmalloc'd by default (CONFIG_VMAP_STACK=y), so too
many tasks will increment the base stacks' addresses to a point where
virt_addr_valid(buf) will fail (BUG() in sg_set_buf()) when that
happens.
In practice: too many parallel reads and writes on an encrypted mount
will trigger this bug.
To fix this, always alloc @creq with kmalloc() instead.
Also drop the @sensitive_size variable/arguments since
kfree_sensitive() doesn't need it.
Backtrace:
[ 945.272081] ------------[ cut here ]------------
[ 945.272774] kernel BUG at include/linux/scatterlist.h:209!
[ 945.273520] Oops: invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC NOPTI
[ 945.274412] CPU: 7 UID: 0 PID: 56 Comm: kworker/u33:0 Kdump: loaded Not tainted 6.15.0-lku-11779-g8e9d6efccdd7-dirty #1 PREEMPT(voluntary)
[ 945.275736] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-2-gc13ff2cd-prebuilt.qemu.org 04/01/2014
[ 945.276877] Workqueue: writeback wb_workfn (flush-cifs-2)
[ 945.277457] RIP: 0010:crypto_gcm_init_common+0x1f9/0x220
[ 945.278018] Code: b0 00 00 00 48 83 c4 08 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 48 c7 c0 00 00 00 80 48 2b 05 5c 58 e5 00 e9 58 ff ff ff <0f> 0b 0f 0b 0f 0b 0f 0b 0f 0b 0f 0b 48 c7 04 24 01 00 00 00 48 8b
[ 945.279992] RSP: 0018:ffffc90000a27360 EFLAGS: 00010246
[ 945.280578] RAX: 0000000000000000 RBX: ffffc90001d85060 RCX: 0000000000000030
[ 945.281376] RDX: 0000000000080000 RSI: 0000000000000000 RDI: ffffc90081d85070
[ 945.282145] RBP: ffffc90001d85010 R08: ffffc90001d85000 R09: 0000000000000000
[ 945.282898] R10: ffffc90001d85090 R11: 0000000000001000 R12: ffffc90001d85070
[ 945.283656] R13: ffff888113522948 R14: ffffc90001d85060 R15: ffffc90001d85010
[ 945.284407] FS: 0000000000000000(0000) GS:ffff8882e66cf000(0000) knlGS:0000000000000000
[ 945.285262] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 945.285884] CR2: 00007fa7ffdd31f4 CR3: 000000010540d000 CR4: 0000000000350ef0
[ 945.286683] Call Trace:
[ 945.286952] <TASK>
[ 945.287184] ? crypt_message+0x33f/0xad0 [cifs]
[ 945.287719] crypto_gcm_encrypt+0x36/0xe0
[ 945.288152] crypt_message+0x54a/0xad0 [cifs]
[ 945.288724] smb3_init_transform_rq+0x277/0x300 [cifs]
[ 945.289300] smb_send_rqst+0xa3/0x160 [cifs]
[ 945.289944] cifs_call_async+0x178/0x340 [cifs]
[ 945.290514] ? __pfx_smb2_writev_callback+0x10/0x10 [cifs]
[ 945.291177] smb2_async_writev+0x3e3/0x670 [cifs]
[ 945.291759] ? find_held_lock+0x32/0x90
[ 945.292212] ? netfs_advance_write+0xf2/0x310
[ 945.292723] netfs_advance_write+0xf2/0x310
[ 945.293210] netfs_write_folio+0x346/0xcc0
[ 945.293689] ? __pfx__raw_spin_unlock_irq+0x10/0x10
[ 945.294250] netfs_writepages+0x117/0x460
[ 945.294724] do_writepages+0xbe/0x170
[ 945.295152] ? find_held_lock+0x32/0x90
[ 945.295600] ? kvm_sched_clock_read+0x11/0x20
[ 945.296103] __writeback_single_inode+0x56/0x4b0
[ 945.296643] writeback_sb_inodes+0x229/0x550
[ 945.297140] __writeback_inodes_wb+0x4c/0xe0
[ 945.297642] wb_writeback+0x2f1/0x3f0
[ 945.298069] wb_workfn+0x300/0x490
[ 945.298472] process_one_work+0x1fe/0x590
[ 945.298949] worker_thread+0x1ce/0x3c0
[ 945.299397] ? __pfx_worker_thread+0x10/0x10
[ 945.299900] kthr
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/waitid: always prune wait queue entry in io_waitid_wait()
For a successful return, always remove our entry from the wait queue
entry list. Previously this was skipped if a cancelation was in
progress, but this can race with another invocation of the wait queue
entry callback. |
| In the Linux kernel, the following vulnerability has been resolved:
fbdev: simplefb: Fix use after free in simplefb_detach_genpds()
The pm_domain cleanup can not be devres managed as it uses struct
simplefb_par which is allocated within struct fb_info by
framebuffer_alloc(). This allocation is explicitly freed by
unregister_framebuffer() in simplefb_remove().
Devres managed cleanup runs after the device remove call and thus can no
longer access struct simplefb_par.
Call simplefb_detach_genpds() explicitly from simplefb_destroy() like
the cleanup functions for clocks and regulators.
Fixes an use after free on M2 Mac mini during
aperture_remove_conflicting_devices() using the downstream asahi kernel
with Debian's kernel config. For unknown reasons this started to
consistently dereference an invalid pointer in v6.16.3 based kernels.
[ 6.736134] BUG: KASAN: slab-use-after-free in simplefb_detach_genpds+0x58/0x220
[ 6.743545] Read of size 4 at addr ffff8000304743f0 by task (udev-worker)/227
[ 6.750697]
[ 6.752182] CPU: 6 UID: 0 PID: 227 Comm: (udev-worker) Tainted: G S 6.16.3-asahi+ #16 PREEMPTLAZY
[ 6.752186] Tainted: [S]=CPU_OUT_OF_SPEC
[ 6.752187] Hardware name: Apple Mac mini (M2, 2023) (DT)
[ 6.752189] Call trace:
[ 6.752190] show_stack+0x34/0x98 (C)
[ 6.752194] dump_stack_lvl+0x60/0x80
[ 6.752197] print_report+0x17c/0x4d8
[ 6.752201] kasan_report+0xb4/0x100
[ 6.752206] __asan_report_load4_noabort+0x20/0x30
[ 6.752209] simplefb_detach_genpds+0x58/0x220
[ 6.752213] devm_action_release+0x50/0x98
[ 6.752216] release_nodes+0xd0/0x2c8
[ 6.752219] devres_release_all+0xfc/0x178
[ 6.752221] device_unbind_cleanup+0x28/0x168
[ 6.752224] device_release_driver_internal+0x34c/0x470
[ 6.752228] device_release_driver+0x20/0x38
[ 6.752231] bus_remove_device+0x1b0/0x380
[ 6.752234] device_del+0x314/0x820
[ 6.752238] platform_device_del+0x3c/0x1e8
[ 6.752242] platform_device_unregister+0x20/0x50
[ 6.752246] aperture_detach_platform_device+0x1c/0x30
[ 6.752250] aperture_detach_devices+0x16c/0x290
[ 6.752253] aperture_remove_conflicting_devices+0x34/0x50
...
[ 6.752343]
[ 6.967409] Allocated by task 62:
[ 6.970724] kasan_save_stack+0x3c/0x70
[ 6.974560] kasan_save_track+0x20/0x40
[ 6.978397] kasan_save_alloc_info+0x40/0x58
[ 6.982670] __kasan_kmalloc+0xd4/0xd8
[ 6.986420] __kmalloc_noprof+0x194/0x540
[ 6.990432] framebuffer_alloc+0xc8/0x130
[ 6.994444] simplefb_probe+0x258/0x2378
...
[ 7.054356]
[ 7.055838] Freed by task 227:
[ 7.058891] kasan_save_stack+0x3c/0x70
[ 7.062727] kasan_save_track+0x20/0x40
[ 7.066565] kasan_save_free_info+0x4c/0x80
[ 7.070751] __kasan_slab_free+0x6c/0xa0
[ 7.074675] kfree+0x10c/0x380
[ 7.077727] framebuffer_release+0x5c/0x90
[ 7.081826] simplefb_destroy+0x1b4/0x2c0
[ 7.085837] put_fb_info+0x98/0x100
[ 7.089326] unregister_framebuffer+0x178/0x320
[ 7.093861] simplefb_remove+0x3c/0x60
[ 7.097611] platform_remove+0x60/0x98
[ 7.101361] device_remove+0xb8/0x160
[ 7.105024] device_release_driver_internal+0x2fc/0x470
[ 7.110256] device_release_driver+0x20/0x38
[ 7.114529] bus_remove_device+0x1b0/0x380
[ 7.118628] device_del+0x314/0x820
[ 7.122116] platform_device_del+0x3c/0x1e8
[ 7.126302] platform_device_unregister+0x20/0x50
[ 7.131012] aperture_detach_platform_device+0x1c/0x30
[ 7.136157] aperture_detach_devices+0x16c/0x290
[ 7.140779] aperture_remove_conflicting_devices+0x34/0x50
... |
| In the Linux kernel, the following vulnerability has been resolved:
io_uring/zcrx: fix overshooting recv limit
It's reported that sometimes a zcrx request can receive more than was
requested. It's caused by io_zcrx_recv_skb() adjusting desc->count for
all received buffers including frag lists, but then doing recursive
calls to process frag list skbs, which leads to desc->count double
accounting and underflow. |
| In the Linux kernel, the following vulnerability has been resolved:
net/9p: Fix buffer overflow in USB transport layer
A buffer overflow vulnerability exists in the USB 9pfs transport layer
where inconsistent size validation between packet header parsing and
actual data copying allows a malicious USB host to overflow heap buffers.
The issue occurs because:
- usb9pfs_rx_header() validates only the declared size in packet header
- usb9pfs_rx_complete() uses req->actual (actual received bytes) for
memcpy
This allows an attacker to craft packets with small declared size
(bypassing validation) but large actual payload (triggering overflow
in memcpy).
Add validation in usb9pfs_rx_complete() to ensure req->actual does not
exceed the buffer capacity before copying data. |
| In the Linux kernel, the following vulnerability has been resolved:
hfs/hfsplus: avoid WARN_ON() for sanity check, use proper error handling
Commit 55d1cbbbb29e ("hfs/hfsplus: use WARN_ON for sanity check") fixed
a build warning by turning a comment into a WARN_ON(), but it turns out
that syzbot then complains because it can trigger said warning with a
corrupted hfs image.
The warning actually does warn about a bad situation, but we are much
better off just handling it as the error it is. So rather than warn
about us doing bad things, stop doing the bad things and return -EIO.
While at it, also fix a memory leak that was introduced by an earlier
fix for a similar syzbot warning situation, and add a check for one case
that historically wasn't handled at all (ie neither comment nor
subsequent WARN_ON). |
| In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: prevent double-free in dbUnmount() after failed jfs_remount()
Syzkaller reported the following issue:
==================================================================
BUG: KASAN: double-free in slab_free mm/slub.c:3787 [inline]
BUG: KASAN: double-free in __kmem_cache_free+0x71/0x110 mm/slub.c:3800
Free of addr ffff888086408000 by task syz-executor.4/12750
[...]
Call Trace:
<TASK>
[...]
kasan_report_invalid_free+0xac/0xd0 mm/kasan/report.c:482
____kasan_slab_free+0xfb/0x120
kasan_slab_free include/linux/kasan.h:177 [inline]
slab_free_hook mm/slub.c:1781 [inline]
slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807
slab_free mm/slub.c:3787 [inline]
__kmem_cache_free+0x71/0x110 mm/slub.c:3800
dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264
jfs_umount+0x248/0x3b0 fs/jfs/jfs_umount.c:87
jfs_put_super+0x86/0x190 fs/jfs/super.c:194
generic_shutdown_super+0x130/0x310 fs/super.c:492
kill_block_super+0x79/0xd0 fs/super.c:1386
deactivate_locked_super+0xa7/0xf0 fs/super.c:332
cleanup_mnt+0x494/0x520 fs/namespace.c:1291
task_work_run+0x243/0x300 kernel/task_work.c:179
resume_user_mode_work include/linux/resume_user_mode.h:49 [inline]
exit_to_user_mode_loop+0x124/0x150 kernel/entry/common.c:171
exit_to_user_mode_prepare+0xb2/0x140 kernel/entry/common.c:203
__syscall_exit_to_user_mode_work kernel/entry/common.c:285 [inline]
syscall_exit_to_user_mode+0x26/0x60 kernel/entry/common.c:296
do_syscall_64+0x49/0xb0 arch/x86/entry/common.c:86
entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]
</TASK>
Allocated by task 13352:
kasan_save_stack mm/kasan/common.c:45 [inline]
kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
____kasan_kmalloc mm/kasan/common.c:371 [inline]
__kasan_kmalloc+0x97/0xb0 mm/kasan/common.c:380
kmalloc include/linux/slab.h:580 [inline]
dbMount+0x54/0x980 fs/jfs/jfs_dmap.c:164
jfs_mount+0x1dd/0x830 fs/jfs/jfs_mount.c:121
jfs_fill_super+0x590/0xc50 fs/jfs/super.c:556
mount_bdev+0x26c/0x3a0 fs/super.c:1359
legacy_get_tree+0xea/0x180 fs/fs_context.c:610
vfs_get_tree+0x88/0x270 fs/super.c:1489
do_new_mount+0x289/0xad0 fs/namespace.c:3145
do_mount fs/namespace.c:3488 [inline]
__do_sys_mount fs/namespace.c:3697 [inline]
__se_sys_mount+0x2d3/0x3c0 fs/namespace.c:3674
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
Freed by task 13352:
kasan_save_stack mm/kasan/common.c:45 [inline]
kasan_set_track+0x3d/0x60 mm/kasan/common.c:52
kasan_save_free_info+0x27/0x40 mm/kasan/generic.c:518
____kasan_slab_free+0xd6/0x120 mm/kasan/common.c:236
kasan_slab_free include/linux/kasan.h:177 [inline]
slab_free_hook mm/slub.c:1781 [inline]
slab_free_freelist_hook+0x12e/0x1a0 mm/slub.c:1807
slab_free mm/slub.c:3787 [inline]
__kmem_cache_free+0x71/0x110 mm/slub.c:3800
dbUnmount+0xf4/0x110 fs/jfs/jfs_dmap.c:264
jfs_mount_rw+0x545/0x740 fs/jfs/jfs_mount.c:247
jfs_remount+0x3db/0x710 fs/jfs/super.c:454
reconfigure_super+0x3bc/0x7b0 fs/super.c:935
vfs_fsconfig_locked fs/fsopen.c:254 [inline]
__do_sys_fsconfig fs/fsopen.c:439 [inline]
__se_sys_fsconfig+0xad5/0x1060 fs/fsopen.c:314
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
[...]
JFS_SBI(ipbmap->i_sb)->bmap wasn't set to NULL after kfree() in
dbUnmount().
Syzkaller uses faultinject to reproduce this KASAN double-free
warning. The issue is triggered if either diMount() or dbMount() fail
in jfs_remount(), since diUnmount() or dbUnmount() already happened in
such a case - they will do double-free on next execution: jfs_umount
or jfs_remount.
Tested on both upstream and jfs-next by syzkaller. |
| In the Linux kernel, the following vulnerability has been resolved:
ubi: Fix possible null-ptr-deref in ubi_free_volume()
It willl cause null-ptr-deref in the following case:
uif_init()
ubi_add_volume()
cdev_add() -> if it fails, call kill_volumes()
device_register()
kill_volumes() -> if ubi_add_volume() fails call this function
ubi_free_volume()
cdev_del()
device_unregister() -> trying to delete a not added device,
it causes null-ptr-deref
So in ubi_free_volume(), it delete devices whether they are added
or not, it will causes null-ptr-deref.
Handle the error case whlie calling ubi_add_volume() to fix this
problem. If add volume fails, set the corresponding vol to null,
so it can not be accessed in kill_volumes() and release the
resource in ubi_add_volume() error path. |
| In the Linux kernel, the following vulnerability has been resolved:
cxl/features: Add check for no entries in cxl_feature_info
cxl EDAC calls cxl_feature_info() to get the feature information and
if the hardware has no Features support, cxlfs may be passed in as
NULL.
[ 51.957498] BUG: kernel NULL pointer dereference, address: 0000000000000008
[ 51.965571] #PF: supervisor read access in kernel mode
[ 51.971559] #PF: error_code(0x0000) - not-present page
[ 51.977542] PGD 17e4f6067 P4D 0
[ 51.981384] Oops: Oops: 0000 [#1] SMP NOPTI
[ 51.986300] CPU: 49 UID: 0 PID: 3782 Comm: systemd-udevd Not tainted 6.17.0dj
test+ #64 PREEMPT(voluntary)
[ 51.997355] Hardware name: <removed>
[ 52.009790] RIP: 0010:cxl_feature_info+0xa/0x80 [cxl_core]
Add a check for cxlfs before dereferencing it and return -EOPNOTSUPP if
there is no cxlfs created due to no hardware support. |
| CLUSTERPRO X for Linux 4.0, 4.1, 4.2, 5.0, 5.1 and 5.2 and EXPRESSCLUSTER X for Linux 4.0, 4.1, 4.2, 5.0, 5.1 and 5.2, CLUSTERPRO X SingleServerSafe for Linux 4.0, 4.1, 4.2, 5.0, 5.1 and 5.2, EXPRESSCLUSTER X SingleServerSafe for Linux 4.0, 4.1, 4.2, 5.0, 5.1 and 5.2 allows an attacker sends specially crafted network packets to the product, arbitrary OS commands may be executed without authentication. |
| In the Linux kernel, the following vulnerability has been resolved:
net: macb: fix a memory corruption in extended buffer descriptor mode
For quite some time we were chasing a bug which looked like a sudden
permanent failure of networking and mmc on some of our devices.
The bug was very sensitive to any software changes and even more to
any kernel debug options.
Finally we got a setup where the problem was reproducible with
CONFIG_DMA_API_DEBUG=y and it revealed the issue with the rx dma:
[ 16.992082] ------------[ cut here ]------------
[ 16.996779] DMA-API: macb ff0b0000.ethernet: device driver tries to free DMA memory it has not allocated [device address=0x0000000875e3e244] [size=1536 bytes]
[ 17.011049] WARNING: CPU: 0 PID: 85 at kernel/dma/debug.c:1011 check_unmap+0x6a0/0x900
[ 17.018977] Modules linked in: xxxxx
[ 17.038823] CPU: 0 PID: 85 Comm: irq/55-8000f000 Not tainted 5.4.0 #28
[ 17.045345] Hardware name: xxxxx
[ 17.049528] pstate: 60000005 (nZCv daif -PAN -UAO)
[ 17.054322] pc : check_unmap+0x6a0/0x900
[ 17.058243] lr : check_unmap+0x6a0/0x900
[ 17.062163] sp : ffffffc010003c40
[ 17.065470] x29: ffffffc010003c40 x28: 000000004000c03c
[ 17.070783] x27: ffffffc010da7048 x26: ffffff8878e38800
[ 17.076095] x25: ffffff8879d22810 x24: ffffffc010003cc8
[ 17.081407] x23: 0000000000000000 x22: ffffffc010a08750
[ 17.086719] x21: ffffff8878e3c7c0 x20: ffffffc010acb000
[ 17.092032] x19: 0000000875e3e244 x18: 0000000000000010
[ 17.097343] x17: 0000000000000000 x16: 0000000000000000
[ 17.102647] x15: ffffff8879e4a988 x14: 0720072007200720
[ 17.107959] x13: 0720072007200720 x12: 0720072007200720
[ 17.113261] x11: 0720072007200720 x10: 0720072007200720
[ 17.118565] x9 : 0720072007200720 x8 : 000000000000022d
[ 17.123869] x7 : 0000000000000015 x6 : 0000000000000098
[ 17.129173] x5 : 0000000000000000 x4 : 0000000000000000
[ 17.134475] x3 : 00000000ffffffff x2 : ffffffc010a1d370
[ 17.139778] x1 : b420c9d75d27bb00 x0 : 0000000000000000
[ 17.145082] Call trace:
[ 17.147524] check_unmap+0x6a0/0x900
[ 17.151091] debug_dma_unmap_page+0x88/0x90
[ 17.155266] gem_rx+0x114/0x2f0
[ 17.158396] macb_poll+0x58/0x100
[ 17.161705] net_rx_action+0x118/0x400
[ 17.165445] __do_softirq+0x138/0x36c
[ 17.169100] irq_exit+0x98/0xc0
[ 17.172234] __handle_domain_irq+0x64/0xc0
[ 17.176320] gic_handle_irq+0x5c/0xc0
[ 17.179974] el1_irq+0xb8/0x140
[ 17.183109] xiic_process+0x5c/0xe30
[ 17.186677] irq_thread_fn+0x28/0x90
[ 17.190244] irq_thread+0x208/0x2a0
[ 17.193724] kthread+0x130/0x140
[ 17.196945] ret_from_fork+0x10/0x20
[ 17.200510] ---[ end trace 7240980785f81d6f ]---
[ 237.021490] ------------[ cut here ]------------
[ 237.026129] DMA-API: exceeded 7 overlapping mappings of cacheline 0x0000000021d79e7b
[ 237.033886] WARNING: CPU: 0 PID: 0 at kernel/dma/debug.c:499 add_dma_entry+0x214/0x240
[ 237.041802] Modules linked in: xxxxx
[ 237.061637] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G W 5.4.0 #28
[ 237.068941] Hardware name: xxxxx
[ 237.073116] pstate: 80000085 (Nzcv daIf -PAN -UAO)
[ 237.077900] pc : add_dma_entry+0x214/0x240
[ 237.081986] lr : add_dma_entry+0x214/0x240
[ 237.086072] sp : ffffffc010003c30
[ 237.089379] x29: ffffffc010003c30 x28: ffffff8878a0be00
[ 237.094683] x27: 0000000000000180 x26: ffffff8878e387c0
[ 237.099987] x25: 0000000000000002 x24: 0000000000000000
[ 237.105290] x23: 000000000000003b x22: ffffffc010a0fa00
[ 237.110594] x21: 0000000021d79e7b x20: ffffffc010abe600
[ 237.115897] x19: 00000000ffffffef x18: 0000000000000010
[ 237.121201] x17: 0000000000000000 x16: 0000000000000000
[ 237.126504] x15: ffffffc010a0fdc8 x14: 0720072007200720
[ 237.131807] x13: 0720072007200720 x12: 0720072007200720
[ 237.137111] x11: 0720072007200720 x10: 0720072007200720
[ 237.142415] x9 : 0720072007200720 x8 : 0000000000000259
[ 237.147718] x7 : 0000000000000001 x6 : 0000000000000000
[ 237.15302
---truncated--- |
| In the Linux kernel, the following vulnerability has been resolved:
btrfs: set page extent mapped after read_folio in relocate_one_page
One of the CI runs triggered the following panic
assertion failed: PagePrivate(page) && page->private, in fs/btrfs/subpage.c:229
------------[ cut here ]------------
kernel BUG at fs/btrfs/subpage.c:229!
Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
CPU: 0 PID: 923660 Comm: btrfs Not tainted 6.5.0-rc3+ #1
pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
pc : btrfs_subpage_assert+0xbc/0xf0
lr : btrfs_subpage_assert+0xbc/0xf0
sp : ffff800093213720
x29: ffff800093213720 x28: ffff8000932138b4 x27: 000000000c280000
x26: 00000001b5d00000 x25: 000000000c281000 x24: 000000000c281fff
x23: 0000000000001000 x22: 0000000000000000 x21: ffffff42b95bf880
x20: ffff42b9528e0000 x19: 0000000000001000 x18: ffffffffffffffff
x17: 667274622f736620 x16: 6e69202c65746176 x15: 0000000000000028
x14: 0000000000000003 x13: 00000000002672d7 x12: 0000000000000000
x11: ffffcd3f0ccd9204 x10: ffffcd3f0554ae50 x9 : ffffcd3f0379528c
x8 : ffff800093213428 x7 : 0000000000000000 x6 : ffffcd3f091771e8
x5 : ffff42b97f333948 x4 : 0000000000000000 x3 : 0000000000000000
x2 : 0000000000000000 x1 : ffff42b9556cde80 x0 : 000000000000004f
Call trace:
btrfs_subpage_assert+0xbc/0xf0
btrfs_subpage_set_dirty+0x38/0xa0
btrfs_page_set_dirty+0x58/0x88
relocate_one_page+0x204/0x5f0
relocate_file_extent_cluster+0x11c/0x180
relocate_data_extent+0xd0/0xf8
relocate_block_group+0x3d0/0x4e8
btrfs_relocate_block_group+0x2d8/0x490
btrfs_relocate_chunk+0x54/0x1a8
btrfs_balance+0x7f4/0x1150
btrfs_ioctl+0x10f0/0x20b8
__arm64_sys_ioctl+0x120/0x11d8
invoke_syscall.constprop.0+0x80/0xd8
do_el0_svc+0x6c/0x158
el0_svc+0x50/0x1b0
el0t_64_sync_handler+0x120/0x130
el0t_64_sync+0x194/0x198
Code: 91098021 b0007fa0 91346000 97e9c6d2 (d4210000)
This is the same problem outlined in 17b17fcd6d44 ("btrfs:
set_page_extent_mapped after read_folio in btrfs_cont_expand") , and the
fix is the same. I originally looked for the same pattern elsewhere in
our code, but mistakenly skipped over this code because I saw the page
cache readahead before we set_page_extent_mapped, not realizing that
this was only in the !page case, that we can still end up with a
!uptodate page and then do the btrfs_read_folio further down.
The fix here is the same as the above mentioned patch, move the
set_page_extent_mapped call to after the btrfs_read_folio() block to
make sure that we have the subpage blocksize stuff setup properly before
using the page. |
| In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: avoid a NULL dereference with unsupported widgets
If an IPC4 topology contains an unsupported widget, its .module_info
field won't be set, then sof_ipc4_route_setup() will cause a kernel
Oops trying to dereference it. Add a check for such cases. |
| In the Linux kernel, the following vulnerability has been resolved:
md: raid1: fix potential OOB in raid1_remove_disk()
If rddev->raid_disk is greater than mddev->raid_disks, there will be
an out-of-bounds in raid1_remove_disk(). We have already found
similar reports as follows:
1) commit d17f744e883b ("md-raid10: fix KASAN warning")
2) commit 1ebc2cec0b7d ("dm raid: fix KASAN warning in raid5_remove_disk")
Fix this bug by checking whether the "number" variable is
valid. |
