Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: rose: lock the socket in rose_bind()<br /> <br /> syzbot reported a soft lockup in rose_loopback_timer(),<br /> with a repro calling bind() from multiple threads.<br /> <br /> rose_bind() must lock the socket to avoid this issue.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: brcmfmac: Check the return value of of_property_read_string_index()<br /> <br /> Somewhen between 6.10 and 6.11 the driver started to crash on my<br /> MacBookPro14,3. The property doesn&amp;#39;t exist and &amp;#39;tmp&amp;#39; remains<br /> uninitialized, so we pass a random pointer to devm_kstrdup().<br /> <br /> The crash I am getting looks like this:<br /> <br /> BUG: unable to handle page fault for address: 00007f033c669379<br /> PF: supervisor read access in kernel mode<br /> PF: error_code(0x0001) - permissions violation<br /> PGD 8000000101341067 P4D 8000000101341067 PUD 101340067 PMD 1013bb067 PTE 800000010aee9025<br /> Oops: Oops: 0001 [#1] SMP PTI<br /> CPU: 4 UID: 0 PID: 827 Comm: (udev-worker) Not tainted 6.11.8-gentoo #1<br /> Hardware name: Apple Inc. MacBookPro14,3/Mac-551B86E5744E2388, BIOS 529.140.2.0.0 06/23/2024<br /> RIP: 0010:strlen+0x4/0x30<br /> Code: f7 75 ec 31 c0 c3 cc cc cc cc 48 89 f8 c3 cc cc cc cc 0f 1f 40 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 3f 00 74 14 48 89 f8 48 83 c0 01 80 38 00 75 f7 48 29 f8 c3 cc<br /> RSP: 0018:ffffb4aac0683ad8 EFLAGS: 00010202<br /> RAX: 00000000ffffffea RBX: 00007f033c669379 RCX: 0000000000000001<br /> RDX: 0000000000000cc0 RSI: 00007f033c669379 RDI: 00007f033c669379<br /> RBP: 00000000ffffffea R08: 0000000000000000 R09: 00000000c0ba916a<br /> R10: ffffffffffffffff R11: ffffffffb61ea260 R12: ffff91f7815b50c8<br /> R13: 0000000000000cc0 R14: ffff91fafefffe30 R15: ffffb4aac0683b30<br /> FS: 00007f033ccbe8c0(0000) GS:ffff91faeed00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f033c669379 CR3: 0000000107b1e004 CR4: 00000000003706f0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? __die+0x23/0x70<br /> ? page_fault_oops+0x149/0x4c0<br /> ? raw_spin_rq_lock_nested+0xe/0x20<br /> ? sched_balance_newidle+0x22b/0x3c0<br /> ? update_load_avg+0x78/0x770<br /> ? exc_page_fault+0x6f/0x150<br /> ? asm_exc_page_fault+0x26/0x30<br /> ? __pfx_pci_conf1_write+0x10/0x10<br /> ? strlen+0x4/0x30<br /> devm_kstrdup+0x25/0x70<br /> brcmf_of_probe+0x273/0x350 [brcmfmac]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5: HWS, change error flow on matcher disconnect<br /> <br /> Currently, when firmware failure occurs during matcher disconnect flow,<br /> the error flow of the function reconnects the matcher back and returns<br /> an error, which continues running the calling function and eventually<br /> frees the matcher that is being disconnected.<br /> This leads to a case where we have a freed matcher on the matchers list,<br /> which in turn leads to use-after-free and eventual crash.<br /> <br /> This patch fixes that by not trying to reconnect the matcher back when<br /> some FW command fails during disconnect.<br /> <br /> Note that we&amp;#39;re dealing here with FW error. We can&amp;#39;t overcome this<br /> problem. This might lead to bad steering state (e.g. wrong connection<br /> between matchers), and will also lead to resource leakage, as it is<br /> the case with any other error handling during resource destruction.<br /> <br /> However, the goal here is to allow the driver to continue and not crash<br /> the machine with use-after-free error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: don&amp;#39;t use btrfs_set_item_key_safe on RAID stripe-extents<br /> <br /> Don&amp;#39;t use btrfs_set_item_key_safe() to modify the keys in the RAID<br /> stripe-tree, as this can lead to corruption of the tree, which is caught<br /> by the checks in btrfs_set_item_key_safe():<br /> <br /> BTRFS info (device nvme1n1): leaf 49168384 gen 15 total ptrs 194 free space 8329 owner 12<br /> BTRFS info (device nvme1n1): refs 2 lock_owner 1030 current 1030<br /> [ snip ]<br /> item 105 key (354549760 230 20480) itemoff 14587 itemsize 16<br /> stride 0 devid 5 physical 67502080<br /> item 106 key (354631680 230 4096) itemoff 14571 itemsize 16<br /> stride 0 devid 1 physical 88559616<br /> item 107 key (354631680 230 32768) itemoff 14555 itemsize 16<br /> stride 0 devid 1 physical 88555520<br /> item 108 key (354717696 230 28672) itemoff 14539 itemsize 16<br /> stride 0 devid 2 physical 67604480<br /> [ snip ]<br /> BTRFS critical (device nvme1n1): slot 106 key (354631680 230 32768) new key (354635776 230 4096)<br /> ------------[ cut here ]------------<br /> kernel BUG at fs/btrfs/ctree.c:2602!<br /> Oops: invalid opcode: 0000 [#1] PREEMPT SMP PTI<br /> CPU: 1 UID: 0 PID: 1055 Comm: fsstress Not tainted 6.13.0-rc1+ #1464<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014<br /> RIP: 0010:btrfs_set_item_key_safe+0xf7/0x270<br /> Code: <br /> RSP: 0018:ffffc90001337ab0 EFLAGS: 00010287<br /> RAX: 0000000000000000 RBX: ffff8881115fd000 RCX: 0000000000000000<br /> RDX: 0000000000000001 RSI: 0000000000000001 RDI: 00000000ffffffff<br /> RBP: ffff888110ed6f50 R08: 00000000ffffefff R09: ffffffff8244c500<br /> R10: 00000000ffffefff R11: 00000000ffffffff R12: ffff888100586000<br /> R13: 00000000000000c9 R14: ffffc90001337b1f R15: ffff888110f23b58<br /> FS: 00007f7d75c72740(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007fa811652c60 CR3: 0000000111398001 CR4: 0000000000370eb0<br /> Call Trace:<br /> <br /> ? __die_body.cold+0x14/0x1a<br /> ? die+0x2e/0x50<br /> ? do_trap+0xca/0x110<br /> ? do_error_trap+0x65/0x80<br /> ? btrfs_set_item_key_safe+0xf7/0x270<br /> ? exc_invalid_op+0x50/0x70<br /> ? btrfs_set_item_key_safe+0xf7/0x270<br /> ? asm_exc_invalid_op+0x1a/0x20<br /> ? btrfs_set_item_key_safe+0xf7/0x270<br /> btrfs_partially_delete_raid_extent+0xc4/0xe0<br /> btrfs_delete_raid_extent+0x227/0x240<br /> __btrfs_free_extent.isra.0+0x57f/0x9c0<br /> ? exc_coproc_segment_overrun+0x40/0x40<br /> __btrfs_run_delayed_refs+0x2fa/0xe80<br /> btrfs_run_delayed_refs+0x81/0xe0<br /> btrfs_commit_transaction+0x2dd/0xbe0<br /> ? preempt_count_add+0x52/0xb0<br /> btrfs_sync_file+0x375/0x4c0<br /> do_fsync+0x39/0x70<br /> __x64_sys_fsync+0x13/0x20<br /> do_syscall_64+0x54/0x110<br /> entry_SYSCALL_64_after_hwframe+0x76/0x7e<br /> RIP: 0033:0x7f7d7550ef90<br /> Code: <br /> RSP: 002b:00007ffd70237248 EFLAGS: 00000202 ORIG_RAX: 000000000000004a<br /> RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007f7d7550ef90<br /> RDX: 000000000000013a RSI: 000000000040eb28 RDI: 0000000000000004<br /> RBP: 000000000000001b R08: 0000000000000078 R09: 00007ffd7023725c<br /> R10: 00007f7d75400390 R11: 0000000000000202 R12: 028f5c28f5c28f5c<br /> R13: 8f5c28f5c28f5c29 R14: 000000000040b520 R15: 00007f7d75c726c8<br /> <br /> <br /> While the root cause of the tree order corruption isn&amp;#39;t clear, using<br /> btrfs_duplicate_item() to copy the item and then adjusting both the key<br /> and the per-device physical addresses is a safe way to counter this<br /> problem.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> btrfs: fix use-after-free when attempting to join an aborted transaction<br /> <br /> When we are trying to join the current transaction and if it&amp;#39;s aborted,<br /> we read its &amp;#39;aborted&amp;#39; field after unlocking fs_info-&gt;trans_lock and<br /> without holding any extra reference count on it. This means that a<br /> concurrent task that is aborting the transaction may free the transaction<br /> before we read its &amp;#39;aborted&amp;#39; field, leading to a use-after-free.<br /> <br /> Fix this by reading the &amp;#39;aborted&amp;#39; field while holding fs_info-&gt;trans_lock<br /> since any freeing task must first acquire that lock and set<br /> fs_info-&gt;running_transaction to NULL before freeing the transaction.<br /> <br /> This was reported by syzbot and Dmitry with the following stack traces<br /> from KASAN:<br /> <br /> ==================================================================<br /> BUG: KASAN: slab-use-after-free in join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278<br /> Read of size 4 at addr ffff888011839024 by task kworker/u4:9/1128<br /> <br /> CPU: 0 UID: 0 PID: 1128 Comm: kworker/u4:9 Not tainted 6.13.0-rc7-syzkaller-00019-gc45323b7560e #0<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014<br /> Workqueue: events_unbound btrfs_async_reclaim_data_space<br /> Call Trace:<br /> <br /> __dump_stack lib/dump_stack.c:94 [inline]<br /> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120<br /> print_address_description mm/kasan/report.c:378 [inline]<br /> print_report+0x169/0x550 mm/kasan/report.c:489<br /> kasan_report+0x143/0x180 mm/kasan/report.c:602<br /> join_transaction+0xd9b/0xda0 fs/btrfs/transaction.c:278<br /> start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697<br /> flush_space+0x448/0xcf0 fs/btrfs/space-info.c:803<br /> btrfs_async_reclaim_data_space+0x159/0x510 fs/btrfs/space-info.c:1321<br /> process_one_work kernel/workqueue.c:3236 [inline]<br /> process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3317<br /> worker_thread+0x870/0xd30 kernel/workqueue.c:3398<br /> kthread+0x2f0/0x390 kernel/kthread.c:389<br /> ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147<br /> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244<br /> <br /> <br /> Allocated by task 5315:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> poison_kmalloc_redzone mm/kasan/common.c:377 [inline]<br /> __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:394<br /> kasan_kmalloc include/linux/kasan.h:260 [inline]<br /> __kmalloc_cache_noprof+0x243/0x390 mm/slub.c:4329<br /> kmalloc_noprof include/linux/slab.h:901 [inline]<br /> join_transaction+0x144/0xda0 fs/btrfs/transaction.c:308<br /> start_transaction+0xaf8/0x1670 fs/btrfs/transaction.c:697<br /> btrfs_create_common+0x1b2/0x2e0 fs/btrfs/inode.c:6572<br /> lookup_open fs/namei.c:3649 [inline]<br /> open_last_lookups fs/namei.c:3748 [inline]<br /> path_openat+0x1c03/0x3590 fs/namei.c:3984<br /> do_filp_open+0x27f/0x4e0 fs/namei.c:4014<br /> do_sys_openat2+0x13e/0x1d0 fs/open.c:1402<br /> do_sys_open fs/open.c:1417 [inline]<br /> __do_sys_creat fs/open.c:1495 [inline]<br /> __se_sys_creat fs/open.c:1489 [inline]<br /> __x64_sys_creat+0x123/0x170 fs/open.c:1489<br /> do_syscall_x64 arch/x86/entry/common.c:52 [inline]<br /> do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83<br /> entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> Freed by task 5336:<br /> kasan_save_stack mm/kasan/common.c:47 [inline]<br /> kasan_save_track+0x3f/0x80 mm/kasan/common.c:68<br /> kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:582<br /> poison_slab_object mm/kasan/common.c:247 [inline]<br /> __kasan_slab_free+0x59/0x70 mm/kasan/common.c:264<br /> kasan_slab_free include/linux/kasan.h:233 [inline]<br /> slab_free_hook mm/slub.c:2353 [inline]<br /> slab_free mm/slub.c:4613 [inline]<br /> kfree+0x196/0x430 mm/slub.c:4761<br /> cleanup_transaction fs/btrfs/transaction.c:2063 [inline]<br /> btrfs_commit_transaction+0x2c97/0x3720 fs/btrfs/transaction.c:2598<br /> insert_balance_item+0x1284/0x20b0 fs/btrfs/volumes.c:3757<br /> btrfs_balance+0x992/<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> misc: fastrpc: Fix copy buffer page size<br /> <br /> For non-registered buffer, fastrpc driver copies the buffer and<br /> pass it to the remote subsystem. There is a problem with current<br /> implementation of page size calculation which is not considering<br /> the offset in the calculation. This might lead to passing of<br /> improper and out-of-bounds page size which could result in<br /> memory issue. Calculate page start and page end using the offset<br /> adjusted address instead of absolute address.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> NFC: nci: Add bounds checking in nci_hci_create_pipe()<br /> <br /> The "pipe" variable is a u8 which comes from the network. If it&amp;#39;s more<br /> than 127, then it results in memory corruption in the caller,<br /> nci_hci_connect_gate().

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> nilfs2: fix possible int overflows in nilfs_fiemap()<br /> <br /> Since nilfs_bmap_lookup_contig() in nilfs_fiemap() calculates its result<br /> by being prepared to go through potentially maxblocks == INT_MAX blocks,<br /> the value in n may experience an overflow caused by left shift of blkbits.<br /> <br /> While it is extremely unlikely to occur, play it safe and cast right hand<br /> expression to wider type to mitigate the issue.<br /> <br /> Found by Linux Verification Center (linuxtesting.org) with static analysis<br /> tool SVACE.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ceph: fix memory leak in ceph_mds_auth_match()<br /> <br /> We now free the temporary target path substring allocation on every<br /> possible branch, instead of omitting the default branch. In some<br /> cases, a memory leak occured, which could rapidly crash the system<br /> (depending on how many file accesses were attempted).<br /> <br /> This was detected in production because it caused a continuous memory<br /> growth, eventually triggering kernel OOM and completely hard-locking<br /> the kernel.<br /> <br /> Relevant kmemleak stacktrace:<br /> <br /> unreferenced object 0xffff888131e69900 (size 128):<br /> comm "git", pid 66104, jiffies 4295435999<br /> hex dump (first 32 bytes):<br /> 76 6f 6c 75 6d 65 73 2f 63 6f 6e 74 61 69 6e 65 volumes/containe<br /> 72 73 2f 67 69 74 65 61 2f 67 69 74 65 61 2f 67 rs/gitea/gitea/g<br /> backtrace (crc 2f3bb450):<br /> [] __kmalloc_noprof+0x359/0x510<br /> [] ceph_mds_check_access+0x5bf/0x14e0 [ceph]<br /> [] ceph_open+0x312/0xd80 [ceph]<br /> [] do_dentry_open+0x456/0x1120<br /> [] vfs_open+0x79/0x360<br /> [] path_openat+0x1de5/0x4390<br /> [] do_filp_open+0x19c/0x3c0<br /> [] do_sys_openat2+0x141/0x180<br /> [] __x64_sys_open+0xe5/0x1a0<br /> [] do_syscall_64+0xb7/0x210<br /> [] entry_SYSCALL_64_after_hwframe+0x77/0x7f<br /> <br /> It can be triggered by mouting a subdirectory of a CephFS filesystem,<br /> and then trying to access files on this subdirectory with an auth token<br /> using a path-scoped capability:<br /> <br /> $ ceph auth get client.services<br /> [client.services]<br /> key = REDACTED<br /> caps mds = "allow rw fsname=cephfs path=/volumes/"<br /> caps mon = "allow r fsname=cephfs"<br /> caps osd = "allow rw tag cephfs data=cephfs"<br /> <br /> $ cat /proc/self/mounts<br /> services@[REDACTED].cephfs=/volumes/containers /ceph/containers ceph rw,noatime,name=services,secret=,ms_mode=prefer-crc,mount_timeout=300,acl,mon_addr=[REDACTED]:3300,recover_session=clean 0 0<br /> <br /> $ seq 1 1000000 | xargs -P32 --replace={} touch /ceph/containers/file-{} &amp;&amp; \<br /> seq 1 1000000 | xargs -P32 --replace={} cat /ceph/containers/file-{}<br /> <br /> [ idryomov: combine if statements, rename rc to path_matched and make<br /> it a bool, formatting ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ata: libata-sff: Ensure that we cannot write outside the allocated buffer<br /> <br /> reveliofuzzing reported that a SCSI_IOCTL_SEND_COMMAND ioctl with out_len<br /> set to 0xd42, SCSI command set to ATA_16 PASS-THROUGH, ATA command set to<br /> ATA_NOP, and protocol set to ATA_PROT_PIO, can cause ata_pio_sector() to<br /> write outside the allocated buffer, overwriting random memory.<br /> <br /> While a ATA device is supposed to abort a ATA_NOP command, there does seem<br /> to be a bug either in libata-sff or QEMU, where either this status is not<br /> set, or the status is cleared before read by ata_sff_hsm_move().<br /> Anyway, that is most likely a separate bug.<br /> <br /> Looking at __atapi_pio_bytes(), it already has a safety check to ensure<br /> that __atapi_pio_bytes() cannot write outside the allocated buffer.<br /> <br /> Add a similar check to ata_pio_sector(), such that also ata_pio_sector()<br /> cannot write outside the allocated buffer.

Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usbnet: ipheth: fix DPE OoB read<br /> <br /> Fix an out-of-bounds DPE read, limit the number of processed DPEs to<br /> the amount that fits into the fixed-size NDP16 header.