Vulnerabilidades

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> MIPS: SGI-IP27: Fix platform-device leak in bridge_platform_create()<br /> <br /> In error case in bridge_platform_create after calling<br /> platform_device_add()/platform_device_add_data()/<br /> platform_device_add_resources(), release the failed<br /> &amp;#39;pdev&amp;#39; or it will be leak, call platform_device_put()<br /> to fix this problem.<br /> <br /> Besides, &amp;#39;pdev&amp;#39; is divided into &amp;#39;pdev_wd&amp;#39; and &amp;#39;pdev_bd&amp;#39;,<br /> use platform_device_unregister() to release sgi_w1<br /> resources when xtalk-bridge registration fails.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> chardev: fix error handling in cdev_device_add()<br /> <br /> While doing fault injection test, I got the following report:<br /> <br /> ------------[ cut here ]------------<br /> kobject: &amp;#39;(null)&amp;#39; (0000000039956980): is not initialized, yet kobject_put() is being called.<br /> WARNING: CPU: 3 PID: 6306 at kobject_put+0x23d/0x4e0<br /> CPU: 3 PID: 6306 Comm: 283 Tainted: G W 6.1.0-rc2-00005-g307c1086d7c9 #1253<br /> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014<br /> RIP: 0010:kobject_put+0x23d/0x4e0<br /> Call Trace:<br /> <br /> cdev_device_add+0x15e/0x1b0<br /> __iio_device_register+0x13b4/0x1af0 [industrialio]<br /> __devm_iio_device_register+0x22/0x90 [industrialio]<br /> max517_probe+0x3d8/0x6b4 [max517]<br /> i2c_device_probe+0xa81/0xc00<br /> <br /> When device_add() is injected fault and returns error, if dev-&gt;devt is not set,<br /> cdev_add() is not called, cdev_del() is not needed. Fix this by checking dev-&gt;devt<br /> in error path.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mtd: core: add missing of_node_get() in dynamic partitions code<br /> <br /> This fixes unbalanced of_node_put():<br /> [ 1.078910] 6 cmdlinepart partitions found on MTD device gpmi-nand<br /> [ 1.085116] Creating 6 MTD partitions on "gpmi-nand":<br /> [ 1.090181] 0x000000000000-0x000008000000 : "nandboot"<br /> [ 1.096952] 0x000008000000-0x000009000000 : "nandfit"<br /> [ 1.103547] 0x000009000000-0x00000b000000 : "nandkernel"<br /> [ 1.110317] 0x00000b000000-0x00000c000000 : "nanddtb"<br /> [ 1.115525] ------------[ cut here ]------------<br /> [ 1.120141] refcount_t: addition on 0; use-after-free.<br /> [ 1.125328] WARNING: CPU: 0 PID: 1 at lib/refcount.c:25 refcount_warn_saturate+0xdc/0x148<br /> [ 1.133528] Modules linked in:<br /> [ 1.136589] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc7-next-20220930-04543-g8cf3f7<br /> [ 1.146342] Hardware name: Freescale i.MX8DXL DDR3L EVK (DT)<br /> [ 1.151999] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)<br /> [ 1.158965] pc : refcount_warn_saturate+0xdc/0x148<br /> [ 1.163760] lr : refcount_warn_saturate+0xdc/0x148<br /> [ 1.168556] sp : ffff800009ddb080<br /> [ 1.171866] x29: ffff800009ddb080 x28: ffff800009ddb35a x27: 0000000000000002<br /> [ 1.179015] x26: ffff8000098b06ad x25: ffffffffffffffff x24: ffff0a00ffffff05<br /> [ 1.186165] x23: ffff00001fdf6470 x22: ffff800009ddb367 x21: 0000000000000000<br /> [ 1.193314] x20: ffff00001fdfebe8 x19: ffff00001fdfec50 x18: ffffffffffffffff<br /> [ 1.200464] x17: 0000000000000000 x16: 0000000000000118 x15: 0000000000000004<br /> [ 1.207614] x14: 0000000000000fff x13: ffff800009bca248 x12: 0000000000000003<br /> [ 1.214764] x11: 00000000ffffefff x10: c0000000ffffefff x9 : 4762cb2ccb52de00<br /> [ 1.221914] x8 : 4762cb2ccb52de00 x7 : 205d313431303231 x6 : 312e31202020205b<br /> [ 1.229063] x5 : ffff800009d55c1f x4 : 0000000000000001 x3 : 0000000000000000<br /> [ 1.236213] x2 : 0000000000000000 x1 : ffff800009954be6 x0 : 000000000000002a<br /> [ 1.243365] Call trace:<br /> [ 1.245806] refcount_warn_saturate+0xdc/0x148<br /> [ 1.250253] kobject_get+0x98/0x9c<br /> [ 1.253658] of_node_get+0x20/0x34<br /> [ 1.257072] of_fwnode_get+0x3c/0x54<br /> [ 1.260652] fwnode_get_nth_parent+0xd8/0xf4<br /> [ 1.264926] fwnode_full_name_string+0x3c/0xb4<br /> [ 1.269373] device_node_string+0x498/0x5b4<br /> [ 1.273561] pointer+0x41c/0x5d0<br /> [ 1.276793] vsnprintf+0x4d8/0x694<br /> [ 1.280198] vprintk_store+0x164/0x528<br /> [ 1.283951] vprintk_emit+0x98/0x164<br /> [ 1.287530] vprintk_default+0x44/0x6c<br /> [ 1.291284] vprintk+0xf0/0x134<br /> [ 1.294428] _printk+0x54/0x7c<br /> [ 1.297486] of_node_release+0xe8/0x128<br /> [ 1.301326] kobject_put+0x98/0xfc<br /> [ 1.304732] of_node_put+0x1c/0x28<br /> [ 1.308137] add_mtd_device+0x484/0x6d4<br /> [ 1.311977] add_mtd_partitions+0xf0/0x1d0<br /> [ 1.316078] parse_mtd_partitions+0x45c/0x518<br /> [ 1.320439] mtd_device_parse_register+0xb0/0x274<br /> [ 1.325147] gpmi_nand_probe+0x51c/0x650<br /> [ 1.329074] platform_probe+0xa8/0xd0<br /> [ 1.332740] really_probe+0x130/0x334<br /> [ 1.336406] __driver_probe_device+0xb4/0xe0<br /> [ 1.340681] driver_probe_device+0x3c/0x1f8<br /> [ 1.344869] __driver_attach+0xdc/0x1a4<br /> [ 1.348708] bus_for_each_dev+0x80/0xcc<br /> [ 1.352548] driver_attach+0x24/0x30<br /> [ 1.356127] bus_add_driver+0x108/0x1f4<br /> [ 1.359967] driver_register+0x78/0x114<br /> [ 1.363807] __platform_driver_register+0x24/0x30<br /> [ 1.368515] gpmi_nand_driver_init+0x1c/0x28<br /> [ 1.372798] do_one_initcall+0xbc/0x238<br /> [ 1.376638] do_initcall_level+0x94/0xb4<br /> [ 1.380565] do_initcalls+0x54/0x94<br /> [ 1.384058] do_basic_setup+0x1c/0x28<br /> [ 1.387724] kernel_init_freeable+0x110/0x188<br /> [ 1.392084] kernel_init+0x20/0x1a0<br /> [ 1.395578] ret_from_fork+0x10/0x20<br /> [ 1.399157] ---[ end trace 0000000000000000 ]---<br /> [ 1.403782] ------------[ cut here ]------------

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ipc: fix memory leak in init_mqueue_fs()<br /> <br /> When setup_mq_sysctls() failed in init_mqueue_fs(), mqueue_inode_cachep is<br /> not released. In order to fix this issue, the release path is reordered.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> mm,hugetlb: take hugetlb_lock before decrementing h-&gt;resv_huge_pages<br /> <br /> The h-&gt;*_huge_pages counters are protected by the hugetlb_lock, but<br /> alloc_huge_page has a corner case where it can decrement the counter<br /> outside of the lock.<br /> <br /> This could lead to a corrupted value of h-&gt;resv_huge_pages, which we have<br /> observed on our systems.<br /> <br /> Take the hugetlb_lock before decrementing h-&gt;resv_huge_pages to avoid a<br /> potential race.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> ext4: fix delayed allocation bug in ext4_clu_mapped for bigalloc + inline<br /> <br /> When converting files with inline data to extents, delayed allocations<br /> made on a file system created with both the bigalloc and inline options<br /> can result in invalid extent status cache content, incorrect reserved<br /> cluster counts, kernel memory leaks, and potential kernel panics.<br /> <br /> With bigalloc, the code that determines whether a block must be<br /> delayed allocated searches the extent tree to see if that block maps<br /> to a previously allocated cluster. If not, the block is delayed<br /> allocated, and otherwise, it isn&amp;#39;t. However, if the inline option is<br /> also used, and if the file containing the block is marked as able to<br /> store data inline, there isn&amp;#39;t a valid extent tree associated with<br /> the file. The current code in ext4_clu_mapped() calls<br /> ext4_find_extent() to search the non-existent tree for a previously<br /> allocated cluster anyway, which typically finds nothing, as desired.<br /> However, a side effect of the search can be to cache invalid content<br /> from the non-existent tree (garbage) in the extent status tree,<br /> including bogus entries in the pending reservation tree.<br /> <br /> To fix this, avoid searching the extent tree when allocating blocks<br /> for bigalloc + inline files that are being converted from inline to<br /> extent mapped.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/i915/bios: fix a memory leak in generate_lfp_data_ptrs<br /> <br /> When (size != 0 || ptrs-&gt;lvds_ entries != 3), the program tries to<br /> free() the ptrs. However, the ptrs is not created by calling kzmalloc(),<br /> but is obtained by pointer offset operation.<br /> This may lead to memory leaks or undefined behavior.<br /> <br /> Fix this by replacing the arguments of kfree() with ptrs_block.<br /> <br /> (cherry picked from commit 7674cd0b7d28b952151c3df26bbfa7e07eb2b4ec)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()<br /> <br /> Wei Chen reports a kernel bug as blew:<br /> <br /> general protection fault, probably for non-canonical address<br /> KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]<br /> ...<br /> Call Trace:<br /> <br /> __i2c_transfer+0x77e/0x1930 drivers/i2c/i2c-core-base.c:2109<br /> i2c_transfer+0x1d5/0x3d0 drivers/i2c/i2c-core-base.c:2170<br /> i2cdev_ioctl_rdwr+0x393/0x660 drivers/i2c/i2c-dev.c:297<br /> i2cdev_ioctl+0x75d/0x9f0 drivers/i2c/i2c-dev.c:458<br /> vfs_ioctl fs/ioctl.c:51 [inline]<br /> __do_sys_ioctl fs/ioctl.c:870 [inline]<br /> __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:856<br /> do_syscall_x64 arch/x86/entry/common.c:50 [inline]<br /> do_syscall_64+0x3d/0x90 arch/x86/entry/common.c:80<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> RIP: 0033:0x7fd834a8bded<br /> <br /> In az6027_i2c_xfer(), if msg[i].addr is 0x99,<br /> a null-ptr-deref will caused when accessing msg[i].buf.<br /> For msg[i].len is 0 and msg[i].buf is null.<br /> <br /> Fix this by checking msg[i].len in az6027_i2c_xfer().

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> f2fs: fix to do sanity check on destination blkaddr during recovery<br /> <br /> As Wenqing Liu reported in bugzilla:<br /> <br /> https://bugzilla.kernel.org/show_bug.cgi?id=216456<br /> <br /> loop5: detected capacity change from 0 to 131072<br /> F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1<br /> F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0<br /> F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1<br /> F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0<br /> F2FS-fs (loop5): recover_inode: ino = 6, name = hln, inline = 1<br /> F2FS-fs (loop5): recover_data: ino = 6 (i_size: recover) err = 0<br /> F2FS-fs (loop5): Bitmap was wrongly set, blk:5634<br /> ------------[ cut here ]------------<br /> WARNING: CPU: 3 PID: 1013 at fs/f2fs/segment.c:2198<br /> RIP: 0010:update_sit_entry+0xa55/0x10b0 [f2fs]<br /> Call Trace:<br /> <br /> f2fs_do_replace_block+0xa98/0x1890 [f2fs]<br /> f2fs_replace_block+0xeb/0x180 [f2fs]<br /> recover_data+0x1a69/0x6ae0 [f2fs]<br /> f2fs_recover_fsync_data+0x120d/0x1fc0 [f2fs]<br /> f2fs_fill_super+0x4665/0x61e0 [f2fs]<br /> mount_bdev+0x2cf/0x3b0<br /> legacy_get_tree+0xed/0x1d0<br /> vfs_get_tree+0x81/0x2b0<br /> path_mount+0x47e/0x19d0<br /> do_mount+0xce/0xf0<br /> __x64_sys_mount+0x12c/0x1a0<br /> do_syscall_64+0x38/0x90<br /> entry_SYSCALL_64_after_hwframe+0x63/0xcd<br /> <br /> If we enable CONFIG_F2FS_CHECK_FS config, it will trigger a kernel panic<br /> instead of warning.<br /> <br /> The root cause is: in fuzzed image, SIT table is inconsistent with inode<br /> mapping table, result in triggering such warning during SIT table update.<br /> <br /> This patch introduces a new flag DATA_GENERIC_ENHANCE_UPDATE, w/ this<br /> flag, data block recovery flow can check destination blkaddr&amp;#39;s validation<br /> in SIT table, and skip f2fs_replace_block() to avoid inconsistent status.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> media: dvbdev: adopts refcnt to avoid UAF<br /> <br /> dvb_unregister_device() is known that prone to use-after-free.<br /> That is, the cleanup from dvb_unregister_device() releases the dvb_device<br /> even if there are pointers stored in file-&gt;private_data still refer to it.<br /> <br /> This patch adds a reference counter into struct dvb_device and delays its<br /> deallocation until no pointer refers to the object.

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> drm/radeon: Add the missed acpi_put_table() to fix memory leak<br /> <br /> When the radeon driver reads the bios information from ACPI<br /> table in radeon_acpi_vfct_bios(), it misses to call acpi_put_table()<br /> to release the ACPI memory after the init, so add acpi_put_table()<br /> properly to fix the memory leak.<br /> <br /> v2: fix text formatting (Alex)

*** Pendiente de traducción *** In the Linux kernel, the following vulnerability has been resolved:<br /> <br /> power: supply: fix null pointer dereferencing in power_supply_get_battery_info<br /> <br /> when kmalloc() fail to allocate memory in kasprintf(), propname<br /> will be NULL, strcmp() called by of_get_property() will cause<br /> null pointer dereference.<br /> <br /> So return ENOMEM if kasprintf() return NULL pointer.