Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> fs/jfs: Add validity check for db_maxag and db_agpref<br /> <br /> Both db_maxag and db_agpref are used as the index of the<br /> db_agfree array, but there is currently no validity check for<br /> db_maxag and db_agpref, which can lead to errors.<br /> <br /> The following is related bug reported by Syzbot:<br /> <br /> UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20<br /> index 7936 is out of range for type &amp;#39;atomic_t[128]&amp;#39;<br /> <br /> Add checking that the values of db_maxag and db_agpref are valid<br /> indexes for the db_agfree array.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> jfs: fix array-index-out-of-bounds in diAlloc<br /> <br /> Currently there is not check against the agno of the iag while<br /> allocating new inodes to avoid fragmentation problem. Added the check<br /> which is required.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ALSA: hda: Fix possible null-ptr-deref when assigning a stream<br /> <br /> While AudioDSP drivers assign streams exclusively of HOST or LINK type,<br /> nothing blocks a user to attempt to assign a COUPLED stream. As<br /> supplied substream instance may be a stub, what is the case when<br /> code-loading, such scenario ends with null-ptr-deref.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: config: fix iteration issue in &amp;#39;usb_get_bos_descriptor()&amp;#39;<br /> <br /> The BOS descriptor defines a root descriptor and is the base descriptor for<br /> accessing a family of related descriptors.<br /> <br /> Function &amp;#39;usb_get_bos_descriptor()&amp;#39; encounters an iteration issue when<br /> skipping the &amp;#39;USB_DT_DEVICE_CAPABILITY&amp;#39; descriptor type. This results in<br /> the same descriptor being read repeatedly.<br /> <br /> To address this issue, a &amp;#39;goto&amp;#39; statement is introduced to ensure that the<br /> pointer and the amount read is updated correctly. This ensures that the<br /> function iterates to the next descriptor instead of reading the same<br /> descriptor repeatedly.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net/mlx5e: Track xmit submission to PTP WQ after populating metadata map<br /> <br /> Ensure the skb is available in metadata mapping to skbs before tracking the<br /> metadata index for detecting undelivered CQEs. If the metadata index is put<br /> in the tracking list before putting the skb in the map, the metadata index<br /> might be used for detecting undelivered CQEs before the relevant skb is<br /> available in the map, which can lead to a null-ptr-deref.<br /> <br /> Log:<br /> general protection fault, probably for non-canonical address 0xdffffc0000000005: 0000 [#1] SMP KASAN<br /> KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]<br /> CPU: 0 PID: 1243 Comm: kworker/0:2 Not tainted 6.6.0-rc4+ #108<br /> Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014<br /> Workqueue: events mlx5e_rx_dim_work [mlx5_core]<br /> RIP: 0010:mlx5e_ptp_napi_poll+0x9a4/0x2290 [mlx5_core]<br /> Code: 8c 24 38 cc ff ff 4c 8d 3c c1 4c 89 f9 48 c1 e9 03 42 80 3c 31 00 0f 85 97 0f 00 00 4d 8b 3f 49 8d 7f 28 48 89 f9 48 c1 e9 03 80 3c 31 00 0f 85 8b 0f 00 00 49 8b 47 28 48 85 c0 0f 84 05 07<br /> RSP: 0018:ffff8884d3c09c88 EFLAGS: 00010206<br /> RAX: 0000000000000069 RBX: ffff8881160349d8 RCX: 0000000000000005<br /> RDX: ffffed10218f48cf RSI: 0000000000000004 RDI: 0000000000000028<br /> RBP: ffff888122707700 R08: 0000000000000001 R09: ffffed109a781383<br /> R10: 0000000000000003 R11: 0000000000000003 R12: ffff88810c7a7a40<br /> R13: ffff888122707700 R14: dffffc0000000000 R15: 0000000000000000<br /> FS: 0000000000000000(0000) GS:ffff8884d3c00000(0000) knlGS:0000000000000000<br /> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> CR2: 00007f4f878dd6e0 CR3: 000000014d108002 CR4: 0000000000370eb0<br /> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000<br /> DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400<br /> Call Trace:<br /> <br /> ? die_addr+0x3c/0xa0<br /> ? exc_general_protection+0x144/0x210<br /> ? asm_exc_general_protection+0x22/0x30<br /> ? mlx5e_ptp_napi_poll+0x9a4/0x2290 [mlx5_core]<br /> ? mlx5e_ptp_napi_poll+0x8f6/0x2290 [mlx5_core]<br /> __napi_poll.constprop.0+0xa4/0x580<br /> net_rx_action+0x460/0xb80<br /> ? _raw_spin_unlock_irqrestore+0x32/0x60<br /> ? __napi_poll.constprop.0+0x580/0x580<br /> ? tasklet_action_common.isra.0+0x2ef/0x760<br /> __do_softirq+0x26c/0x827<br /> irq_exit_rcu+0xc2/0x100<br /> common_interrupt+0x7f/0xa0<br /> <br /> <br /> asm_common_interrupt+0x22/0x40<br /> RIP: 0010:__kmem_cache_alloc_node+0xb/0x330<br /> Code: 41 5d 41 5e 41 5f c3 8b 44 24 14 8b 4c 24 10 09 c8 eb d5 e8 b7 43 ca 01 0f 1f 80 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 41 57 56 41 89 d6 41 55 41 89 f5 41 54 49 89 fc 53 48 83 e4 f0 48 83<br /> RSP: 0018:ffff88812c4079c0 EFLAGS: 00000246<br /> RAX: 1ffffffff083c7fe RBX: ffff888100042dc0 RCX: 0000000000000218<br /> RDX: 00000000ffffffff RSI: 0000000000000dc0 RDI: ffff888100042dc0<br /> RBP: ffff88812c4079c8 R08: ffffffffa0289f96 R09: ffffed1025880ea9<br /> R10: ffff888138839f80 R11: 0000000000000002 R12: 0000000000000dc0<br /> R13: 0000000000000100 R14: 000000000000008c R15: ffff8881271fc450<br /> ? cmd_exec+0x796/0x2200 [mlx5_core]<br /> kmalloc_trace+0x26/0xc0<br /> cmd_exec+0x796/0x2200 [mlx5_core]<br /> mlx5_cmd_do+0x22/0xc0 [mlx5_core]<br /> mlx5_cmd_exec+0x17/0x30 [mlx5_core]<br /> mlx5_core_modify_cq_moderation+0x139/0x1b0 [mlx5_core]<br /> ? mlx5_add_cq_to_tasklet+0x280/0x280 [mlx5_core]<br /> ? lockdep_set_lock_cmp_fn+0x190/0x190<br /> ? process_one_work+0x659/0x1220<br /> mlx5e_rx_dim_work+0x9d/0x100 [mlx5_core]<br /> process_one_work+0x730/0x1220<br /> ? lockdep_hardirqs_on_prepare+0x400/0x400<br /> ? max_active_store+0xf0/0xf0<br /> ? assign_work+0x168/0x240<br /> worker_thread+0x70f/0x12d0<br /> ? __kthread_parkme+0xd1/0x1d0<br /> ? process_one_work+0x1220/0x1220<br /> kthread+0x2d9/0x3b0<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork+0x2d/0x70<br /> ? kthread_complete_and_exit+0x20/0x20<br /> ret_from_fork_as<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> net: wangxun: fix kernel panic due to null pointer<br /> <br /> When the device uses a custom subsystem vendor ID, the function<br /> wx_sw_init() returns before the memory of &amp;#39;wx-&gt;mac_table&amp;#39; is allocated.<br /> The null pointer will causes the kernel panic.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> bonding: stop the device in bond_setup_by_slave()<br /> <br /> Commit 9eed321cde22 ("net: lapbether: only support ethernet devices")<br /> has been able to keep syzbot away from net/lapb, until today.<br /> <br /> In the following splat [1], the issue is that a lapbether device has<br /> been created on a bonding device without members. Then adding a non<br /> ARPHRD_ETHER member forced the bonding master to change its type.<br /> <br /> The fix is to make sure we call dev_close() in bond_setup_by_slave()<br /> so that the potential linked lapbether devices (or any other devices<br /> having assumptions on the physical device) are removed.<br /> <br /> A similar bug has been addressed in commit 40baec225765<br /> ("bonding: fix panic on non-ARPHRD_ETHER enslave failure")<br /> <br /> [1]<br /> skbuff: skb_under_panic: text:ffff800089508810 len:44 put:40 head:ffff0000c78e7c00 data:ffff0000c78e7bea tail:0x16 end:0x140 dev:bond0<br /> kernel BUG at net/core/skbuff.c:192 !<br /> Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP<br /> Modules linked in:<br /> CPU: 0 PID: 6007 Comm: syz-executor383 Not tainted 6.6.0-rc3-syzkaller-gbf6547d8715b #0<br /> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023<br /> pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> pc : skb_panic net/core/skbuff.c:188 [inline]<br /> pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202<br /> lr : skb_panic net/core/skbuff.c:188 [inline]<br /> lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:202<br /> sp : ffff800096a06aa0<br /> x29: ffff800096a06ab0 x28: ffff800096a06ba0 x27: dfff800000000000<br /> x26: ffff0000ce9b9b50 x25: 0000000000000016 x24: ffff0000c78e7bea<br /> x23: ffff0000c78e7c00 x22: 000000000000002c x21: 0000000000000140<br /> x20: 0000000000000028 x19: ffff800089508810 x18: ffff800096a06100<br /> x17: 0000000000000000 x16: ffff80008a629a3c x15: 0000000000000001<br /> x14: 1fffe00036837a32 x13: 0000000000000000 x12: 0000000000000000<br /> x11: 0000000000000201 x10: 0000000000000000 x9 : cb50b496c519aa00<br /> x8 : cb50b496c519aa00 x7 : 0000000000000001 x6 : 0000000000000001<br /> x5 : ffff800096a063b8 x4 : ffff80008e280f80 x3 : ffff8000805ad11c<br /> x2 : 0000000000000001 x1 : 0000000100000201 x0 : 0000000000000086<br /> Call trace:<br /> skb_panic net/core/skbuff.c:188 [inline]<br /> skb_under_panic+0x13c/0x140 net/core/skbuff.c:202<br /> skb_push+0xf0/0x108 net/core/skbuff.c:2446<br /> ip6gre_header+0xbc/0x738 net/ipv6/ip6_gre.c:1384<br /> dev_hard_header include/linux/netdevice.h:3136 [inline]<br /> lapbeth_data_transmit+0x1c4/0x298 drivers/net/wan/lapbether.c:257<br /> lapb_data_transmit+0x8c/0xb0 net/lapb/lapb_iface.c:447<br /> lapb_transmit_buffer+0x178/0x204 net/lapb/lapb_out.c:149<br /> lapb_send_control+0x220/0x320 net/lapb/lapb_subr.c:251<br /> __lapb_disconnect_request+0x9c/0x17c net/lapb/lapb_iface.c:326<br /> lapb_device_event+0x288/0x4e0 net/lapb/lapb_iface.c:492<br /> notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93<br /> raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461<br /> call_netdevice_notifiers_info net/core/dev.c:1970 [inline]<br /> call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2022 [inline]<br /> __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508<br /> dev_close_many+0x1e0/0x470 net/core/dev.c:1559<br /> dev_close+0x174/0x250 net/core/dev.c:1585<br /> lapbeth_device_event+0x2e4/0x958 drivers/net/wan/lapbether.c:466<br /> notifier_call_chain+0x1a4/0x510 kernel/notifier.c:93<br /> raw_notifier_call_chain+0x3c/0x50 kernel/notifier.c:461<br /> call_netdevice_notifiers_info net/core/dev.c:1970 [inline]<br /> call_netdevice_notifiers_extack net/core/dev.c:2008 [inline]<br /> call_netdevice_notifiers net/core/dev.c:2022 [inline]<br /> __dev_close_many+0x1b8/0x3c4 net/core/dev.c:1508<br /> dev_close_many+0x1e0/0x470 net/core/dev.c:1559<br /> dev_close+0x174/0x250 net/core/dev.c:1585<br /> bond_enslave+0x2298/0x30cc drivers/net/bonding/bond_main.c:2332<br /> bond_do_ioctl+0x268/0xc64 drivers/net/bonding/bond_main.c:4539<br /> dev_ifsioc+0x754/0x9ac<br /> dev_ioctl+0x4d8/0xd34 net/core/dev_ioctl.c:786<br /> sock_do_ioctl+0x1d4/0x2d0 net/socket.c:1217<br /> sock_ioctl+0x4e8/0x834 net/socket.c:1322<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_<br /> ---truncated---

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> scsi: ufs: core: Fix racing issue between ufshcd_mcq_abort() and ISR<br /> <br /> If command timeout happens and cq complete IRQ is raised at the same time,<br /> ufshcd_mcq_abort clears lprb-&gt;cmd and a NULL pointer deref happens in the<br /> ISR. Error log:<br /> <br /> ufshcd_abort: Device abort task at tag 18<br /> Unable to handle kernel NULL pointer dereference at virtual address<br /> 0000000000000108<br /> pc : [0xffffffe27ef867ac] scsi_dma_unmap+0xc/0x44<br /> lr : [0xffffffe27f1b898c] ufshcd_release_scsi_cmd+0x24/0x114

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix racy may inline data check in dio write<br /> <br /> syzbot reports that the following warning from ext4_iomap_begin()<br /> triggers as of the commit referenced below:<br /> <br /> if (WARN_ON_ONCE(ext4_has_inline_data(inode)))<br /> return -ERANGE;<br /> <br /> This occurs during a dio write, which is never expected to encounter<br /> an inode with inline data. To enforce this behavior,<br /> ext4_dio_write_iter() checks the current inline state of the inode<br /> and clears the MAY_INLINE_DATA state flag to either fall back to<br /> buffered writes, or enforce that any other writers in progress on<br /> the inode are not allowed to create inline data.<br /> <br /> The problem is that the check for existing inline data and the state<br /> flag can span a lock cycle. For example, if the ilock is originally<br /> locked shared and subsequently upgraded to exclusive, another writer<br /> may have reacquired the lock and created inline data before the dio<br /> write task acquires the lock and proceeds.<br /> <br /> The commit referenced below loosens the lock requirements to allow<br /> some forms of unaligned dio writes to occur under shared lock, but<br /> AFAICT the inline data check was technically already racy for any<br /> dio write that would have involved a lock cycle. Regardless, lift<br /> clearing of the state bit to the same lock critical section that<br /> checks for preexisting inline data on the inode to close the race.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> blk-mq: make sure active queue usage is held for bio_integrity_prep()<br /> <br /> blk_integrity_unregister() can come if queue usage counter isn&amp;#39;t held<br /> for one bio with integrity prepared, so this request may be completed with<br /> calling profile-&gt;complete_fn, then kernel panic.<br /> <br /> Another constraint is that bio_integrity_prep() needs to be called<br /> before bio merge.<br /> <br /> Fix the issue by:<br /> <br /> - call bio_integrity_prep() with one queue usage counter grabbed reliably<br /> <br /> - call bio_integrity_prep() before bio merge

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> i915/perf: Fix NULL deref bugs with drm_dbg() calls<br /> <br /> When i915 perf interface is not available dereferencing it will lead to<br /> NULL dereferences.<br /> <br /> As returning -ENOTSUPP is pretty clear return when perf interface is not<br /> available.<br /> <br /> [tursulin: added stable tag]<br /> (cherry picked from commit 36f27350ff745bd228ab04d7845dfbffc177a889)

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> tty: vcc: Add check for kstrdup() in vcc_probe()<br /> <br /> Add check for the return value of kstrdup() and return the error, if it<br /> fails in order to avoid NULL pointer dereference.