Vulnerabilities

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> kobject: Add sanity check for kset-&gt;kobj.ktype in kset_register()<br /> <br /> When I register a kset in the following way:<br /> static struct kset my_kset;<br /> kobject_set_name(&amp;my_kset.kobj, "my_kset");<br /> ret = kset_register(&amp;my_kset);<br /> <br /> A null pointer dereference exception is occurred:<br /> [ 4453.568337] Unable to handle kernel NULL pointer dereference at \<br /> virtual address 0000000000000028<br /> ... ...<br /> [ 4453.810361] Call trace:<br /> [ 4453.813062] kobject_get_ownership+0xc/0x34<br /> [ 4453.817493] kobject_add_internal+0x98/0x274<br /> [ 4453.822005] kset_register+0x5c/0xb4<br /> [ 4453.825820] my_kobj_init+0x44/0x1000 [my_kset]<br /> ... ...<br /> <br /> Because I didn&amp;#39;t initialize my_kset.kobj.ktype.<br /> <br /> According to the description in Documentation/core-api/kobject.rst:<br /> - A ktype is the type of object that embeds a kobject. Every structure<br /> that embeds a kobject needs a corresponding ktype.<br /> <br /> So add sanity check to make sure kset-&gt;kobj.ktype is not NULL.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ionic: catch failure from devlink_alloc<br /> <br /> Add a check for NULL on the alloc return. If devlink_alloc() fails and<br /> we try to use devlink_priv() on the NULL return, the kernel gets very<br /> unhappy and panics. With this fix, the driver load will still fail,<br /> but at least it won&amp;#39;t panic the kernel.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> iw_cxgb4: Fix potential NULL dereference in c4iw_fill_res_cm_id_entry()<br /> <br /> This condition needs to match the previous "if (epcp-&gt;state == LISTEN) {"<br /> exactly to avoid a NULL dereference of either "listen_ep" or "ep". The<br /> problem is that "epcp" has been re-assigned so just testing<br /> "if (epcp-&gt;state == LISTEN) {" a second time is not sufficient.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> usb: xhci: tegra: fix sleep in atomic call<br /> <br /> When we set the dual-role port to Host mode, we observed the following<br /> splat:<br /> [ 167.057718] BUG: sleeping function called from invalid context at<br /> include/linux/sched/mm.h:229<br /> [ 167.057872] Workqueue: events tegra_xusb_usb_phy_work<br /> [ 167.057954] Call trace:<br /> [ 167.057962] dump_backtrace+0x0/0x210<br /> [ 167.057996] show_stack+0x30/0x50<br /> [ 167.058020] dump_stack_lvl+0x64/0x84<br /> [ 167.058065] dump_stack+0x14/0x34<br /> [ 167.058100] __might_resched+0x144/0x180<br /> [ 167.058140] __might_sleep+0x64/0xd0<br /> [ 167.058171] slab_pre_alloc_hook.constprop.0+0xa8/0x110<br /> [ 167.058202] __kmalloc_track_caller+0x74/0x2b0<br /> [ 167.058233] kvasprintf+0xa4/0x190<br /> [ 167.058261] kasprintf+0x58/0x90<br /> [ 167.058285] tegra_xusb_find_port_node.isra.0+0x58/0xd0<br /> [ 167.058334] tegra_xusb_find_port+0x38/0xa0<br /> [ 167.058380] tegra_xusb_padctl_get_usb3_companion+0x38/0xd0<br /> [ 167.058430] tegra_xhci_id_notify+0x8c/0x1e0<br /> [ 167.058473] notifier_call_chain+0x88/0x100<br /> [ 167.058506] atomic_notifier_call_chain+0x44/0x70<br /> [ 167.058537] tegra_xusb_usb_phy_work+0x60/0xd0<br /> [ 167.058581] process_one_work+0x1dc/0x4c0<br /> [ 167.058618] worker_thread+0x54/0x410<br /> [ 167.058650] kthread+0x188/0x1b0<br /> [ 167.058672] ret_from_fork+0x10/0x20<br /> <br /> The function tegra_xusb_padctl_get_usb3_companion eventually calls<br /> tegra_xusb_find_port and this in turn calls kasprintf which might sleep<br /> and so cannot be called from an atomic context.<br /> <br /> Fix this by moving the call to tegra_xusb_padctl_get_usb3_companion to<br /> the tegra_xhci_id_work function where it is really needed.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> x86/MCE/AMD: Use an u64 for bank_map<br /> <br /> Thee maximum number of MCA banks is 64 (MAX_NR_BANKS), see<br /> <br /> a0bc32b3cacf ("x86/mce: Increase maximum number of banks to 64").<br /> <br /> However, the bank_map which contains a bitfield of which banks to<br /> initialize is of type unsigned int and that overflows when those bit<br /> numbers are &gt;= 32, leading to UBSAN complaining correctly:<br /> <br /> UBSAN: shift-out-of-bounds in arch/x86/kernel/cpu/mce/amd.c:1365:38<br /> shift exponent 32 is too large for 32-bit type &amp;#39;int&amp;#39;<br /> <br /> Change the bank_map to a u64 and use the proper BIT_ULL() macro when<br /> modifying bits in there.<br /> <br /> [ bp: Rewrite commit message. ]

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: improve error handling from ext4_dirhash()<br /> <br /> The ext4_dirhash() will *almost* never fail, especially when the hash<br /> tree feature was first introduced. However, with the addition of<br /> support of encrypted, casefolded file names, that function can most<br /> certainly fail today.<br /> <br /> So make sure the callers of ext4_dirhash() properly check for<br /> failures, and reflect the errors back up to their callers.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> pwm: lpc32xx: Remove handling of PWM channels<br /> <br /> Because LPC32xx PWM controllers have only a single output which is<br /> registered as the only PWM device/channel per controller, it is known in<br /> advance that pwm-&gt;hwpwm value is always 0. On basis of this fact<br /> simplify the code by removing operations with pwm-&gt;hwpwm, there is no<br /> controls which require channel number as input.<br /> <br /> Even though I wasn&amp;#39;t aware at the time when I forward ported that patch,<br /> this fixes a null pointer dereference as lpc32xx-&gt;chip.pwms is NULL<br /> before devm_pwmchip_add() is called.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/amdgpu/gfx: disable gfx9 cp_ecc_error_irq only when enabling legacy gfx ras<br /> <br /> gfx9 cp_ecc_error_irq is only enabled when legacy gfx ras is assert.<br /> So in gfx_v9_0_hw_fini, interrupt disablement for cp_ecc_error_irq<br /> should be executed under such condition, otherwise, an amdgpu_irq_put<br /> calltrace will occur.<br /> <br /> [ 7283.170322] RIP: 0010:amdgpu_irq_put+0x45/0x70 [amdgpu]<br /> [ 7283.170964] RSP: 0018:ffff9a5fc3967d00 EFLAGS: 00010246<br /> [ 7283.170967] RAX: ffff98d88afd3040 RBX: ffff98d89da20000 RCX: 0000000000000000<br /> [ 7283.170969] RDX: 0000000000000000 RSI: ffff98d89da2bef8 RDI: ffff98d89da20000<br /> [ 7283.170971] RBP: ffff98d89da20000 R08: ffff98d89da2ca18 R09: 0000000000000006<br /> [ 7283.170973] R10: ffffd5764243c008 R11: 0000000000000000 R12: 0000000000001050<br /> [ 7283.170975] R13: ffff98d89da38978 R14: ffffffff999ae15a R15: ffff98d880130105<br /> [ 7283.170978] FS: 0000000000000000(0000) GS:ffff98d996f00000(0000) knlGS:0000000000000000<br /> [ 7283.170981] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033<br /> [ 7283.170983] CR2: 00000000f7a9d178 CR3: 00000001c42ea000 CR4: 00000000003506e0<br /> [ 7283.170986] Call Trace:<br /> [ 7283.170988] <br /> [ 7283.170989] gfx_v9_0_hw_fini+0x1c/0x6d0 [amdgpu]<br /> [ 7283.171655] amdgpu_device_ip_suspend_phase2+0x101/0x1a0 [amdgpu]<br /> [ 7283.172245] amdgpu_device_suspend+0x103/0x180 [amdgpu]<br /> [ 7283.172823] amdgpu_pmops_freeze+0x21/0x60 [amdgpu]<br /> [ 7283.173412] pci_pm_freeze+0x54/0xc0<br /> [ 7283.173419] ? __pfx_pci_pm_freeze+0x10/0x10<br /> [ 7283.173425] dpm_run_callback+0x98/0x200<br /> [ 7283.173430] __device_suspend+0x164/0x5f0<br /> <br /> v2: drop gfx11 as it&amp;#39;s fixed in a different solution by retiring cp_ecc_irq funcs(Hawking)

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 /> ibmvnic: Do not reset dql stats on NON_FATAL err<br /> <br /> All ibmvnic resets, make a call to netdev_tx_reset_queue() when<br /> re-opening the device. netdev_tx_reset_queue() resets the num_queued<br /> and num_completed byte counters. These stats are used in Byte Queue<br /> Limit (BQL) algorithms. The difference between these two stats tracks<br /> the number of bytes currently sitting on the physical NIC. ibmvnic<br /> increases the number of queued bytes though calls to<br /> netdev_tx_sent_queue() in the drivers xmit function. When, VIOS reports<br /> that it is done transmitting bytes, the ibmvnic device increases the<br /> number of completed bytes through calls to netdev_tx_completed_queue().<br /> It is important to note that the driver batches its transmit calls and<br /> num_queued is increased every time that an skb is added to the next<br /> batch, not necessarily when the batch is sent to VIOS for transmission.<br /> <br /> Unlike other reset types, a NON FATAL reset will not flush the sub crq<br /> tx buffers. Therefore, it is possible for the batched skb array to be<br /> partially full. So if there is call to netdev_tx_reset_queue() when<br /> re-opening the device, the value of num_queued (0) would not account<br /> for the skb&amp;#39;s that are currently batched. Eventually, when the batch<br /> is sent to VIOS, the call to netdev_tx_completed_queue() would increase<br /> num_completed to a value greater than the num_queued. This causes a<br /> BUG_ON crash:<br /> <br /> ibmvnic 30000002: Firmware reports error, cause: adapter problem.<br /> Starting recovery...<br /> ibmvnic 30000002: tx error 600<br /> ibmvnic 30000002: tx error 600<br /> ibmvnic 30000002: tx error 600<br /> ibmvnic 30000002: tx error 600<br /> ------------[ cut here ]------------<br /> kernel BUG at lib/dynamic_queue_limits.c:27!<br /> Oops: Exception in kernel mode, sig: 5<br /> [....]<br /> NIP dql_completed+0x28/0x1c0<br /> LR ibmvnic_complete_tx.isra.0+0x23c/0x420 [ibmvnic]<br /> Call Trace:<br /> ibmvnic_complete_tx.isra.0+0x3f8/0x420 [ibmvnic] (unreliable)<br /> ibmvnic_interrupt_tx+0x40/0x70 [ibmvnic]<br /> __handle_irq_event_percpu+0x98/0x270<br /> ---[ end trace ]---<br /> <br /> Therefore, do not reset the dql stats when performing a NON_FATAL reset.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ubifs: Fix memory leak in alloc_wbufs()<br /> <br /> kmemleak reported a sequence of memory leaks, and show them as following:<br /> <br /> unreferenced object 0xffff8881575f8400 (size 1024):<br /> comm "mount", pid 19625, jiffies 4297119604 (age 20.383s)<br /> hex dump (first 32 bytes):<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................<br /> backtrace:<br /> [] __kmalloc+0x4d/0x150<br /> [] ubifs_mount+0x307b/0x7170 [ubifs]<br /> [] legacy_get_tree+0xed/0x1d0<br /> [] vfs_get_tree+0x7d/0x230<br /> [] path_mount+0xdd4/0x17b0<br /> [] __x64_sys_mount+0x1fa/0x270<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> unreferenced object 0xffff8881798a6e00 (size 512):<br /> comm "mount", pid 19677, jiffies 4297121912 (age 37.816s)<br /> hex dump (first 32 bytes):<br /> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk<br /> 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk<br /> backtrace:<br /> [] __kmalloc+0x4d/0x150<br /> [] ubifs_wbuf_init+0x52/0x480 [ubifs]<br /> [] ubifs_mount+0x31f5/0x7170 [ubifs]<br /> [] legacy_get_tree+0xed/0x1d0<br /> [] vfs_get_tree+0x7d/0x230<br /> [] path_mount+0xdd4/0x17b0<br /> [] __x64_sys_mount+0x1fa/0x270<br /> [] do_syscall_64+0x35/0x80<br /> [] entry_SYSCALL_64_after_hwframe+0x46/0xb0<br /> <br /> The problem is that the ubifs_wbuf_init() returns an error in the<br /> loop which in the alloc_wbufs(), then the wbuf-&gt;buf and wbuf-&gt;inodes<br /> that were successfully alloced before are not freed.<br /> <br /> Fix it by adding error hanging path in alloc_wbufs() which frees<br /> the memory alloced before when ubifs_wbuf_init() returns an error.

In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> wifi: rtw89: fix potential leak in rtw89_append_probe_req_ie()<br /> <br /> Do `kfree_skb(new)` before `goto out` to prevent potential leak.